Also available in: Español · Português · Français · العربية
JWT Decoder
Paste a JSON Web Token and see its header, payload, and signature status decoded instantly, entirely in your browser.
What is a JWT decoder?
A JSON Web Token (JWT) is a compact, three-part string — header, payload, and signature, separated by dots — that carries a set of claims as base64url-encoded JSON. Applications use them for things like session tokens and API credentials because the claims can be read without a database lookup. A JWT decoder takes that string apart: it base64url-decodes each segment, parses the JSON, and shows you what the token actually says. This decoder does exactly that with no installation and no account — paste a token and see its claims laid out as readable tables instead of a wall of encoded text.
Decoding is not the same as trusting. A decoder tells you what a token claims about itself — who issued it, who it is for, when it expires — not whether those claims are genuine. That distinction is central enough that it gets its own section below, because it is the single most important thing to understand before you use a decoded JWT for anything.
How to use it
- Paste your token. Drop the full JWT into the box above. Decoding happens as you type — there is no submit button and nothing leaves your browser.
- Read the header and payload. They appear as tables of claims, each with its value, a plain-English meaning for the seven claims RFC 7519 registers, and a human-readable UTC date for exp, nbf, and iat. Above them you will see the algorithm, the token type, and whether the token is expired, not yet valid, or currently within its validity window.
- Check the signature, then copy or clear. The signature segment is shown for reference but deliberately not verified. Use the copy button to grab either raw-JSON view, load a sample token to see the tool in action, or hit clear to start over.
What this tool won't tell you
Decoding a JWT and verifying one are not the same operation, and RFC 7519 is explicit about the difference: recovering the header and payload is base64url decoding and JSON parsing, nothing more. It tells you what a token claims, not whether those claims are genuine. Anyone with a text editor can construct a token whose payload says “admin”: true — the values only become trustworthy once a signature has been checked against the right key, and that check is a separate step this page does not perform.
That is also why there is no field to paste a signing secret. Verifying an HS256 token means typing the same secret your server uses to sign tokens into a web page, and a signing secret is precisely the value that must never leave your own systems — pasting it anywhere, even into a tool that runs entirely client-side, is a habit not worth forming. Tools that offer a “verify” button are asking you to paste that secret; this one refuses instead. The token itself never leaves your browser either — it is not uploaded, not logged, and not tucked into the address bar the way some decoders have historically handled it.
There are limits to what decoding alone can tell you, worth stating plainly. The expired / not-yet-valid status compares the token’s exp and nbf claims against your own device’s clock, so it inherits whatever clock skew your device has. It does not check that aud or iss match what your application actually expects — that is application logic, not decoding. It cannot tell you whether a token has been revoked, since revocation lives in a database somewhere, not in the token. And a five-part token is JWE, not JWS — genuinely encrypted rather than malformed — so its payload cannot be read without the decryption key, decoder or not.
A couple of details are easy to get wrong even once you are looking at decoded JSON. exp, nbf, and iat are NumericDate values — seconds since 1970-01-01 UTC, not milliseconds — so a naive new Date(exp) in JavaScript lands you somewhere in the far future; the decoder converts these to a readable UTC date so you do not have to do the arithmetic yourself. And if the header’s alg is none, that is not a formatting quirk: RFC 7515 defines it as an unsecured token, one with no signature at all, and the decoder flags it as such rather than treating it like any other algorithm.
The decoder itself was checked against the jose library on 400 randomly generated tokens plus hand-written edge cases — 3,073 assertions, all passing — and that library was then removed, so it is not a dependency of this site.
Why is it free?
This is a static page that decodes your token with JavaScript already running in your browser — there is no per-use cost to cover, so there is no account, no rate limit, and no watermark on the output. Nothing is uploaded, because decoding a JWT never required a server in the first place.