JWT Decoder
Decode JSON Web Tokens to inspect the header, payload, claims, signature, and expiration status.
What the decoder shows you
Paste a token and it splits on the dots, Base64URL-decodes the first two parts, and parses each as JSON. Nothing is submitted — output appears as you type.
- Header and payload — pretty-printed side by side, each with its own copy button.
- Claim cards — one per payload key.
exp,iatandnbfrender as a readable local date with the raw epoch number underneath. - Expiry banner — green or red depending on whether
expis in the past. - Signature — shown as-is. It is displayed, not checked.
- Load Sample JWT — a valid HS256 token to poke at if you do not have one handy.
A token that is not three dot-separated Base64URL segments gets an explicit error rather than blank output.
Anatomy of a JWT
A JWT is three Base64URL-encoded JSON objects separated by dots: header.payload.signature. Only the signature requires the secret key — the header and payload are readable by anyone with the token.
// Header — algorithm and token type
{
"alg": "HS256",
"typ": "JWT"
}
// Payload — claims (user data + metadata)
{
"sub": "user_123",
"name": "Alice",
"role": "admin",
"iat": 1700000000, // issued at (Unix timestamp)
"exp": 1700003600 // expires at (1 hour later)
}
// Signature — verifies the token hasn't been tampered with
HMACSHA256(base64url(header) + "." + base64url(payload), secret)Standard JWT claims
| Claim | Name | Description |
|---|---|---|
| sub | Subject | Unique identifier of the user (user ID, email) |
| iss | Issuer | Who created the token (your auth server URL) |
| aud | Audience | Who the token is intended for (your API URL) |
| exp | Expiration | Unix timestamp after which the token is invalid |
| iat | Issued At | Unix timestamp when the token was created |
| nbf | Not Before | Token is invalid before this Unix timestamp |
| jti | JWT ID | Unique token ID, used to prevent replay attacks |
Decoding vs. verifying a JWT
Decoding just reads the header and payload — it requires no key and proves nothing about authenticity. Verification checks the signature against a secret (HMAC) or public key (RSA/ECDSA) to confirm the token was issued by a trusted party and hasn't been modified. Always verify tokens server-side before trusting their claims.
This page does the first half only. A decoded token that looks correct still tells you nothing about whether it is genuine — an attacker can craft any payload they like and it will decode just as cleanly here. Treat decoded output as a debugging aid, never as an auth check.
Where your token goes
Nowhere. Splitting, atob decoding, and JSON parsing all happen in this page, so a production access token pasted here is not transmitted anywhere. Open DevTools and watch the Network tab while typing if you would rather check than take our word for it.
Related token & encoding tools
Frequently Asked Questions
What is a JWT (JSON Web Token)?
A compact, URL-safe token made of three Base64URL-encoded parts joined by dots: a header naming the algorithm, a payload of claims, and a signature. It is the usual way an API tells a client who it is talking to.
Does this tool verify JWT signatures?
No — it decodes only. Verifying needs your HMAC secret or public key, and pasting a signing secret into any website is a bad idea. Verify server-side with your auth library instead.
Can I tell whether my JWT is expired?
Yes. If the payload has an exp claim, a banner shows expired or not expired plus the expiry date in your local timezone. Tokens with no exp claim show no banner.
Is it safe to paste my JWT here?
The token never leaves your browser, so nothing is transmitted. The wider caution still applies: a JWT is not encrypted, so treat any token you paste anywhere as readable.
Why can anyone read my token's payload?
Because Base64URL is encoding, not encryption. The signature stops the payload being altered, not read. Never put passwords or secrets in a JWT payload.