JWT Decoder & Encoder
Decode and inspect a JSON Web Token, get plain-English feedback on every claim, verify the signature (HMAC, RSA, ECDSA, RSA-PSS or EdDSA — with a secret, PEM key, JWK or JWKS), decrypt encrypted tokens (JWE), and sign brand-new tokens. Everything runs in your browser — your token, secrets and keys are never uploaded.
New to this? Read the JWT guide →
● Header ● Payload ● Signature
Verify signature
Decode a token to verify it.
———
Paste a JWT to decode it.
How to use the JWT decoder
- Paste a token into the decode box. The header and payload are split out and shown as readable JSON, and the signature is displayed separately.
- Check the claims, especially exp (expiry). The tool flags a token that has already expired.
- To experiment, use the encode panel to build a token, or paste a secret or public key to verify that a token's signature is valid.
- To change a claim and see the effect, press Edit & re-sign — the decoded header and payload are loaded into the encode panel, where you can tweak them and sign with your own key or secret.
What you are looking at
A JWT is three Base64url parts joined by dots: header.payload.signature. The decoder reverses the Base64url on the first two so you can read them. The crucial point: the payload is encoded, not encrypted. Anyone holding the token can read every claim, which is exactly why it is safe to inspect one here, and why you must never put a password, API key or other secret in a token.
Claims worth checking
- exp and nbf — when the token expires and when it becomes valid.
- iat — when it was issued.
- aud and iss — the intended audience and the issuer; a server should verify both.
- sub — the subject, usually the user the token is about.
Decode safely
Everything runs in your browser, so you can inspect a production token without pasting it into someone else's server. You can also link straight to a decoded token with #token=… (the Copy link button builds this for you) — the fragment stays in the browser and is never sent to any server, though anyone who has the link can of course read the token in it.
For how the signature actually protects a token, the common attacks (alg: none, RS256-to-HS256 confusion) and a validation checklist, read JWT security: how JSON Web Tokens work.
Where you'd use this
Debugging authentication. When an API returns 401 and the token "looks fine", the answer is almost always inside the payload: an expiry in the past, the wrong audience, or a missing scope.
For example: A mobile app gets logged out after an hour despite a 24-hour session setting. Decoding the token shows exp is 3,600 seconds after iat — the auth server is ignoring the configured lifetime, not the app.
Frequently asked questions
What does the JWT decoder show?
It splits the token into header, payload and signature and decodes the Base64URL header and payload to readable JSON, including standard claims like exp, iat and sub.
Does it verify the token signature?
Yes — optionally. Decoding alone never proves a token is authentic, but paste the shared secret, a public key or certificate, a JWK or a JWKS (or fetch one by URL) and the tool checks HS/RS/ES/PS/EdDSA signatures locally. Production servers must still verify tokens themselves.
Is my token uploaded?
No. The token is decoded locally in your browser and never sent anywhere — important, since JWTs often grant access.
Does it flag security problems?
Yes. Beyond expiry, it warns about unsigned tokens (alg: none), unusually long lifetimes, suspected secrets or credentials in the payload, tokens too large for a cookie, and missing iss/aud claims.
Can it decrypt encrypted JWTs (JWE)?
Yes. Paste a five-part JWE and the matching key — RSA-OAEP(-256) private keys, direct or wrapped symmetric keys (dir, A128/192/256KW), PBES2 passwords and ECDH-ES keys are supported, with AES-GCM and AES-CBC-HS content encryption. Decryption happens locally, and a nested signed JWT is decoded automatically.