JWT Token Decoder & Claims Inspector
Decode a JWT's header and payload, inspect its claims and expiration, and verify an HS256/384/512 signature against your own secret — all in your browser.
Header
{
"alg": "HS256",
"typ": "JWT"
}
Payload
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
Signature (raw)
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Claims
- sub (Subject)1234567890
- nameJohn Doe
- iat (Issued at)2018-01-18 01:30:22 UTC
Enter a secret above to verify an HS256/384/512 signature.
About this tool
How to use it
- Paste a JWT (the full string, all three dot-separated parts) into the input box.
- The header and payload decode instantly into readable JSON, with every claim also listed individually below — timestamps like exp, iat, and nbf are converted to a readable date and a relative time.
- Check the banner above the segments for whether the token is currently valid, expired, or not yet valid, based on its exp/nbf claims.
- To verify a signature, paste the shared secret the token was signed with into the Verify field — this only works for HS256/HS384/HS512 (shared-secret) tokens, not RS256/ES256 and other asymmetric algorithms.
Why it matters
A JWT's payload is only base64url-encoded, not encrypted — anyone holding the token can already read it, which is exactly why decoding it here (entirely in your browser) doesn't expose anything an attacker with the token couldn't already see. What's harder to see at a glance is whether the claims are what you expect: is this token actually expired, does it have the audience/issuer you think it does, and — if you hold the signing secret — was it actually signed with that secret and not tampered with.
When to use it
Debugging why an API is rejecting a token — checking its exp/nbf claims and payload contents directly instead of guessing. Confirming a token your own backend issued has the claims you expect before shipping the code that reads them. Verifying a shared-secret (HS256) token wasn't tampered with, when you control the signing secret.
Good to know
Signature verification uses the browser's own Web Crypto API (SubtleCrypto HMAC) and only supports HS256/HS384/HS512 — algorithms that sign with a shared secret. RS256, ES256, and other asymmetric algorithms need the public key, not a secret, to verify, and are correctly reported as unsupported rather than silently skipped or faked. Nothing you paste — token or secret — is sent anywhere; decoding and verification both run locally.
Common questions
Is my token or secret sent to a server?
No. Decoding uses the browser's built-in base64 and JSON functions, and signature verification uses the browser's own Web Crypto API — both run entirely in your browser tab. Nothing is uploaded, logged, or stored.
Why can't it verify my RS256 token?
RS256 (and other asymmetric algorithms like ES256, PS256) sign with a private key and verify with a matching public key — there's no single 'secret' to check against. This tool only verifies HS256/HS384/HS512, which use one shared secret for both signing and verifying, and says so plainly rather than pretending to check something it can't.
The payload decoded fine but it says the signature doesn't match — is the token fake?
Not necessarily fake — it means the signature doesn't match the exact secret you entered. Double-check you're using the same secret the issuer actually signed with (a common mistake is a trailing space, wrong encoding, or an old/rotated secret).
What does 'not yet valid' mean?
The token has an nbf ("not before") claim set to a time in the future — the issuer deliberately made this token unusable until that moment, often for scheduled access or clock-skew tolerance testing.
Why does decoding work even though I don't have the signing key?
A JWT's header and payload are base64url-encoded, not encrypted — decoding them requires no key at all, which is also why a JWT should never contain secrets you don't want the token holder to read. Only the signature step needs a key, and only to check integrity, not to unlock the readable content.