Text and data

Decode a JWT, and verify it

And check the signature, not just read it.

On this device

Paste the token

Decoding happens as you type and needs no key. To verify, add the secret or public key underneath.

Decoded as you type, on this device. A “Bearer ” prefix is ignored if you paste one.

What this tool does, exactly

Decoding a token tells you what it claims. Verifying it tells you whether to believe any of that. This does both, keeps them visibly apart, and does it on a page that has no endpoint to send your token to.

Decoded is not verified
Anyone can decode any token: the header and payload are base64url, not encryption, and they are readable by design. That step proves nothing. Verification is arithmetic against a key, and it is the only part that answers whether a token is genuine. The two are shown separately here and the verdict is never implied by a tidy-looking payload.
What it verifies
HS256, HS384 and HS512 with a shared secret; RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512 with a public key in PEM or JWK form. All of it through the browser's own WebCrypto — the same implementation that verifies the certificate for this page.
The claims that are not the signature
A valid signature on an expired token is still an expired token. Expiry, not-before and issued-at are checked against your clock and reported separately from the signature, in plain dates as well as the raw numbers, because a token can fail in two entirely different ways and “invalid” is not a useful answer to either.
alg: none is refused
A token declaring no algorithm at all is a known attack rather than a curiosity — an attacker strips the signature and hopes the verifier obliges. It is decoded and shown, clearly labelled unsigned, and never reported as verified under any circumstances.
Why here rather than anywhere
A JWT is not information about a credential; it is the credential, and so is the signing secret you would paste beside it. This site is static files with no endpoint. Open your browser's network panel, or disconnect after the page loads and watch it keep verifying.

About this tool

Is it safe to paste a real token here?

The decoding and verification run in this browser tab, and the event bridge has no token or key property. You can inspect the network panel to verify the current request boundary. A real token is still a credential in memory, so close the tab when done and prefer a test key to a production signing secret.

What is the difference between decoding and verifying?

Decoding unpacks base64url and shows you what the token says. Anyone can do it to any token, including one somebody made up thirty seconds ago, and it proves precisely nothing. Verifying recomputes the signature with a key and compares it, which is the step that establishes the token really was issued by whoever holds that key and has not been altered since.

Which algorithms are supported?

HS256, HS384 and HS512 with a shared secret. RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 and ES512 with a public key, given as PEM or as a JWK. EdDSA is not supported here yet: browser support for Ed25519 in WebCrypto is still uneven, and a verifier that works in one browser and fails silently in another is worse than one that says it cannot.

My token verified but the tool still says there is a problem.

Then the signature is genuine and something else is wrong — almost always that the token has expired, or that its not-before time has not arrived yet. Those are reported separately from the signature on purpose, because they mean different things: a bad signature means do not trust this token at all, while an expired one means it was genuine and is now past its time.

Do you support decoding encrypted tokens (JWE)?

No. A JWE is encrypted rather than merely signed, needs the decryption key, and has a different structure with five parts rather than three. It is a different tool and it is not this one; a JWE pasted here is recognised and named rather than reported as malformed.

More text and data tools · All 52 · How they work