JWT Decoder Explained: Read the Header, Payload and Expiry

JSON Web Tokens (JWTs) are compact strings commonly passed in an HTTP authorization header or a cookie. They look opaque, but the first two sections are normally Base64URL-encoded JSON that can be read during debugging.

What the three JWT sections mean

A JWT has three dot-separated segments:

header.payload.signature

The header describes how the token was created. It often contains alg, the signing algorithm, and typ, which is commonly JWT. Some systems also include kid, a key identifier used by the issuer to select a public key.

The payload contains claims: data about the subject, issuer, audience, permissions or session. Common registered claims include:

• iss — who issued the token
• sub — the subject or user identifier
• aud — the intended audience
• exp — the expiry time
• iat — when it was issued
• nbf — the time before which it should not be accepted

The signature is the value used by a verifier to detect whether the signed content was changed. It is not readable JSON, and simply displaying it does not prove that it is valid.

How to inspect a token safely

1. Copy a test token or a token from a local development environment.
2. Open the JWT Decoder and paste the three-part value.
3. Read the header and payload, then check the human-readable dates for exp, iat and nbf.
4. Compare iss and aud with the values your API actually expects.

The decoder runs Base64URL decoding locally and displays the signature text for reference. It does not send the token to a server and it does not verify the signature.

Decoding is not authentication

Anyone who receives a JWT can usually decode its header and payload. Base64URL is an encoding, not encryption. A decoded claim such as role: "admin" is only a statement in an untrusted string until the server verifies the signature, issuer, audience and time limits.

For real authentication, let the API use a trusted JWT library, the issuer’s signing keys and the algorithm policy for that service. Never decide authorization from values that a browser decoded on its own. Also avoid pasting a live production token into any third-party debugging site; use a short-lived test token with no sensitive claims instead.

Common expiry mistakes

JWT date claims are normally Unix timestamps in seconds, not milliseconds. A token can also be technically unexpired but rejected because its nbf is in the future, its aud does not match the API, or the server clock differs from the issuer clock. Small clock-skew allowances belong in the verifier’s configuration, not in a client-side decoder.

If the tool reports invalid Base64URL characters or the wrong number of segments, check for copied quotation marks, line breaks, a missing dot, or a token that is not a JWT at all. Do not “repair” a production credential by hand; obtain a fresh test token from the correct environment.