About JWT Decoder
JWT Decoder splits a JSON Web Token into its three parts and shows the contents of the first two: the header, which says which signing algorithm was used and what type the token is, and the payload, which carries the claims such as subject, issuer, issue time and expiry. Both are pretty-printed as JSON so a claim is legible instead of being buried in a base64 string.
The decoding is purely structural. A JWT is three base64url-encoded segments separated by dots, and the first two are simply decoded and parsed — no key is involved anywhere in this page.
That leads to the one thing you must not conclude from it. The third segment, the signature, is not checked, and the tool says so explicitly in its output. A token that decodes cleanly here is not thereby valid: the signature may be wrong, the expiry may have passed, and the algorithm may have been altered. Never treat a successful decode as authentication, and never accept a client-supplied token on that basis. If you need to verify rather than inspect, that check belongs on a server with the signing key.
How to use JWT Decoder
- 1 Paste the whole token, including all three dot-separated segments.
- 2 Read the header to see the declared algorithm and token type.
- 3 Read the payload for the claims — subject, issuer, times and any custom fields.
- 4 Treat the result as a description of what the token says, never as proof that it is genuine.
Frequently asked questions
Does it verify the signature?
No, and it states that in its own output. Verification requires the signing key and is deliberately out of scope for a browser page. A token that decodes successfully can still be forged, expired or misissued.
Is it safe to paste a real token here?
The decoding runs locally in your browser and nothing is transmitted. Even so, a production token is a live credential for as long as it has not expired, so prefer a throwaway token from a test environment unless you have a reason to inspect the real one.
Can it tell me whether a token has expired?
Not directly — it only shows the claims, so you would read the expiry claim yourself and compare it with the current time. Note that any check you do here is advisory only, since a client-side expiry check cannot be enforced.
Why does the payload look like it has too few claims?
JWT payloads carry only the claims that were put into them; most are shorter than people expect. The registered claims are conventional rather than mandatory, so a token with no issuer or audience is unusual but entirely legal.
Free, online, and private
Free to use
JWT Decoder is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How JWT Decoder behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Segments read | the first two only — header and payload; the third (signature) segment is never decoded or shown |
| Signature check | none — no key, no algorithm and no verification call exist; the output carries the line "signature not verified" |
| Minimum shape | at least two dot-separated parts; anything shorter returns the line "Invalid JWT" |
| Segment decoding | base64url is normalised (- to +, _ to /), padded to a multiple of 4, then parsed with JSON.parse |
| Claim handling | exp, nbf and iss are printed as they appear — no claim is validated or reformatted |
| Failure line | either segment failing produces one fixed line, "Failed to decode JWT" |
Compiled from the implementation of this tool and checked against it by itoolnet.
What JWT Decoder does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- Nothing is verified. Only the header and payload are read, no key is ever supplied and no algorithm is checked against the header, so a token whose payload was edited decodes exactly like an untouched one — readable text, never proof of authenticity.
- Time claims are not evaluated: exp and nbf appear as raw epoch numbers with no comparison against the current clock and no date formatting, so deciding whether the token is still valid is left entirely to you.
- Only the JSON layer is exposed. The header fields are not explained, a kid is not resolved to a key, and a payload that is not valid JSON after decoding falls to the single failure line with the cause discarded by the catch block.
Tested and documented by itoolnet, the team that builds and maintains this site.