JWT Decoder Online — Inspect Headers, Payload & Expiry Free
What Is a JWT Token?
A JSON Web Token (JWT) is a compact, URL-safe token format used to represent claims between two parties. A JWT consists of exactly three parts separated by dots: a Header, a Payload, and a Signature. Each part is independently Base64URL-encoded, making the entire token safe to use in HTTP headers and URL parameters.
The Three Parts
- Header — Declares the token type (
JWT) and the signing algorithm (HS256,RS256, etc.). - Payload — Contains the claims:
sub(subject/user ID),exp(expiry),iat(issued at),iss(issuer), and any custom application data like roles or permissions. - Signature — A cryptographic hash of the header and payload using a secret key or private key. It proves the token hasn't been tampered with.
Common Use Cases
- API authentication — Issued after login and sent as
Authorization: Bearer <token>on subsequent requests. - OAuth 2.0 / OpenID Connect — ID tokens and access tokens in modern auth flows are typically JWTs.
- Stateless sessions — The server encodes session state into the token itself, avoiding server-side session storage.
Decoding vs Verifying
This tool decodes JWTs — it reads the contents of the header and payload. It does not verify the signature, which requires the secret key or public key used to sign the token. A decoded-but-unverified JWT can still reveal useful debugging information (user ID, expiry, issuer), but you should never trust unverified claims in a security-sensitive context.
Standard JWT Claims Reference
These registered claim names are defined in RFC 7519 and have well-known meaning across all JWT implementations:
| Claim | Full Name | Description |
|---|---|---|
iss | Issuer | Who created and signed the token (e.g. your auth server URL) |
sub | Subject | Who the token is about — usually the user ID |
aud | Audience | Who the token is intended for — the recipient must verify this |
exp | Expiration Time | Unix timestamp after which the token must not be accepted |
nbf | Not Before | Unix timestamp before which the token must not be accepted |
iat | Issued At | Unix timestamp when the token was created |
jti | JWT ID | Unique identifier for this token — used to prevent replay attacks |
Common Signing Algorithms
- HS256 / HS384 / HS512 — HMAC with SHA. Uses a single shared secret key for both signing and verification. Common in monolithic apps where the same service signs and verifies.
- RS256 / RS384 / RS512 — RSA with SHA. Uses a private key to sign and a public key to verify. Allows any service to verify tokens without holding the secret. Standard in OAuth 2.0 / OIDC.
- ES256 / ES384 / ES512 — ECDSA. Shorter signatures than RSA at equivalent security levels. Increasingly common in modern auth systems.
- none — No signature. Should be rejected by any properly configured server. Never accept tokens with
alg: none.
Why You Should Decode JWTs Locally
JWTs often contain sensitive data: user IDs, email addresses, roles, permissions, and session metadata. Pasting a production JWT into an online tool that sends data to a server is a significant security risk — the token could be logged, stored, or replayed against your API.
This tool decodes entirely in your browser using standard JavaScript — atob() and TextDecoder. No network request is made. Verify this yourself: open DevTools → Network tab, paste a token, click Decode — the network panel stays empty.
Privacy & Security
- No server calls — Decoding happens entirely in JavaScript on your machine. Your token is never transmitted anywhere.
- Works offline — Once the page is loaded, the tool works without an internet connection.
- GDPR-safe — No data is collected, stored, or processed on any server. No cookies are set by this tool.