100% on-device · nothing uploaded
JWT decoder
Paste a JSON Web Token and read what is inside it — the header, the payload claims, and the expiry and issued-at times as plain dates. It all happens on your device, so a token that might grant access never leaves this tab.
How to use it
- Paste the token — three base64url parts separated by dots (header.payload.signature).
- The header and payload are decoded and pretty-printed; copy either with one tap.
- Time claims — exp, iat, nbf — are shown in your local time with how long ago or away they are.
Decoding is not verifying — and the difference has been exploited
The payload of a JWT is base64url, not encryption. Anyone holding the token can read every claim in it, which is why a token should never carry a password, a card number or anything else you would not hand to the bearer. The signature is the only part that proves the header and payload were not edited in transit, and checking it requires the secret or the public key.
That distinction has a well-known failure mode. The header names its own algorithm, so an attacker can rewrite it to “none”, strip the signature, and hand back a token whose claims say whatever they like. Libraries that trusted the header field accepted these, and the resulting CVEs are the reason every modern library makes you state the algorithm you expect rather than reading it from the token. Use this tool to see what is in a token; never to decide whether to trust it.
Reading the claims, and why this runs on your device
Seven registered claims turn up constantly. iss is who issued the token and aud is who it was meant for — a token minted for one service and replayed at another should fail on aud alone. sub identifies the subject, usually a user id. exp, nbf and iat are Unix seconds, not milliseconds, which is why a token pasted into a naive viewer sometimes appears to expire in 1970. jti is a unique id, the hook that makes revocation lists possible.
A live JWT is a credential: whoever holds it can act as its subject until it expires. Pasting one into a hosted decoder means sending a working key to a third-party server, where it lands in request logs that outlive your debugging session. This decoder is base64url and JSON.parse running in your own tab, so the token never crosses the network — and if you are ever unsure about a tool that does, that is a good reason to rotate the secret afterwards.
Questions
Is my token sent anywhere?
No. Decoding is base64url plus JSON parsing, done entirely in your browser. The token is never uploaded, logged or stored — which matters, because a JWT can be a live credential.
Does it verify the signature?
No, and on purpose. Verifying needs the secret or public key and is a server’s job; this tool only decodes and displays the contents. Never trust a token’s claims on the strength of decoding alone.
Why is each time shown two ways?
Each time claim (exp, iat, nbf) is a Unix timestamp; we show the absolute date in your local zone and how far in the past or future it is, so an expired token is obvious at a glance.
What are the three parts?
Header (the algorithm and type), payload (the claims), and signature (which proves the first two were not tampered with). Only the first two carry readable data.
Updated 2026-07-20. Runs fully in your browser — nothing is uploaded.