What is a JWT Decoder?
A JSON Web Token is three base64url-encoded parts joined by dots: a header that names the signing algorithm and key id, a payload of claims, and a signature. The format is defined by RFC 7519 with the signature in RFC 7515. Base64url is an encoding, not encryption, so anyone holding a token can read every claim inside it — which is why tokens are stolen rather than forged, and why a JWT must never carry a password, a card number or anything you would not print.
This decoder splits a pasted token, renders the header and payload as formatted JSON, lists the registered timestamp claims (exp, iat, nbf, auth_time) as ISO dates next to their raw second values, and states plainly whether the token has already expired. The signature is displayed so you can copy or compare it, but it is deliberately not verified.
Decoding happens in the page. No request is made with the token and nothing is stored, so it cannot end up in a server log.
How to decode a JWT
- Paste the whole token into the box. A leading "Bearer " is stripped automatically, and line wrapping is ignored.
- Read the Header panel for the algorithm (alg), token type (typ) and key id (kid) your server will use to pick a verification key.
- Read the Payload panel for the claims — typically iss, sub, aud, exp, nbf, iat, jti plus your application's own scope or roles.
- Check the validity banner and the timestamp table. An expired token, or one whose nbf is still in the future, is the usual cause of an unexplained 401.
- Treat the claims as untrusted until your server has verified the signature, and see the expiry of any refresh token before assuming a session is still alive.
JWT Decoder limits and rules
| Item | Limit |
|---|---|
| Supported format | Compact JWS with three dot-separated parts |
| Encrypted tokens | JWE has five parts and needs the decryption key — this tool cannot read it |
| Signature verification | Not performed; the browser must never hold the issuer's secret |
| alg: none | Shown as-is, but an unsigned token must be rejected by your server |
| Claim timestamps | NumericDate, meaning whole seconds since 1970-01-01 UTC |
| Common registered claims | iss, sub, aud, exp, nbf, iat, jti |
| Clock tolerance | Verifiers usually allow 60–120 seconds of skew on exp and nbf |
When to use it
- Debugging a 401 or invalid_token response: nine times out of ten the token expired, or its aud or iss does not match what the API expects.
- Checking which scopes, roles or tenant id a token actually carries before filing an access bug against the wrong service.
- Telling a staging token apart from a production one when both are floating around in the same clipboard.
- Reviewing the algorithm and key id in code review, to catch a token signed HS256 where the service verifies RS256.
- Confirming that an SDK refreshes tokens when it says it does, by watching exp move forward.
Is it private?
Everything runs inside your browser. Your text and files are never uploaded, never stored and never seen by anyone else — including me. You can use the tool with the network tab open and watch no request leave the page. Closing the tab erases the input.
Frequently asked questions
No. Verification requires the issuer's public key or shared secret; with HMAC the secret itself would have to reach the browser, which is exactly the mistake that lets attackers mint their own tokens. Verify server-side, or with the issuer's JWKS in a trusted environment.
Five parts means it is a JWE — an encrypted token, defined by RFC 7516. Its claims are ciphertext and cannot be read without the decryption key, so a form-based decoder will report an error rather than showing content that is not there.
The expiry time as a NumericDate: whole seconds since 1970-01-01 UTC. The tool multiplies it by 1000 and prints the equivalent ISO timestamp, so exp 1735689600 renders as 2025-01-01T00:00:00.000Z.
The decoding happens locally, so the token is not transmitted. Even so, get out of the habit of pasting live credentials into any web page — use a short-lived test token, and rotate anything you are unsure about.
Because a signature proves integrity, not confidentiality. Anyone can base64url-decode the payload, so a JWT with a valid signature is still readable by anyone who intercepts it.
Related tools
Written and maintained by Md. Nur Hossain Repon.