Paste a JSON Web Token to read its header and payload — decoded locally, nothing is sent anywhere.
Your result will appear here.
Why
JSON Web Tokens (JWTs) carry authentication and authorization data between services, but they look like meaningless strings. The header and payload are just Base64URL-encoded JSON — a decoder reveals exactly what claims a token contains, like the user ID, roles, and expiry. A JWT is made of three parts separated by dots, in the form header.payload.signature, and each of the first two parts is simply JSON that has been Base64URL-encoded. That encoding is not encryption; it is a reversible text transformation designed to make JSON safe to put in a URL or HTTP header. Because of that, anyone can decode the header and payload of any JWT, which is exactly why a decoder is so useful for debugging and why you must never put secrets in a token's payload.
This decoder splits and decodes the token's header and payload right in your browser. It does not verify the signature or send your token anywhere, so it is safe to inspect tokens while debugging. The header typically tells you the token type and the signing algorithm — for example {"alg":"HS256","typ":"JWT"} — and sometimes a key identifier (kid) that points to which key signed it. The payload holds the claims: statements about the user and the token itself. Seeing these decoded turns an opaque string into readable JSON, so instead of guessing why a request was rejected you can look directly at the user ID, the roles or scopes, the issuer, the audience, and the timestamps that govern when the token is valid.
Understanding the standard claims is what makes a JWT decoder genuinely useful, because most authentication bugs come down to one of them. The registered claims defined by the spec include iss (issuer, who created the token), sub (subject, usually the user ID), aud (audience, who the token is meant for), exp (expiration time), nbf (not-before time), iat (issued-at time), and jti (a unique token ID). The time-based claims are expressed as Unix timestamps — seconds since 1970 — which is one reason a timestamp converter pairs so naturally with a JWT decoder. When you decode a token and see an exp value, you can immediately tell whether it has expired, and when you see aud or iss, you can check whether the token was issued by and for the systems you expect. Custom claims, such as roles, permissions, or tenant IDs, sit alongside these and describe what the bearer is allowed to do.
The single most important concept this tool exists to teach is the difference between decoding and verifying, because confusing them is a serious security mistake. Decoding only reads the Base64URL-encoded header and payload; it requires no key and proves nothing about whether the token is genuine. Verifying recomputes the signature using the issuer's secret or public key and confirms that the token was actually issued by a trusted party and has not been tampered with. A decoder like this one deliberately does not verify, so it is perfect for inspection during debugging — but your application code must always verify the signature before trusting a single claim. Anyone can craft a string that decodes to a payload claiming to be an administrator; only a valid signature, checked against the right key, proves that claim is legitimate.
A JWT decoder is one of the most practical tools for debugging authentication and authorization problems, which are notoriously opaque without visibility into the token. When a user is unexpectedly logged out, a request returns 401 or 403, or a permission check fails, the answer is almost always somewhere in the token. Decoding it lets you confirm the exp has not already passed, that the roles or scopes you expect are actually present, that the aud and iss match the service rejecting the request, and that the sub identifies the right user. Without a decoder you are reduced to adding log statements deep in your backend; with one you paste the token and read the truth in seconds. This is invaluable when integrating with identity providers, where a subtle mismatch in audience or a clock-skew issue with nbf can otherwise consume hours of guesswork.
It is worth being clear about what a JWT is and is not, so you use them safely. A JWT is a stateless bearer token: whoever holds it can use it, and the server trusts it based on the signature rather than by looking it up in a session store. That makes JWTs efficient and scalable, but it also means the payload is readable by anyone and that revoking a token before its expiry is genuinely hard, since there is no central record to invalidate. The practical implications are concrete: never store passwords, secrets, or sensitive personal data in a payload, because it is effectively public; keep expiry times short to limit the damage if a token leaks; and if you truly need encrypted contents, that is a separate standard (JWE) rather than a plain signed JWT. Treating the payload as visible and the signature as the only thing that confers trust is the mental model that keeps token-based systems secure.
How
Drop in the full JWT string, including both dots that separate the header, payload, and signature. The signature part is not decoded, but pasting the whole token is the most reliable way to make sure the header and payload split correctly. Because decoding happens entirely in your browser, even a real session token is safe to inspect here.
The decoded header and payload appear as formatted JSON. Read the header to see the signing algorithm and token type, then read the payload to inspect the claims — the user (sub), roles or scopes, issuer (iss), audience (aud), and the time-based claims like exp and iat that control validity.
Check the claims against what your application expects: confirm the token has not expired, that the roles and permissions are present, and that the issuer and audience match the service in question. Remember that this view only decodes the token — your backend must still verify the signature before trusting any of these values.
Who
Backend engineers inspect auth tokens constantly while building and debugging APIs, confirming that the claims their middleware reads match what the identity provider actually issued. A decoder lets them see the sub, roles, aud, and exp at a glance instead of instrumenting their authentication layer with log statements every time a request is unexpectedly rejected.
Frontend developers check what claims a session token carries so they can drive UI decisions like which menus to show or whether a token is about to expire. Decoding the payload in the browser is a quick way to confirm the client is receiving the user information and roles it expects from the backend, without needing access to server logs.
Testers verify token contents during functional and security testing, confirming that the right claims appear for each role and that expiry behaves correctly. Being able to decode a token makes it easy to assert that, for example, an admin login really produces an admin role claim and that a refreshed token carries an updated expiry.
Security professionals audit claims and expiry settings, looking for over-broad scopes, excessively long lifetimes, sensitive data leaking into the payload, or weak signing algorithms in the header. A decoder is their first lens on a token, after which they verify the signature and review how the issuing system protects its keys.
Engineers wiring services together with OAuth and OpenID Connect rely on decoding to debug mismatches between issuers and audiences across systems. When two services disagree about who a token is for, decoding both sides quickly reveals whether the aud, iss, or kid values line up the way the integration requires.
People diagnosing customer authentication issues use a decoder to understand a reported token without needing to reproduce the entire login flow. Reading the exp and claims from a token a user supplies often pinpoints the problem — an expired session, a missing permission, or a token meant for the wrong environment — in moments.
When
When a login, refresh, or protected request is not behaving and you need to know why. Decoding the token reveals whether the claims your application checks are actually present and correct, turning a vague 401 or 403 into a specific, fixable cause within seconds.
When you suspect a session has timed out, decode the token and read the exp claim, which is a Unix timestamp. Comparing it to the current time tells you immediately whether expiry is the culprit, which is one of the most common reasons a previously working token suddenly stops being accepted.
When access control is not working as expected and you need to see exactly what authority the token grants. Reading the role, scope, or permission claims from the payload shows whether the bearer truly has the access the application is trying to enforce, or whether a claim is missing or misspelled.
When wiring up OAuth or OpenID Connect, decoding tokens from the provider lets you confirm the iss, aud, and kid match what your service expects. Subtle mismatches in these values are a frequent source of integration failures that are otherwise hard to diagnose.
When reviewing how a system uses JWTs, decode representative tokens to check for sensitive data in the payload, over-long expiry times, and the signing algorithm declared in the header. This inspection often surfaces issues like secrets accidentally placed in claims or a weak or unexpected alg value.
When you are getting familiar with token-based authentication, decoding real tokens makes the abstract structure tangible. Seeing the header, the claims, and the unverified signature side by side builds an intuition for why the payload is readable by anyone and why only the signature can be trusted.
Paste a JSON Web Token to read its header and payload — decoded locally, nothing is sent anywhere.
Use the JWT Decoder