🔐 JWT Decoder

A JSON Web Token is three Base64url-encoded parts separated by dots: a header, a payload, and a signature. This decoder splits the token, decodes the header and payload, and pretty-prints them as JSON. It also shows the signing algorithm, the token type, and whether the payload’s time claims place the token in the past or future. It does not verify the signature, and it cannot tell you whether a token should be trusted.

How to Use

1. Paste a token into the input field. Decoding starts as soon as the field contains something.
2. Read the token info row: algorithm, type, expiration status, and the expiry date if one exists.
3. Inspect the header and payload panels, which show the decoded JSON.
4. Read the signature panel, which shows the raw Base64url segment. Copy anything you need from the panels by selecting it.

If the input is empty the panels hide. If the token is malformed, an error message explains whether the header, payload, or overall format is at fault.

What the Three Parts Contain

• Header — a small JSON object describing how the token was signed. The alg field names the algorithm (for example HS256 or RS256) and typ is usually JWT. A kid may identify which key was used.
• Payload — the claims. Registered claims include iss (issuer), sub (subject), aud (audience), exp (expiry), nbf (not before), iat (issued at), and jti (token id). Applications add custom claims such as roles or a user id.
• Signature — the cryptographic output. It is binary and Base64url-encoded, so the decoder shows it as a string rather than as JSON.

Base64url is a URL-safe variant of Base64: it uses - and _ instead of + and /, and padding = is commonly omitted. The decoder restores padding before decoding.

Decoding Is Not Verification

This is the most important limitation. Base64url decoding is reversible and needs no key at all, so the header and payload are readable by anyone who has the token — they are not secret and not encrypted. A token can be fabricated with any payload the author chooses, and it will decode here perfectly. The decoder never checks the signature, never validates iss or aud, and never rejects a weak algorithm. A token whose header declares "alg":"none" decodes without complaint, which is precisely why decoded content must never drive an authorization decision. Trust comes only from verifying the signature with the correct secret or public key and validating the expected claims on the server.

Reading exp, nbf, and iat

JWT time claims are NumericDate values: seconds since the Unix epoch in UTC, not milliseconds. exp is the moment the token expires, nbf is the earliest moment it may be used, and iat records when it was issued. The decoder compares exp and nbf to your local clock and labels the token valid, expired, or not yet valid, and it renders the expiry as a readable date. Because the comparison uses your machine’s clock and is purely informational, a device with the wrong time can show a misleading label. A token with no exp claim never expires by this check and is labeled valid — again, that is an absence of evidence, not proof of safety.

Worked Example

Take the canonical example token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The header decodes to {"alg":"HS256","typ":"JWT"}, so the algorithm shows as HS256 and the type as JWT. The payload decodes to {"sub":"1234567890","name":"John Doe","iat":1516239022}, an issued-at time of 22 January 2018. There is no exp and no nbf, so the status reads valid and the expiry shows no expiration. The signature panel shows the final segment as raw text. Nothing in that output proves the token was signed by anyone in particular.

Had the payload also carried an exp, the label would track that timestamp rather than the token’s content: the same string would read valid until the expiry moment and then flip to expired, with no change to the token itself.

Common Decoding Errors

• “Invalid JWT format: expected 3 parts.” The most frequent error. It means the dot-separated structure is broken — a truncated paste, a token copied with an HTTP Bearer prefix still attached, surrounding quotes, or a token with only two segments.
• “Invalid header: not valid base64 encoding.” The first segment contains characters that are neither Base64url nor the restored padding, which usually points to a partial copy or a token type that is not a JWT.
• “Invalid header: not valid JSON.” The segment decodes from Base64url but the resulting text is not JSON. This can happen if the wrong segment was placed first, or if the token was altered.
• A five-segment value. That is a JWE (encrypted token), not a signed JWT. Its content is ciphertext and cannot be read without the decryption key, so this decoder will reject it.
• Percent-encoded input. If the token arrived through a URL and still contains %2E or similar escapes, the dots are hidden and the split never happens. Decode the URL first.

The decoder strips whitespace before parsing, so line breaks from a wrapped copy are safe; almost every other failure comes from extra or missing characters.

Related Tools

• JWT Encoder
• Base64 Encoder
• JSON Formatter
• Hash Generator