JWT Decoder

JWT Decoder: How It Works

A JSON Web Token is three base64url-encoded parts separated by dots. Anyone can decode and read one — that is by design. What they cannot do without the key is change it and have it still verify. Understanding that distinction is the whole of JWT security.

The three parts

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjMiLCJleHAiOjE3...} . SflKxwRJSMeKKF2QT4f

Part	Contains
Header	Algorithm (`alg`) and type (`typ`)
Payload	Claims — who the token is about, what it permits, when it expires
Signature	A cryptographic seal over the first two parts

The first two parts are base64url, not encryption. Decoding requires no key, so a JWT is readable by anyone who holds it. Never place passwords, payment details or anything private in the payload.

Standard claims

Claim	Meaning
`iss`	Issuer — who created it
`sub`	Subject — usually the user ID
`aud`	Audience — which service should accept it
`exp`	Expiry, as a Unix timestamp in seconds
`nbf`	Not valid before
`iat`	Issued at
`jti`	Unique token ID, used for revocation lists

exp is in seconds, while JavaScript's Date.now() returns milliseconds. Mixing them produces tokens that appear to expire in the year 56000, and it is one of the most common implementation bugs.

Signing algorithms

Algorithm	Type	Suits
HS256	Symmetric (shared secret)	One service both issuing and verifying
RS256	Asymmetric (private/public key)	Many services verifying tokens issued by one
ES256	Asymmetric, elliptic curve	Same as RS256, smaller signatures

Asymmetric signing lets any number of services verify with a public key while only the issuer can create tokens. With a shared secret, every verifier can also forge.

The two classic vulnerabilities

alg: none. The specification permits an unsecured token. A verifier that trusts the header's algorithm field will accept a token with no signature at all. Always pin the expected algorithm server-side rather than reading it from the token.
Algorithm confusion. A server expecting RS256 that is passed an HS256 token may verify it using the public RSA key as an HMAC secret — and the public key is public. Again, the fix is to pin the algorithm.

What decoding does not tell you

A decoder shows the header and payload. It does not verify the signature without the key, so a decoded token that looks correct may still be forged or expired. Decoding is for debugging — reading claims, checking expiry, confirming a scope was issued. Verification always belongs on the server with the key.

Practical guidance

Keep access tokens short-lived — minutes to an hour — and use a refresh token for longer sessions.
Because JWTs are stateless, they cannot be revoked by deleting a record. Short expiry plus a denylist keyed on jti is the usual compromise.
Always validate exp, aud and iss, not just the signature. A valid signature on a token intended for another service is still the wrong token.
Transmit only over HTTPS, and prefer an httpOnly cookie over localStorage, which is readable by any script on the page.

Frequently Asked Questions

Is a JWT encrypted?

No. The header and payload are base64url-encoded, which is reversible by anyone. Signing proves the token has not been altered; it does not hide the contents. Never put secrets in a payload.

Can this decoder verify my token?

It decodes the header and payload so you can read the claims. Verifying the signature requires the secret or public key, which belongs on your server and should never be pasted into a web tool.

Why does my token show an absurd expiry date?

Almost certainly milliseconds where seconds are required. The exp claim is a Unix timestamp in seconds; JavaScript's Date.now() returns milliseconds. Divide by 1000.

What is the alg:none attack?

The specification allows an unsecured token with no signature. A verifier that reads the algorithm from the token's own header can be tricked into accepting one. Always pin the expected algorithm in your server configuration.

How do I revoke a JWT?

You cannot directly, because verification is stateless and requires no lookup. The practical approaches are short expiry times with refresh tokens, and a server-side denylist of revoked jti values checked on each request.

Should I store tokens in localStorage?

Preferably not. localStorage is readable by any JavaScript on the page, so a single cross-site scripting flaw exposes the token. An httpOnly, secure cookie with SameSite protection is generally safer.