JWT decoder
Decoding and verification happen entirely in this page. The token, the secret and the key are never sent anywhere — this tool makes no network requests after it loads.
header · payload · signature
—
—
| Claim | Meaning | Value |
|---|---|---|
| No token decoded yet. | ||
Paste a token and a key, then press Verify. Nothing leaves the page.
About this tool
Paste a token to see its header and payload decoded, with the registered claims explained in plain terms and the expiry checked against the current time. Supply a secret or a public key and the signature is verified too.
The three parts of the token are colour-coded in the input so you can see where each one begins and ends.
How it works
Verification uses the browser's built-in Web Crypto API — HMAC for the HS family, RSASSA-PKCS1-v1_5 for RS, and ECDSA for ES. The key is imported and the signature checked inside the page. No cryptography is hand-rolled here, and no key or token is transmitted.
JWT, JWS and JWE — which one is on your screen
The three names get used interchangeably and they are not the same thing. A JSON Web Token (JWT, RFC 7519) is a set of claims — it defines what is being said, not how it travels. Those claims are then carried either inside a JSON Web Signature (JWS, RFC 7515), which signs them, or inside a JSON Web Encryption (JWE, RFC 7516), which encrypts them.
The familiar three-part string — header.payload.signature, dots between, no spaces — is JWS Compact Serialization. So a signed JWT is a JWS. The reverse does not hold: a JWS can sign any payload at all, and it is only a JWT when that payload happens to be a JSON claims set. If you searched for a JSON Web Signature decoder and landed here, this is the right tool — a signed JWT and a compact JWS are the same three-part structure, and this page decodes and verifies it either way.
A JWE is not handled here. Encrypted tokens have five dot-separated parts rather than three, and the payload is ciphertext — there is nothing to read without the decryption key. If your token has four dots in it, it is a JWE and this page will tell you it is malformed rather than pretend otherwise.
Common questions
Is my token sent anywhere?
No, and on this page that matters more than on most. A JWT is a live credential — anyone holding it can act as you until it expires. Decoding and verification both happen in your browser, with no fetch, no logging and no third-party scripts.
Do I have to give it my signing secret to verify?
Only if you want the signature checked. Decoding works without it. If you do supply one it is used by the browser's own crypto implementation and never leaves the page — but a token you have pasted into any online decoder should be treated as one you would rather rotate.
Which algorithms are supported?
The HMAC family (HS256, HS384, HS512), RSA (RS256, RS384, RS512) and ECDSA (ES256, ES384, ES512), using the browser's Web Crypto implementation.
Does a valid signature mean the token is safe to trust?
It means the signature matches the key you supplied. Expiry, issuer, audience and scope still have to be right for your case — the claims table shows those so you can check them.
What is the difference between decoding a token and verifying it?
They answer completely different questions, and confusing them is the most common JWT mistake there is.
Decoding is just Base64url — it unpacks the header and payload so you can read them. It needs no key, it always succeeds on a well-formed token, and it proves nothing whatsoever. Anyone can craft a token that decodes to "role": "admin"; the decoded content is a claim, not a fact.
Verifying recomputes the signature over the header and payload using a key you supply, and checks it against the signature the token carries. It needs the secret or public key, and it is what establishes that the token really was issued by whoever holds that key and has not been altered since.
This page decodes on paste, and verifies only once you give it a key. In your own code, never act on a decoded claim you have not verified.
Is this a token validator?
Partly, and the distinction is worth being precise about. It validates the two things that can be checked mechanically: that the signature is correct for the key you supply, and that the token has not expired. It cannot validate the things that depend on your application — whether the issuer is one you trust, whether the audience is you, whether the scope covers the action being attempted, and whether the algorithm is the one you expected rather than one an attacker substituted. The claims table lays those out so you can judge them, but that judgement is yours. See "Does a valid signature mean the token is safe to trust?" above.
Why a token fails to decode or verify
Invalid signature, and you are certain the secret is right
Check whether the secret is meant to be interpreted as raw text or as bytes decoded from Base64. Many issuers store the signing key Base64-encoded, and signing the text of that string produces a completely different signature from signing the bytes it represents. It is the most common cause of this by a wide margin.
Invalid signature on an RS or ES token
These are asymmetric. Verification needs the public key, not the secret used to sign. Supplying a private key, or a certificate where a key is expected, will fail.
The token expired but the system still accepted it
Most libraries allow a small clock-skew tolerance, typically 30 to 60 seconds, so a token can be honoured slightly past its exp. If the gap is larger than that, check that the clocks on the two machines agree.
Malformed token
A JWT is three Base64url segments separated by full stops. Base64url replaces + and / with - and _ and drops the = padding. A token that has been through a system expecting ordinary Base64 may have been corrupted in transit. Copying from a terminal that wrapped the line can also insert whitespace.
The header says alg: none
That is an unsigned token. It is a known attack: strip the signature, set the algorithm to none, and hope the verifier accepts it. Nothing in production should ever accept one.
The payload decodes but the claims look wrong
Decoding proves nothing about authenticity — anyone can read a JWT, and anyone can write one. Only a verified signature makes the claims trustworthy, and even then iss, aud, exp and nbf all still have to be checked against what your application expects.
The same job at the command line
Decoding is trivial without a tool. Verification is not, which is the part worth having a page for.
echo $JWT | cut -d. -f2 | base64 -d 2>/dev/null | jq .Decode and pretty-print the payload. The redirect swallows the padding warning Base64url causes.echo $JWT | cut -d. -f1 | base64 -d 2>/dev/null | jq .Decode the header, which is where the algorithm is declared.
More tools
See the whole toolbox — thirty-seven free tools planned, all running in your browser.