JWT Decoder
Decode the header and payload of any JSON Web Token, with registered claims explained and timestamps converted to readable dates. Everything happens locally — nothing is sent anywhere.
Photo by FLY:D on Unsplash
JWT decoder
Never paste a production token here or anywhere else. A JWT is a bearer credential: anyone holding it can act as you until it expires. This tool decodes entirely in your browser and sends nothing anywhere, but the habit of pasting tokens into web forms is the risk. Use a test token.
Registered claims
Key takeaways
- A JWT is signed, not encrypted — anyone holding it can read every claim in the payload.
- All JWT time claims are in seconds since the Unix epoch; milliseconds are the most common bug.
- Pin the expected algorithm server-side: trusting the header's alg field is how the none and algorithm-confusion attacks work.
The three parts of a JWT
A JSON Web Token is three base64url-encoded segments joined by dots:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 header
.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFkYSJ9 payload
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1 signature- Header declares the signing algorithm (
alg) and the token type (typ), sometimes with a key identifier (kid). - Payload holds the claims — statements about the subject and the token itself.
- Signature is computed over the first two segments with a secret or a private key. It proves the token has not been altered.
Base64url is encoding, not encryption. Anyone who has the token can read the payload, exactly as this page just did. Never put passwords, card numbers or anything else confidential in a JWT. If you need secrecy, you need JWE, not JWS. See hashing vs encryption vs encoding.
Registered claims
RFC 7519 reserves seven claim names. None are mandatory, but validators should check the ones present.
| Claim | Name | Purpose |
|---|---|---|
iss | Issuer | Who created the token. Verify it matches the authority you trust. |
sub | Subject | Who the token is about — usually a user ID. |
aud | Audience | Who the token is for. Reject tokens issued for another service. |
exp | Expiration | Unix seconds after which the token must be rejected. |
nbf | Not before | Unix seconds before which it is not yet valid. |
iat | Issued at | When it was created; useful for age policies. |
jti | JWT ID | Unique identifier, used to build a revocation list. |
All time claims are seconds since the Unix epoch, not milliseconds — a frequent source of tokens that expire in 1970 or in the year 56,000. Convert them with the timestamp converter.
Signing algorithms
| Family | Examples | Key | Use when |
|---|---|---|---|
| HMAC | HS256, HS384, HS512 | One shared secret | A single service issues and verifies its own tokens |
| RSA | RS256, RS384, RS512 | Private signs, public verifies | Third parties must verify without being able to issue |
| ECDSA | ES256, ES384, ES512 | Private/public elliptic curve | Same as RSA with much smaller signatures |
| EdDSA | Ed25519 | Private/public | Modern default where supported |
| None | none | — | Never in production |
RS256 is the norm for OpenID Connect because the identity provider publishes a public key set (JWKS) that every relying party can fetch. HS256 is simpler but means every verifier can also forge tokens.
The four ways JWT implementations fail
- Accepting
alg: none. The classic 2015 vulnerability: a library that trusts the header lets an attacker strip the signature. Always pin the expected algorithm server-side rather than reading it from the token. - Algorithm confusion. An attacker changes RS256 to HS256 and signs with the public key as the HMAC secret. Libraries that pick the verification method from the header are vulnerable.
- No expiry, or no revocation path. A stateless token stays valid until
exp. Keep access tokens short-lived (5–15 minutes), use refresh tokens for longevity, and keep ajtideny-list for emergencies. - Storing tokens in localStorage. Any XSS on the page can read it. Prefer
httpOnly; Secure; SameSite=Strictcookies, and see the escaping guide for the XSS side of the problem.
When not to use JWTs
JWTs are excellent for stateless, cross-service authorisation. They are a poor fit for ordinary server-rendered session management, where a random opaque session ID plus a server-side store is simpler, smaller, instantly revocable and much harder to get wrong.
Ask two questions. Does anything actually need to verify this token without calling your database? Can you tolerate a token remaining valid after you revoke access? If the answers are no and no, a session cookie is the better engineering choice.
Frequently Asked Questions
Is a JWT encrypted?
No. A standard JWS token is signed, not encrypted, and the payload is plain base64url that anyone can read. Encryption requires the separate JWE format.
Can this tool verify the signature?
No, and deliberately so. Verification needs the shared secret or the issuer's public key, and pasting either into a web page would be a serious mistake. Verify server-side with a vetted library.
Why does my token show as expired?
The exp claim is in seconds since the Unix epoch. Values supplied in milliseconds decode to dates tens of thousands of years in the future, and values off by a factor of 1,000 the other way decode to 1970.
Where should I store a JWT in a browser?
In an httpOnly, Secure, SameSite cookie. localStorage is readable by any script on the page, so a single XSS flaw hands over the token.
How long should a JWT last?
Access tokens: 5 to 15 minutes. Refresh tokens: days to weeks, stored server-side and revocable. Long-lived access tokens cannot be revoked without extra infrastructure.
What does alg: none mean?
It declares an unsigned token. It exists in the specification for cases where integrity is protected by another layer, but accepting it from a client is a critical vulnerability.
Is it safe to paste a token into this page?
The decoding happens entirely in your browser and nothing is transmitted. Even so, use test tokens: treating production credentials as safe to paste anywhere is the habit worth avoiding.
Sources & further reading
- RFC 7519: JSON Web Token — the token format and registered claim definitions
- RFC 7515: JSON Web Signature — how the signature is computed and verified
- OWASP: JWT cheat sheet — the algorithm confusion and none-algorithm attacks
- RFC 8725: JWT Best Current Practices — the IETF's consolidated security recommendations