JWT decoder

Decoding only — the signature is not verified. JWTs are encoded, not encrypted: never paste a token containing secrets you don't want decoded. Everything here runs in your browser.

What's inside a JWT

A JSON Web Token has three dot-separated parts: a header (the algorithm and type), a payload (the claims — who the token is about, when it was issued and when it expires), and a signature that proves it hasn't been tampered with. The header and payload are just base64url-encoded JSON, which is what this tool decodes. It also reads the standard exp, iat and nbf timestamps into readable dates.

Decoding is not verifying

This tool decodes a token; it does not verify the signature, because that requires the secret or public key held by the server that issued it. So a decoded payload tells you what a token claims, not that the claims are trustworthy. And because JWTs are encoded rather than encrypted, treat them like passwords — anyone who sees a token can read everything in it. The decoding here runs entirely in your browser, so tokens you paste are never sent anywhere.

Reading the three segments

A token looks like xxxxx.yyyyy.zzzzz. Split on the dots and the first two segments are base64url-encoded JSON you can read directly. A typical header decodes to {"alg":"HS256","typ":"JWT"} — the signing algorithm and the token type. The payload holds the claims, and the third segment is the signature over the first two.

Several claim names are standardised and worth recognising:

• iss — issuer, who created the token. aud — audience, who it is meant for.
• sub — subject, usually the user the token is about.
• exp — expiry, and nbf — not valid before. Both are Unix timestamps in seconds, not milliseconds.
• iat — issued at. jti — a unique token ID, used to revoke individual tokens.

Anything else is a custom claim your own system defined. The timestamp converter is handy if you need to check a raw epoch value by hand.

Why decoding proves nothing

The payload is encoded, not encrypted. Anyone holding the token can read every claim in it, and anyone can craft a token containing whatever claims they like. What they cannot do — without the key — is produce a valid signature for it.

That is why verification has to happen server-side with the secret or public key, and why a decoded payload tells you what a token asserts, never that the assertion is true. A verifier must also check that the algorithm is the one expected: historically, accepting the token's own alg header led to attacks where a token was re-signed with none, or an RSA public key was abused as an HMAC secret. Pin the expected algorithm rather than trusting the header.

Handling tokens safely

Treat a JWT like a password, because for as long as it is valid it functions as one. Anyone who obtains it can act as that user until it expires — which is the argument for short expiry times plus a separate refresh token.

Never paste a production token into a website you do not control. This decoder runs entirely in your browser and sends nothing anywhere, but you cannot tell that by looking at any given site, and the safe habit is to assume otherwise. If a live token has been pasted somewhere questionable, or committed to a repository, revoke it rather than hoping. For the underlying encoding, the Base64 tool decodes individual segments.