Developer Tools
JWT Debugger
JWT Debugger is part of Toolspire and is ready as soon as this page loads. Paste a JSON Web Token to see its header and claims in plain language — who issued it, who it’s for, when it expires — and check its signature with a secret, PEM key, certificate or JWKS.
On this page
What you can do here
Claims in plain English
Every claim labelled — issuer, audience, scopes, roles — with dates converted and the time left until expiry.
Real signature check
Verifies with Web Crypto, the same cryptography your browser uses for HTTPS, for every common JWS algorithm.
Any key format
Secrets, PEM, PKCS#1, certificates, JWK or a JWKS from your identity provider — no conversion needed.
Security warnings
Flags unsigned tokens, embedded keys, long lifetimes and weak secrets before they cause trouble.
Private by design
Nothing leaves your device, so production tokens are safe to inspect.
Build tokens too
Switch to Encode & sign to create a test token, then verify it here in one click.
The sequence
How to decode and verify a JWT
- 1
Paste the token
Paste the JWT — a “Bearer …” header value works too. The header, payload and claims appear straight away.
- 2
Check the claims
Read who issued the token, who it’s for and when it expires; warnings appear above the claims.
- 3
Add the key
Enter the secret for HS256, or paste the public key, certificate or JWKS for RS256, ES256 and EdDSA.
- 4
Read the result
“Signature verified” means the token is authentic and unchanged; otherwise check the key or the token.
Worth knowing
- JWT Debugger on Toolspire: decodes the header and payload of any JWT, explains standard and common claims (iss, sub, aud, exp, nbf, iat, scope, roles …) and shows times in UTC and your local time.
- Shows whether the token is expired, not yet valid or still valid, with a live countdown.
- Verifies the signature for HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 and EdDSA (Ed25519) using your browser’s Web Crypto.
- Accepts keys as a shared secret (text, Base64, Base64URL or hex), PEM public or private keys, PKCS#1, X.509 certificates, a JWK or a whole JWKS, picking the key by kid.
- Warns about real security problems: alg “none”, keys or key URLs supplied by the token itself (jwk, jku, x5u), missing expiry, weak or well-known secrets and secrets placed in the payload.
- Runs entirely in this tab — tokens and keys are not sent to us or logged — and also decodes the header of encrypted JWE tokens.
Anatomy of a JWT
| Part | Contains | Example |
|---|---|---|
| Header | The signing algorithm and token type, Base64URL-encoded JSON | {"alg":"RS256","typ":"JWT","kid":"key-1"} |
| Payload | The claims: who the token is about, for whom, and how long it lasts | {"sub":"42","aud":"api","exp":1767229200} |
| Signature | Proof that header and payload came from the key holder unchanged | Base64URL bytes of an HMAC, RSA, ECDSA or EdDSA signature |
Decoding is not verifying
Anyone can decode a JWT — the header and payload are only Base64URL-encoded, not encrypted. That is why tokens must never carry passwords or other secrets. Verifying checks the signature with the right key, which proves who created the token and that nobody changed a single character.
A server should verify the signature, then check exp, nbf, iss and aud, and accept only the algorithms it expects. Never trust the alg value or a key that arrives inside the token itself. Public keys for providers such as Auth0, Okta, Microsoft Entra ID, Cognito and Firebase are published at a JWKS URL, usually ending in /.well-known/jwks.json.
FAQ
Questions about JWT Debugger
Where does JWT Debugger run?
Is it safe to paste a production token here?
Why does it say “Invalid signature”?
Where do I find the public key to verify RS256 tokens?
Can it decrypt JWE tokens?
Why are exp and iat such large numbers?
Keep going
Related tools
Last updated Report a problem or suggest a feature