JWT Decoder

Inspect a token's header, claims and expiry without handing it to anyone.

Token

Header

Payload

Verify signature

Shared secret (HMAC only) Verified locally with the Web Crypto API. RSA and ECDSA tokens are decoded but not verified — that needs the issuer's public key.

Send output to

The tool you should least want to paste into a website

A JSON Web Token is a bearer credential. Whoever holds it is the user it describes, until it expires. Debugging one means pasting it somewhere — and the usual somewhere is a web page that sends it to a server.

Decoding a JWT requires no server. It is a dot-separated string of three Base64URL segments; the first two are JSON. Splitting and decoding that is a few lines of JavaScript, which is exactly what this page does. No request is made, and you can confirm it by decoding with your network disconnected.

One honest caveat: a token pasted into any browser tab is readable by extensions with access to the page. If the token is a live production credential, revoke or rotate it once you have finished debugging, regardless of which tool you used.

Decoding is not verifying

This is the single most important thing to understand about JWTs, and it causes real vulnerabilities. Anyone can read a token's claims — they are only encoded, not encrypted. The signature is what makes the claims trustworthy, and checking it requires the key.

So never make an authorisation decision from a decoded payload without verifying the signature server-side. Related: reject the none algorithm outright, and never let the token's own alg header choose your verification method — that is the classic algorithm-confusion attack, where an attacker re-signs an RS256 token as HS256 using your public key as the HMAC secret.

Reading the standard claims

exp — expiry. Shown here as an absolute time and a countdown.
iat — issued at. A far-future iat usually means milliseconds were written where seconds were expected.
nbf — not before. A token can be structurally valid and not yet usable.
iss / aud — issuer and audience. Both must be checked; a valid token from the wrong issuer is still the wrong token.
sub — the subject, usually a user id.
jti — a unique id, used for replay protection and revocation lists.

A JWT in a URL is a credential in a browser history, a proxy log and a referrer header. Put them in an Authorization header.

Do not put secrets in the payload

Because the payload is readable by anyone holding the token, it is not a place for anything private — no internal identifiers you would not publish, no personal data beyond what the client already knows, and certainly no other credentials. If you need confidentiality rather than integrity, you want JWE, not JWS.

Questions people actually ask

Is it safe to paste a real token here?

Safer than anywhere else, because the token is never transmitted. Decoding is string splitting and Base64URL — no request is made, and you can verify that by decoding with your connection off. That said, a token pasted into any browser tab can be read by extensions with page access, so a production token is still worth revoking afterwards.

Can it verify the signature?

For HMAC algorithms, yes — supply the shared secret and it is verified locally with the Web Crypto API. For RSA and ECDSA it decodes and reports the algorithm but does not verify, because that needs the issuer's public key. Decoding is not verification: anyone can read a JWT, which is why you must never trust its claims without checking the signature server-side.

Why does my token show as expired when it just worked?

Almost always clock skew or a seconds/milliseconds mix-up. The `exp` and `iat` claims are Unix seconds. A library that writes milliseconds produces a token that looks valid centuries from now, and one that reads milliseconds as seconds sees everything as long expired.