How to Verify a JWT (Correctly)

Verifying a JWT is more than checking the signature. A correct verification pins the algorithm, validates the signature with the right key, and then checks the claims. Skipping any step is how real-world bypasses happen.

Updated 2026-06-12

1. Pin the algorithm

Decide which algorithm(s) you accept and enforce them explicitly. Never let the token's alg header decide — that is the root of the alg:none and RS256→HS256 confusion bypasses. Pass an explicit allow-list (e.g. ["RS256"]) to your verifier.

2. Verify the signature with the right key

HS256/384/512: a shared secret. Keep it long and random — weak secrets are brute-forceable.
RS/PS/ES:verify with the issuer's public key, typically fetched from a JWKS endpoint and selected by kid — but only against a trusted key set, never a key the token points to itself.

You can try this interactively in the Decode tab: paste a token, paste the secret or public key (or a JWKS URL), and the verification banner updates live.

3. Validate the claims

Even a perfectly-signed token can be invalid for your use. Check:

exp — reject expired tokens; nbf — reject not-yet-valid ones.
iss — the issuer is one you trust; aud — the audience includes your service.
sub and any authorization claims (role, scope) — but treat them as inputs to your own checks, not gospel.

Common mistakes

Trusting the header alg (enables alg:none / confusion).
Accepting an empty signature segment.
Not checking exp / aud / iss.
Fetching the verification key from a URL inside the token (jku/x5u).

Paste any token into the Audit tab to surface these risks automatically, framed as hypotheses to verify.

Generate the attack token →Decode a token All guides