JWT Decoder — Decode & Verify Tokens in Your Browser
Header, payload, expiry status and HMAC verification — the token never leaves your device.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
Header
Payload
Signature
Base64url of the raw signature bytes. It can only be checked with the key — see below.
Claims
Verify signature
HMAC-signed tokens (HS256 / HS384 / HS512) can be verified here with the shared secret. Verification runs in your browser with WebCrypto — the secret is never sent anywhere.
Paste a JSON Web Token and see its header, payload and signature decoded instantly, with every registered claim labelled and the exp / nbf / iat timestamps turned into real dates. The tool tells you plainly whether the token is currently valid, expired, or not yet usable.
Decoding happens entirely in your browser. That matters more here than for most tools: a JWT is a credential, and pasting one into a server-side decoder hands it to whoever runs that server. Nothing on this page makes a network request with your token.
How to use JWT Decoder
- Paste the token — with or without a leading
Bearer. - Read the header and payload. Claims are listed with what each one means; time claims show the date and how far away it is.
- Check the status line — valid, expired, not yet valid, or no expiry at all.
- Optionally verify an HS256/384/512 signature by entering the shared secret. The check runs locally with WebCrypto.
Decoding is not verifying
A JWT's header and payload are just base64url-encoded JSON — anyone can read them, no key required. That is by design: the token carries its own claims so the server does not need a lookup. What stops someone changing those claims is the third segment, the signature, and only the party with the key can check it. So "decoded" tells you what the token says; only "verified" tells you it was really issued by whom it claims. This page shows both, and keeps them clearly apart.
Which algorithms can be verified here
The HMAC family (HS256, HS384, HS512) signs with a shared secret — the same string on the issuer and the verifier. If you are the developer with that secret, paste it and the signature is checked with the browser's WebCrypto implementation. Asymmetric algorithms (RS256, ES256, PS256…) need the issuer's public key in JWK or PEM form; this tool decodes those tokens fully but does not verify them.
The claims that matter
- exp — expiry, as Unix seconds. After this instant the token must be rejected. Tokens without it never expire, which is a design smell for anything user-facing.
- nbf — not-before. Rare, but a token can be issued for future use.
- iat — issued at. Useful for spotting tokens that were minted long ago and refreshed forever.
- iss / aud / sub — who issued it, who should accept it, who it is about. A verifier must check
aud, or a token for service A can be replayed against service B.
Red flags the decoder points out
An alg of none, or an empty signature segment, means an unsigned token; if a server accepts it, anyone can forge any claims. Five segments instead of three means a JWE — an encrypted token whose payload cannot be read without the key, which is exactly the point. And a huge payload usually means someone is using the token as a session store rather than an identity assertion.
Timestamps are shown as dates using the same conversion as the standalone timestamp tool.
Frequently asked questions
Is it safe to paste a real token here?
Yes — the token is decoded in your browser and never sent anywhere; you can verify that in the network tab. The general rule still stands: a JWT is a credential, so avoid pasting production tokens into any site whose code you cannot inspect, and never one that decodes server-side.
Why can I read the payload without the secret?
Because JWTs are signed, not encrypted. The header and payload are plain base64url — readable by anyone who holds the token. The secret only protects against modification: change one claim and the signature no longer matches. If the contents must be confidential, that's a JWE (encrypted JWT), which has five segments and cannot be decoded here.
Can it verify RS256 or ES256 tokens?
Not currently. Those use a public/private key pair, so verification needs the issuer's public key in JWK or PEM form. The tool decodes them fully and reports the algorithm; only HMAC (HS256/384/512) signatures, which use a shared secret, are verified here.
The token says "expired" but my app still accepts it — why?
Either the server allows clock skew (a minute or two is common), or it isn't checking exp at all — which is a bug worth fixing. Expiry shown here is against your device's clock, so also make sure that clock is right.
What does alg "none" mean?
An unsigned token. Any server that accepts it trusts the client's claims completely — a historically common vulnerability. Libraries should be configured with an explicit allow-list of algorithms so none is never accepted.