JWT Decoder
Decode a JSON Web Token locally and verify its signature with your key.
How to use JWT Decoder
- Paste the token (with or without "Bearer ").
- Read the decoded header and payload, plus human-readable issued and expiry times.
- To verify the signature, paste the shared secret (HS256/384/512) or the public key (RS, PS, ES algorithms).
How it works
A JWT (RFC 7519) has three Base64URL parts: a header, a payload of claims, and a signature. Decoding only needs Base64URL, so anyone holding a token can read its claims; the signature is what proves it was not altered. Times like exp and iat are Unix seconds and are shown in UTC and your local time.
Verification uses the browser’s Web Crypto API (HMAC, RSASSA-PKCS1-v1_5, RSA-PSS and ECDSA). The token and key never leave the page, which matters because tokens often grant live access to real systems. Do not paste private keys anywhere: verification only needs the public key.
Frequently asked questions
Is it safe to paste a production token?
The token is decoded locally and never sent anywhere. Even so, treat live tokens as passwords: prefer expired or test tokens, and revoke any you think were exposed.
Why can anyone read the payload?
JWT payloads are encoded, not encrypted. Do not put secrets in them. Encrypted tokens (JWE) have five parts and cannot be read without the key.
What does "alg: none" mean?
The token is unsigned. Servers must reject such tokens; accepting them is a well-known vulnerability.
Which key do I need to verify?
HS256/384/512 use the same shared secret that signed the token. RS, PS and ES algorithms need the issuer’s public key, as PEM ("BEGIN PUBLIC KEY") or JWK. The example token is signed with the secret toolgix-demo-secret, which Try an example fills in for you.
Limitations
- Encrypted JWE tokens cannot be decoded.
- Certificates (BEGIN CERTIFICATE) must be converted to a public key first.
- EdDSA (Ed25519) verification depends on browser support and is not offered yet.
Last reviewed November 9, 2026. How we build and test tools.