JWT Verifier

A JSON Web Token (JWT) is only as trustworthy as its signature. Anyone can copy the header and payload of a token and re-encode them — what actually proves a JWT came from your server, unmodified, is the signature at the end. The JWT Verifier recomputes that signature from the token's own header and payload using the secret you provide, and tells you whether it matches — cryptographic proof, not just a decode.

This is deliberately different from the sibling JWT Decoder: that tool splits and pretty-prints a token's claims without touching the signature at all (useful when you just want to read what's inside). This tool's whole job is checking whether the signature is genuine.

How to use it

1. Paste the token into JWT to verify.
2. Enter the Secret (HMAC key) the token was signed with — the same key your server used with the JWT Encoder or your own signing code.
3. Read the Verification result. If the signature checks out (and the token is inside its valid time window), the decoded Header and Payload appear below it.

Leave Reference Time blank to check exp/nbf against the current time, or fill in a Unix timestamp / ISO 8601 date to check the token's validity at a specific instant — handy for confirming a token would have been valid when it was actually used.

What counts as invalid?

• Signature mismatch — the computed HMAC doesn't match the token's signature. Either the secret is wrong, or the header/payload was altered after signing.
• Expired — the exp claim is in the past relative to the reference time.
• Not yet valid — the nbf claim is in the future relative to the reference time.
• Malformed JWT — the token isn't three dot-separated, base64url/JSON-decodable segments.
• Unsupported algorithm — the header's alg isn't HS256, HS384 or HS512. This includes the classic alg: "none" attack (an unsigned token some libraries mistakenly accept) and any RSA/ECDSA (RS256/ES256/PS256) token, which needs the issuer's public key rather than a shared secret — see below.

Which algorithms are supported?

HS256, HS384 and HS512 — the HMAC family, where the same secret both signs and verifies. This matches the sibling JWT Encoder exactly, so any token it produces can be verified here. There's no algorithm selector: a verifier reads alg straight from the token's own header, so nothing to pick — a redundant selector would just be one more place for it to disagree with the token.

Asymmetric algorithms (RS256, ES256, PS256…) use a private/public key pair rather than a shared secret, so they aren't offered here; verifying one needs the issuer's public key against a server-side or key-management-aware verifier.

Is my secret safe here?

Yes. Verification runs entirely in your browser — the token, the secret, and the verdict never leave your device. Even so, treat this as a scratchpad: paste test keys, not real production signing secrets. The shareable-link feature deliberately excludes the token and secret; only the optional reference time can be carried in a link.

Why didn't the header/payload show up?

They only appear once the signature is fully verified — a valid computed signature and a token inside its exp/nbf window. If the verdict says invalid for any reason, the header and payload are withheld, since showing "decoded" content next to an invalid verdict invites trusting data that hasn't actually been proven authentic.