JWT Decoder
Read the header and payload of a JSON Web Token, with expiry checked against your clock.
Output — jwt.json
About this tool
Paste a JSON Web Token and read its header and payload as formatted JSON. The notes translate the timestamp claims into real dates, say how long ago a token expired, and flag the dangerous cases - an unsigned token, or a missing expiry. Decoding happens in this browser tab and the token is never transmitted, which is not something you can verify about a server-side decoder.
Three segments, two of them public
A JWT is header.payload.signature, each part Base64URL-encoded and joined with dots. The header and payload are encoded, not encrypted: anyone holding the token can read them, which is exactly what this tool does. The signature is the only part that needs a key, and it proves the other two have not been altered.
The practical consequence gets missed a lot: never put anything confidential in a JWT payload. A user id and a role are fine. An internal email address, a permissions matrix or anything you would not print in a log is not.
Decoding is not verifying
This tool reads the claims. It does not check the signature, because that needs the shared secret or the public key - and pasting your signing secret into a web page would be a genuinely bad idea, whoever runs the page.
A server must do more than check the signature too. It has to confirm alg is the algorithm it expects (never the one the token names), that exp has not passed, and that iss and aud match this service. Skipping the alg check is the classic JWT vulnerability: a token arrives claiming alg "none", a naive library accepts it as signed, and anyone can mint an admin session.
Frequently asked questions
Is my token sent anywhere?
No. The split and the Base64URL decode happen in JavaScript in this tab, and the page makes no network requests at all. That said, a production token is a live credential until it expires - the safest habit is to decode tokens from a staging environment.
Why can I read the payload without any key?
Because a signed JWT (a JWS) is not encrypted. The signature guarantees integrity - that nobody changed the claims - not confidentiality. If the contents must be secret, you want a JWE, which has five segments and cannot be read without the key.
What are exp, iat, nbf, iss and aud?
Registered claims from RFC 7519. exp is the expiry and iat the issue time, both as Unix seconds; nbf is "not valid before"; iss identifies who issued the token and aud who it is for. A correct server checks all of them, not just the signature.
How long should a token live?
Short - minutes to an hour for an access token - because a JWT cannot be revoked. It is valid until exp passes, so a leaked long-lived token is a valid session for as long as it says. The usual pattern is a short access token plus a long-lived refresh token stored server-side, where you can revoke it.