Decode a JSON Web Token and, given the secret or public key, actually verify its signature. Refuses alg: none and algorithm confusion
Initializing in your browser…
Sign a JSON Web Token with HS, RS, PS or ES, generate a key pair, and check the result against the verifier
Encode and decode text, files and JSON as base64, base64url or hex, checked by decoding the result back
Percent-encode and decode against four character sets, build query strings, and take a URL apart
Two tokens look identical in every decoder: one your issuer signed, and one where an attacker added "role": "admin" to the payload.
Input
the token, plus the HS256 secret it should have been signed with
Verdict
Signed token Signature verified with HS256
Tampered payload The signature does not match
Do not trust the claims below.
alg: none Refused. This token carries no signature at all.Anyone can write any claims into the middle segment, so a decoder that shows a payload and a green tick has said nothing about whether the token is genuine. Give this one the secret or the public key and it checks the signature with the Web Crypto API; without one it says "Not verified" rather than "valid". alg: none is refused in any capitalisation, and an RS256 token is never checked against a shared secret, because doing so is the algorithm confusion attack.
Paste a JSON Web Token and see its header, payload and claims. Add the secret or the public key and the tool checks the signature, which is the only thing that says the issuer wrote those claims rather than someone else. That distinction is the point. Anyone can write any claims they like into the middle segment of a token: admin true, a different subject, a later expiry. The payload decodes exactly the same either way. So a decoder that shows you a payload and a green tick has told you nothing about whether the token is genuine, and this one does not pretend otherwise. Without a key the verdict is "Not verified", never "valid". With a key it is either "Signature verified" or "the signature does not match", and it says which.
Verification runs in your browser through the Web Crypto API and covers HS256, HS384 and HS512 with a shared secret, RS256, RS384 and RS512, PS256, PS384 and PS512 with an RSA public key, and ES256, ES384 and ES512 with an EC public key. The key can be a PEM public key, a PEM certificate (the public key is taken out of it), a JWK, a whole JWKS with the right key chosen by the token's kid, or a plain shared secret read as text, base64 or hex. That last control matters more than it looks: a secret published as 64 hex characters is 32 bytes, not 64 characters, and hashing the characters instead of the bytes is the commonest reason a signature that should match does not.
Three attacks decide whether a JWT tool is safe to rely on, and all three are handled by refusing rather than by guessing.
alg: none is the unsigned-token attack: a token that declares it has no signature, which a verifier following the header will happily accept. It is refused unconditionally here, in any capitalisation, with or without a key, and the panel explains what it is rather than showing a green tick.
Algorithm confusion is signing with HMAC and labelling the header RS256, so that a verifier trusting the header uses the RSA public key, which is public, as a shared secret. The key you paste declares its own family, and a token whose header asks for a different family is refused with that named, rather than resolved in the header's favour.
A tampered payload keeps a perfectly valid structure and a signature that no longer covers it. Load the Tampered payload sample and it decodes cleanly and fails verification, which is exactly the difference the signature exists to draw.
Beyond the signature, the tool checks the claims a verifier is supposed to enforce. exp and nbf are reported as passed or failed with how long ago or how long from now, iat is flagged when it is in the future, which usually means a clock is wrong, and a token with no exp at all is called out because it never expires on its own. Clock leeway is adjustable, and an expected audience and issuer can be given, because accepting a token issued for a different audience is a real and common bug.
The token and the key stay in the page. Neither is sent anywhere, and neither goes into the URL, the browser history or the shareable link; the link carries only the settings.
Inspect the claims inside an access token, and with the public key confirm the token really came from your issuer rather than being one you pasted from the wrong environment.
Paste your JWKS and the token, and the right key is chosen by kid. If it does not verify, the key rotated or the token is not yours.
See when a token was issued, when it expires and by how much, with clock leeway if your servers disagree slightly.
Check what is in a payload before it goes to a client, and confirm the token is not accepting alg: none or relying on a secret short enough to guess.
Yes, if you give it the key. Paste the shared secret for an HS token or the public key for an RS, PS or ES token and the signature is checked in your browser with the Web Crypto API. Without a key it says "Not verified" and does not pretend to know.
Because alg: none means the token has no signature, so anyone can write any claims into it. A verifier that follows the header there accepts forgeries, which is the oldest JWT attack there is. The tool refuses it in any capitalisation rather than showing it as a decoded token with a tick.
Because that is the algorithm confusion attack. An RSA public key is public, so if a verifier can be talked into treating it as an HMAC secret, anyone can forge a token. The tool refuses the combination rather than doing what the header asks.
Check how the secret is being read. A secret published as hex or base64 is a sequence of bytes, not the characters that spell it: 64 hex characters are 32 bytes. Switch the encoding control under the key box and the digest changes.
Everything runs in your browser. The token and the key are never sent anywhere, and neither is put in the URL, the browser history or the shareable link. That said, a token in a shared screen or a screenshot is still a credential, so treat it like one.
exp is when the token stops being valid, iat is when it was issued and nbf is when it starts being valid. All three are Unix timestamps in seconds. The tool shows each as a date and says whether the token currently passes, allowing whatever clock leeway you set.
That is a JWE, an encrypted token, rather than a JWS. Its payload is ciphertext and cannot be read without the decryption key. The tool recognises the shape and says so rather than failing with a parse error.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.