JWT Token Validator: Real Signature Verification, Not Just Decoding
Decoding a JWT's payload tells you what it claims — verifying its signature tells you whether you can trust those claims came from whoever holds the secret. This tool does both: it decodes the header and payload for inspection, and recomputes the HS256 (HMAC-SHA256) signature against a secret you provide, giving a genuine valid/invalid result using the browser's native Web Crypto API.
Only HS256 is supported for verification — RS256/ES256 need actual key material, not a secret string.
Decoding vs. Verifying: A Critical Difference
Anyone can decode a JWT's payload — it's just base64, not encrypted. This is why a JWT should never contain secret data in its payload. But decoding tells you nothing about trust: verifying the signature is what actually confirms the token was issued (or at least signed) by someone who knows the secret, and that its contents haven't been altered since.
The Claim Sanity Checks
Beyond signature verification, this tool checks the standard timestamp claims for internal consistency: is the token expired (exp in the past), not yet valid (nbf in the future), issued with a future iat (often a sign of a clock or timezone bug), or configured so exp is before iat entirely (a genuinely broken token).
Why a 'Signature Doesn't Match' Result Isn't Always Malicious
The most common reason for a mismatch during debugging is simply typing the wrong secret — not tampering. If you're testing your own system, double check you're using the exact secret configured on the issuing server, including any encoding quirks (some systems base64-decode the secret before use, others don't).
Practical Examples
Confirming a Token Wasn't Tampered With
Verifying signature integrity.
- 1.Paste the token and your app's JWT secret
- 2.Result: Signature verified — matches this secret
- 3.Confirms the payload hasn't been altered since signing
Debugging an Expired Session
Understanding why a user got logged out.
- 1.Paste the token from a failed request
- 2.Check the exp claim's decoded timestamp
- 3.Confirm whether it's actually in the past
What Gets Checked
- HS256 signature: real cryptographic verification
- exp: expired or valid
- nbf: not-yet-valid check
- iat: future-dated issue time
- exp vs. iat: logical consistency
Good Use Cases
- Verifying a token is genuinely signed by your own service
- Debugging why an API is rejecting a seemingly valid token
- Checking expiration timestamps without writing a script
- Confirming a webhook or session token hasn't been tampered with
Frequently Asked Questions
How is this different from a basic JWT decoder?
A basic decoder just base64-decodes the header and payload — it doesn't tell you whether the token's signature is actually valid. This tool additionally recomputes the HS256 signature using a secret you provide and compares it, so you get a real valid/invalid answer, not just a readable payload.
Why can it only verify HS256, not RS256 or ES256?
HS256 is symmetric (one shared secret signs and verifies), which this tool can compute directly from a secret you type in. RS256/ES256 are asymmetric and need the actual public key (not just a string) to verify — pair this tool with the JSON Web Key Generator if you need to work with those algorithms.
What claim checks does it run beyond signature verification?
It checks exp (expired or not), nbf (not-yet-valid), whether iat is suspiciously in the future, and whether exp is set before iat (a token that expires before it was issued — a sign of a misconfigured issuer).
What does it mean if the signature says 'does NOT match'?
Either the secret you entered is wrong, or the token's header/payload was altered after signing (tampering), or the token was signed with a different secret entirely. It does not mean the token is definitely fraudulent — double-check you're using the exact secret the actual issuer uses.
Does a valid signature guarantee the token is safe to trust?
A valid signature confirms the token wasn't altered since it was signed with that specific secret — but you should still separately confirm the claims themselves make sense for your use case (correct issuer, not expired, expected audience) before trusting the token's content.
Is my token or secret sent anywhere?
No, decoding and signature verification both happen entirely in your browser via the Web Crypto API — nothing is transmitted, which matters since both are often sensitive.