JWT Decoder
Decode a JSON Web Token, inspect its claims, and verify the signature — locally.
Token → claims
Token
Verify signatureenter the secret
Keys never leave this page — verification runs on the Web Crypto API in your browser, and nothing is persisted.
HeaderHMAC SHA-256 · symmetric
{ "alg": "HS256", "typ": "JWT" }
Payload
{ "sub": "1234567890", "name": "John Doe", "iat": 1516239022, // 2018-01-18T01:30:22Z "exp": 1916239022, // 2030-09-21T16:37:02Z "iss": "https://example.com", "aud": "https://api.example.com" }
Valid JWT · HS256 · 6 claims · runs locally
What this tool does
Paste a JWT and this tool splits it into its colour-coded parts, decodes the header and payload, and explains the registered claims — with exp, iat, and nbf annotated in human time and expired tokens flagged. Signature verification is built in: HMAC secrets check live as you type, and asymmetric algorithms take a PEM or JWK public key. Everything — token, secret, key — stays in your browser and is never persisted.
How to use it
- Paste your token into the left pane — the three parts light up as header, payload, and signature.
- Read the decoded header and payload on the right — timestamps carry UTC and relative annotations, and the Claims view explains each registered claim.
- To verify: type the secret for HMAC tokens (it checks live), or paste the public key and hit Verify for RSA/ECDSA tokens.
- Copy the payload, or open the Download menu for the decoded JSON.
Frequently asked questions
Is my token or secret uploaded anywhere?
No. Decoding is plain base64url in your browser, and signature verification runs on the Web Crypto API locally. Neither the token, the secret, nor a public key is sent anywhere or persisted — everything is gone when you close the tab.
How does signature verification work?
For HMAC algorithms (
HS256/384/512) the tool re-signs the token with your secret and compares — it verifies live as you type. For asymmetric algorithms (RS*, PS*, ES*) paste the public key as PEM or JWK and hit Verify.Why does it decode without the secret?
A JWT’s header and payload are just base64url-encoded JSON — anyone can read them. The secret only protects the signature, i.e. whether the token was tampered with. That’s also why you should never put sensitive data in a JWT payload.
What do exp, iat, and nbf mean?
Unix timestamps controlling the token's lifetime: iat is when it was issued, exp when it stops being accepted, nbf the earliest moment it may be used. The tool annotates each with the UTC time and how far away it is, and flags expired or not-yet-valid tokens.
What about alg: none tokens?
They decode like any other token, but the tool labels them clearly: an alg-none token carries no signature at all, and accepting one in production is a classic JWT vulnerability.