JWT Verifier

About JWT verifier

A JWT signed with HMAC can only be trusted after the signature is recomputed with the shared secret. This page does that for HS256, HS384 and HS512 tokens, and separately checks the exp, nbf and iat time claims with an optional clock-skew allowance. It answers whether a token is authentic and whether it is currently usable.

How to use it

1. Paste the token into the JWT box, or select Load sample to fill a working example.
2. Enter the Signing secret and pick the Algorithm that your service uses, HS256, HS384 or HS512.
3. Set Secret encoding to UTF-8, Base64, Base64url or Hex to match how the secret is stored.
4. Adjust Clock skew allowance (seconds) from 0 to 3600 if you want leeway on time claims.
5. Select Verify signature and read the Signature card, then the Claims card for exp, nbf and iat.

A token signed with the secret s3cret

A token with header {"alg":"HS256","typ":"JWT"} and payload {"sub":"42","exp":1893456000}, signed with HS256 using the secret s3cret.

With secret s3cret and HS256 the signature verifies. With any other secret it reports no match. The exp claim, 1 January 2030 UTC, passes until then.

When to use it

• Working out whether an authentication failure is a bad signature or merely an expired token.
• Checking that the secret in a deployment matches the one that issued a token.
• Testing how much clock drift between services your time claims can survive by raising the skew allowance.
• Diagnosing a base64-encoded secret that was mistakenly treated as plain text.

Questions about JWT verifier

Why does the tool refuse when the header alg differs from my selection?

Trusting the token's own alg value is a classic attack, where a forger picks a weaker or none algorithm. So the algorithm always comes from you, and a mismatch is reported instead of silently verified.

Can it verify RS256 or ES256 tokens?

No. Those use public-key signatures and need the issuer's public key. This tool covers only the three HMAC algorithms, which share one secret between signer and verifier.

Why do I need to choose a secret encoding?

Some providers give the secret as Base64 or hex that must be decoded to raw bytes first. Using the wrong setting derives a different key, so a genuine token fails to verify.

Can a token verify but still fail?

Yes. The signature and the time claims are independent, so a token can be authentic yet expired, not yet active, or issued in the future. The Claims card reports each as Pass, Fail or Absent.

What does the skew allowance do?

It widens the acceptable window by that many seconds, so an exp just passed or an nbf a few seconds ahead still passes. It only affects the time checks, never the signature.

Related tools

• JWT DecoderDecode and inspect JWT tokens — view header, payload claims, expiry, and signature.
• HMAC generatorGenerate a keyed-hash message authentication code for any message and secret key using SHA-1, SHA-256, SHA-384 or SHA-512.
• File hash checkerHash a file with SHA-1, SHA-256, SHA-384 or SHA-512 and compare it against a published checksum.
• MD5 GeneratorGenerate an MD5 hash from text
• SHA GeneratorGenerate SHA-1, SHA-256, SHA-384, and SHA-512 hashes
• Bcrypt GeneratorGenerate a bcrypt hash from text