JWT Decoder
Paste a JSON Web Token and read its header and payload as formatted JSON, with expiry and issue times shown as dates and a note on whether the token is currently valid. Decoding happens entirely in your browser, which matters when the token is a live credential.
0 characters · 0 words · 0 lines
0 characters · 0 words · 0 lines
Runs entirely in this browser tab. Your text is never uploaded or stored.
Registered claims
The seven claim names defined in RFC 7519 §4.1. All are optional; times are seconds since 1970-01-01 UTC.
| Claim | Meaning |
|---|---|
iss | Issuer: who created and signed the token |
sub | Subject: the user or entity the token is about |
aud | Audience: who the token is intended for |
exp | Expiration time: reject the token after this moment |
nbf | Not before: reject the token before this moment |
iat | Issued at: when the token was created |
jti | JWT ID: unique identifier, used to prevent replay |
Common alg values
| alg value | Meaning |
|---|---|
HS256 | HMAC with SHA-256; one shared secret signs and verifies |
RS256 | RSA PKCS#1 v1.5 signature with SHA-256; private key signs, public key verifies |
PS256 | RSA-PSS with SHA-256 |
ES256 | ECDSA on the P-256 curve with SHA-256; short signatures |
EdDSA | Ed25519 or Ed448 signatures |
none | Unsigned token; servers should reject it |
Inside a JSON Web Token
JWT is defined in RFC 7519 (May 2015), which suggests pronouncing it like the English word "jot". The common signed form is three Base64url strings joined by dots: header.payload.signature. The header names the signing algorithm in alg, such as HS256 or RS256, and often a key ID in kid. The payload holds claims, JSON fields such as sub (the user), iss (the issuer), aud (the intended audience) and exp, nbf and iat, which are times in seconds since 1 January 1970 UTC. The decoder converts those three to your local time and ISO 8601, and tells you whether the token has expired, is not valid yet, or is inside its window.
Base64url is an encoding, not encryption, so anyone holding a token can read its payload exactly as this page does. Never put passwords, card numbers or other secrets in claims. A token with five dot-separated parts is a JWE, an encrypted token; its contents cannot be read without the key, and the decoder says so. A leading "Bearer " copied from an Authorization header is removed automatically.
Why the signature is not verified here
The signature proves that the header and payload were produced by someone holding the key and have not been changed since. Checking it needs that key: the shared secret for HMAC algorithms like HS256, or the issuer's public key for RS256, ES256 or EdDSA. Pasting a production signing secret into any web page is a bad idea, and a decoder that pretends to vouch for a token without one would give false comfort, so this tool shows the signature but does not verify it. Treat what you see as a claim the token makes, not as fact.
Verification belongs on your server, using a maintained library with the expected algorithm pinned. Two historic mistakes explain why: accepting alg "none", which lets anyone forge an unsigned token, and algorithm confusion, where a server expecting RS256 is tricked into checking an HS256 signature using the public key as the HMAC secret. A decoder is for debugging: seeing which claims a provider issues, spotting a wrong audience, or finding out that a session failed because exp passed a minute ago. To read the Base64url segments raw, use the Base64 decoder.
Frequently asked questions
- Is it safe to paste a real access token into a JWT decoder?
- On this page the token never leaves your browser. Still, a valid token works as a password until it expires, so prefer expired or test tokens and keep live ones out of screenshots and chats.
- Why does my token show as expired when it was just issued?
- Check your device clock first. Some issuers give access tokens a lifetime of only a few minutes, and a token copied from a log may be older than it looks. An exp written in milliseconds instead of seconds does the opposite and lands thousands of years ahead.
- Can someone change the payload of my JWT?
- They can edit and re-encode it, but the signature will no longer match. A server that verifies signatures with the right key and algorithm rejects the altered token.
- What is the difference between JWS and JWE?
- A JWS (RFC 7515) is signed, has three parts and anyone can read it. A JWE (RFC 7516) is encrypted, has five parts and only the key holder can read the payload.
- Does logging out invalidate a JWT?
- Not by itself. A signed JWT stays valid until exp unless the server keeps a denylist or checks a session record, which is why access tokens are usually given short lifetimes.