JWT Decoder
Paste a JSON Web Token to see its header, payload and claims — with expiry checked automatically and HMAC signature verification, all in your browser.
{{ error }}
Decoded — well-formed token alg {{ alg || '(missing)' }}
This token uses "alg": "none"
A token with no algorithm has no signature at all — anyone can write one by hand with any claims they like. Never trust one of these for authentication or authorization.
This token has expired
The exp claim was {{ decoded.claims.exp.iso }} — in the past.
A conforming API should already be rejecting it.
This token is not valid yet
The nbf claim is {{ decoded.claims.nbf.iso }} — in the future.
{{ t.v }}{{ '\n' }}
{{ t.v }}{{ '\n' }}
Claims
- {{ row.label }} {{ row.key }}
- {{ fmtValue(row.raw) }} — {{ row.time.iso }}
Verify signature
{{ alg }} is signed with a private/public key pair, not a shared secret. Verifying it here would need the signer's public key, which this tool does not ask for — the header and payload above are still fully decoded and trustworthy to read.
There is no signature to verify — see the warning above.
The key never leaves this page. It is used locally to recompute the signature and is not sent anywhere, saved, or logged.
{{ verifyError }}
Signature verified
The {{ alg }} signature matches this header and payload under the key you provided.
Signature does not match
Either this is not the right key, or the header/payload has been altered since it was signed. Double-check the key came from the same source that issued this token.
Enter the signing key above to verify this token's signature.
Paste a JWT above to decode its header, payload and claims.
The token and any signing key you enter are decoded and verified entirely in your browser. Neither is ever uploaded to a server.
About JSON Web Tokens
A JWT is three Base64URL-encoded parts joined by dots: a header naming the signing algorithm, a payload of claims (the actual data), and a signature over the first two. Decoding the header and payload needs no secret at all — that is just Base64, which is why a JWT should never carry anything you wouldn't put in a URL. The signature is what actually proves the token wasn't tampered with, and checking it does need the right key.
Decoding is not the same as trusting
Anyone can read a JWT's claims without any key — that's by design, not a bug. What a signature check adds is proof that whoever holds the signing key produced this exact header and payload. A token with a valid structure and a plausible-looking payload but a signature you can't verify should be treated as unverified, not as authentic.
Why HS256/384/512 verify here, but RS/PS/ES don't
The HS family signs with a single shared secret — the same value both signs and verifies, which is exactly what a browser-only tool can do locally. The RS, PS and ES families sign with a private key and verify with a separate public key; verifying one of those tokens here would mean pasting in the issuer's public key, which this tool doesn't ask for. Those tokens still decode fully — only the cryptographic check is out of scope.
Working with the raw payload instead?
Use the JSON Formatter to explore a decoded payload further, or Base64 Encode & Decode to work with a single segment directly.
Frequently asked questions
Is decoding a JWT the same as verifying it?
No. The header and payload are just Base64URL — anyone can decode them without any key, which is why a JWT should never carry a secret in its claims. Only the signature check actually proves the token came from whoever holds the signing key and hasn't been altered since.
Why can this tool verify some tokens but not others?
HS256/384/512 sign with one shared secret, the same value used to both sign and verify — exactly what a browser-only tool can check locally. RS, PS and ES tokens sign with a private key and verify with a separate public key, which this tool would have to ask you to paste in; it doesn't, so those tokens decode fully but show as unverified rather than a false pass or fail.
What do exp, nbf and iat mean?
They are Unix timestamps: exp is when the token expires, nbf is when it first becomes valid, and iat is when it was issued. This tool converts all three to a readable date and flags the token if exp has already passed or nbf hasn't arrived yet.
Is my token or secret key uploaded anywhere?
No. Decoding and signature verification both run entirely in your browser with JavaScript. Nothing is sent to a server, and the key field is masked by default so it doesn't linger in a screenshot or a shared screen.
Why does it say "alg: none" is dangerous?
A token with no algorithm has no signature at all, so anyone can hand-write one with whatever claims they want. Some libraries have historically accepted these by mistake; a conforming verifier must always reject them.
What should I do if the signature doesn't match?
Confirm you're using the exact key the issuer signed with, in the format they gave it to you — a webhook secret published as hex or Base64 gives a different, wrong result if treated as plain text. If the key is right and it still doesn't match, the token has been altered since it was signed.