JWT Decoder
Paste a JSON Web Token to read its header and payload — decoding only, the signature is never verified.
This decodes only — it does not verify the signature. Anyone can read a JWT, so never trust an unverified token, and don’t paste production tokens or secrets here. Decoding runs entirely in your browser.
{
"alg": "HS256",
"typ": "JWT"
}{
"iss": "https://knidox.example",
"sub": "1234567890",
"aud": "knidox-web",
"name": "Ada Lovelace",
"admin": false,
"iat": 1717200000,
"nbf": 1717200000,
"exp": 1717203600,
"jti": "a1b2c3d4"
}| Issuer (iss) | https://knidox.example |
|---|---|
| Subject (sub) | 1234567890 |
| Audience (aud) | knidox-web |
| Expires (exp) | 1717203600Jun 1, 2024, 1:00:00 AM |
| Issued at (iat) | 1717200000Jun 1, 2024, 12:00:00 AM |
| Not before (nbf) | 1717200000Jun 1, 2024, 12:00:00 AM |
| JWT ID (jti) | a1b2c3d4 |
A JWT is three base64url parts joined by dots: header.payload.signature. This tool splits on the dots and base64url-decodes the header and payload into readable JSON, showing standard claims like exp and iat as dates. It only decodes — it never verifies the signature, so an unverified token proves nothing.
What a JSON Web Token contains
A JSON Web Token (JWT) is a compact, URL-safe string used to carry claims between systems — most often to prove who a user is after they sign in. It has three parts separated by dots. The header is base64url-encoded JSON that names the signing algorithm (for example HS256 or RS256) and the token type. The payload is base64url-encoded JSON holding the claims — the actual statements about the user or session. The signature is a cryptographic value computed over the header and payload with a secret or private key.
Because the header and payload are only base64url-encoded, not encrypted, anyone can decode and read them without a key — that is exactly what this tool does. The signature is what makes a JWT trustworthy: a server recomputes it with the correct key and rejects the token if it doesn’t match. Decoding a token is therefore not the same as trusting it. This tool deliberately stops at decoding and never claims a token is genuine.
Standard claims
The JWT specification reserves a small set of “registered” claim names so different systems agree on their meaning. The claims about time — exp, iat, and nbf — are stored as Unix timestamps (seconds since 1 January 1970 UTC), which is why raw JSON shows a large number like 1717203600 rather than a date. The tool converts those numbers to your local date and time and flags whether exp has already passed.
Common registered claims
Defined in RFC 7519. All are optional, but these seven appear most often.
| Claim | Name | Meaning |
|---|---|---|
| iss | Issuer | Who created and signed the token — often an identity provider URL. |
| sub | Subject | Who the token is about, usually a stable user ID. |
| aud | Audience | The recipient the token is intended for; a service should reject tokens meant for others. |
| exp | Expiration | Unix time after which the token must be rejected. |
| iat | Issued at | Unix time the token was created. |
| nbf | Not before | Unix time before which the token must not be accepted. |
| jti | JWT ID | A unique identifier for the token, useful for revocation or replay checks. |
Decoding is not verifying
The single most important thing to remember about a JWT is that reading it proves nothing. Anyone can craft a string with any claims they like and base64url-encode it; only a valid signature, checked against the correct key, tells you the claims are authentic and untampered. Never treat data from an unverified token as trustworthy, and don’t paste real production tokens or anything containing secrets into any online decoder — a live token is a credential. This tool runs entirely in your browser and sends nothing anywhere, but the safe habit is to decode only expired or example tokens.