JWT Signer & Verifier

How to use

1. To sign: edit the payload, enter the secret, and copy the token.
2. To verify: paste a token and the secret it should have been signed with.
3. Check both the signature and the expiry — a valid signature on an expired token is still expired.
4. Use tokens made here for testing, not for production sessions.

Features

• HS256, HS384 and HS512, verified against the specification's published example.
• Verification reports signature and expiry separately.
• Rejects `alg: none` rather than accepting an unsigned token.
• Correct base64url — URL-safe alphabet, no padding.
• Runs entirely in your browser.

Frequently asked questions

Why does the decoder not verify, and this does?

Because verifying needs the secret, and asking for one changes what the page is. The decoder reads a token anybody can read and says plainly it has checked nothing. This page asks for the secret, does the check properly, and tells you what that costs — which is the honest way round.

Why is `alg: none` rejected?

Because it is the oldest JWT attack: strip the signature, set the algorithm to `none`, and a library that trusts the header accepts an unsigned token as valid. A verifier should decide which algorithm it expects, not read it from the token. This one only accepts HS256, HS384 and HS512.

My signature does not match. Why?

Usually whitespace or encoding. The signature covers the exact encoded header and payload, so a re-serialised payload with different key order or spacing produces a different token — even though the JSON means the same thing. Verify the token you were given, byte for byte, rather than one you rebuilt.

Related tools