JWT Decoder Guide: How to Read Headers, Payloads, and Claims Safely

A JSON Web Token commonly contains three period-separated sections:

header.payload.signature

Duck Cloud's JWT Decoder lets you inspect JWT headers and payloads locally without verifying the token.

Structure

A JWT typically contains:

1. header;
2. payload;
3. signature.

The payload contains claims such as exp, iat, nbf, iss, aud, and sub.

Base64URL

JWT sections use Base64URL-style encoding. Encoding is not encryption. Anyone who receives a normal JWT can usually inspect its header and payload.

Do not store secrets in claims just because the token looks unreadable.

Common claims

• exp: expiration time.
• iat: issue time.
• nbf: not-before time.
• iss: issuer.
• aud: intended audience.
• sub: subject.

Use JWT Expiry Checker and Unix Timestamp Converter for timing inspection.

Decoding is not verification

A malicious user can create a token containing "role":"admin". Readable claims are not trusted claims.

Production verification must enforce signature, trusted keys, allowed algorithms, issuer, audience, timing, and application-specific authorization.

JWKS and kid

Identity providers often publish public verification keys through JWKS. The JWT header may include kid to identify the signing key.

Authentication can fail during key rotation if cached keys are stale or the wrong issuer is configured.

Protect live tokens

Bearer tokens may grant account access. Do not put live JWTs in screenshots, public tickets, or logs.

Use short-lived test tokens when possible.

Troubleshooting workflow

1. Decode a safe test token.
2. Check issuer and audience.
3. Check timing claims.
4. Inspect kid.
5. Verify the signature using your maintained JWT library.
6. Separate authentication failures from authorization failures.

A JWT can be easy to read and still completely untrustworthy. Decode to understand it; verify before believing it.