How to decode and verify a JWT

Three Base64url segments separated by dots. Reading one is trivial; verifying one is the part that matters.

A JSON Web Token has three parts: a header saying how it was signed, a payload of claims, and a signature. The first two are merely Base64url-encoded, not encrypted — anyone holding a token can read everything in it.

Step-by-step

1. Paste the token. Header and payload are decoded immediately, with the timestamps rendered as dates.
2. To verify, state the algorithm you expect and supply the key or secret.
3. Read the verdict.

Decoding is not verifying

Reading the claims tells you what the token says. It tells you nothing about whether the token is genuine — anybody can craft a token claiming to be an administrator. Only checking the signature against a key you trust establishes that.

Why the tool makes you state the algorithm

Because taking it from the token is a well-known vulnerability. The header is attacker-controlled: it is part of the token they hand you. Two classic attacks follow.

The first is alg:none — a token declaring it needs no signature. Libraries that trusted the header accepted them. This tool refuses alg:none outright, always.

The second is algorithm confusion. A token signed with RS256 is verified with a public key. If an attacker changes the header to HS256 and signs the token using that public key as an HMAC secret, a library that reads the algorithm from the header will verify it successfully — because the public key is, by definition, public. Requiring the caller to state the expected algorithm removes the whole class of attack, and there is a test in the suite that builds exactly this forgery and requires it to be refused.

Checking the claims

• exp — expiry. A valid signature on an expired token is still an expired token.
• iss and aud — who issued it and who it is for. A perfectly valid token issued for a different service is not valid for yours.

Frequently asked questions

Is my token sent anywhere?

No. Decoding and verification happen in your browser. Tokens frequently are credentials, so nothing on the page transmits one.

Why must I choose the algorithm rather than reading it from the token?

Because the header comes from whoever sent the token. Trusting it enables alg:none acceptance and algorithm-confusion attacks, where a token signed with a public key as an HMAC secret verifies successfully.

Can I edit a token's claims and re-sign it?

Only if you hold the signing key. Without it, changing any part invalidates the signature, which is the entire point.