JWT Decoder
Decode and inspect JSON Web Tokens instantly. View header, payload, claims and expiry. All client-side.
Decode a JSON Web Token
Privacy note
Your token is decoded entirely in the browser. Nothing is sent to any server. Still, avoid pasting production tokens into tools you don't control — including this one.
Standard registered claims (RFC 7519)
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created and signed the token |
| sub | Subject | The principal the token is about (usually a user ID) |
| aud | Audience | Recipients the token is intended for; verifiers should reject mismatches |
| exp | Expiration | Unix time after which the token must be rejected |
| nbf | Not Before | Unix time before which the token is not yet valid |
| iat | Issued At | Unix time the token was created |
| jti | JWT ID | Unique identifier, useful for one-time-use or revocation lists |
Anatomy of a JWT
A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header is a small JSON object naming the signing algorithm (alg, e.g. HS256 or RS256) and token type (typ). The payload is another JSON object holding the claims — statements about the user and the token, such as who it is for and when it expires. The signature is computed over the first two parts using a secret (HMAC) or a private key (RSA/ECDSA); it is what lets a recipient trust the contents without a database lookup. Base64url is encoding, not encryption, so anyone can read the header and payload — which is exactly what this tool does. Never put secrets in a JWT payload expecting them to be hidden.
Why decode ≠ verify (and the alg=none risk)
Decoding a JWT just base64url-decodes the readable parts; it proves nothing about authenticity. Verifying recomputes the signature with the issuer's secret or public key and checks it matches — only then can you trust the claims. That is why this tool decodes but does not verify: doing so safely would require your signing secret, which you should never paste into a third-party site. The classic pitfall is the alg: none algorithm, which declares the token unsigned. Verifiers that honoured it could be tricked into accepting forged tokens, so always configure your library to reject none and to pin the exact algorithms you expect — never let the token's own header decide how it gets verified.
Common JWT claims
The seven registered claims in the table above are defined by RFC 7519, but only a few appear in most tokens. sub identifies the user, iss says who issued the token, and aud says who it is for — verifiers should reject tokens whose audience doesn't match their service. The time claims drive the lifecycle: iat records when the token was issued, nbf the earliest moment it is valid, and exp the moment it must be rejected. The expiry banner above reads exp and tells you whether the token is still live and how long remains. jti gives a unique ID, handy for one-time-use tokens or revocation lists. Everything else — names, roles, emails — are custom ("private") claims your application defines for its own needs.
Frequently Asked Questions
Find this useful?
These tools are free and ad-free. Support the project!