How to Decode a JWT and Read Its Claims

A JSON Web Token (JWT) is a compact string that carries JSON claims between parties. APIs often send access tokens as JWTs so a resource server can read subject, roles, and expiry without a database hit on every request — when the signature is verified with the right key.

The wire format is three Base64URL parts joined by dots:

header.payload.signature

• Header — typically algorithm (alg) and type (typ: JWT)
• Payload — claims such as sub, iss, aud, exp, iat, plus custom fields
• Signature — integrity check bytes (still encoded); verifying needs the secret or public key

Open the JWT decoder and paste a sample token to see each part. Pretty-print claim JSON with a JSON formatter when you copy payload fields into notes.

Each segment is Base64URL-encoded. Decoding header and payload yields JSON objects. The signature segment is not “the password”; it is a cryptographic check over header.payload using the algorithm named in the header.

Header examples

• alg: HS256, RS256, ES256, and others
• typ: usually JWT
• kid: key id when multiple signing keys rotate

Payload examples

• sub — subject (user or service id)
• iss — issuer
• aud — audience
• exp — expiration (Unix time)
• iat — issued-at
• nbf — not-before

Custom claims are allowed; treat them as application data. Anything in the payload is readable to anyone who has the token — JWT is not encryption unless you use nested JWE patterns.

For the encoding layer underneath, read how Base64 (and variants) work. JWTs use Base64URL: - and _ instead of + and /, and padding is often omitted.

Decode only reverses encoding so you can read JSON. Verify checks that a trusted party signed the token and that critical claims (issuer, audience, time) pass policy.

• Anyone can craft a JWT-shaped string with a fake payload
• A decoder will happily show those fake claims
• Without signature verification against the correct key, claims are untrusted input

Common verification steps (in your app, not only in a browser toy)

1. Parse and validate structure.
2. Verify signature with the issuer’s JWKS or shared secret.
3. Reject surprising alg values (especially none).
4. Check exp, nbf, iss, aud against your rules.
5. Authorize using scopes/roles only after the above succeeds.

Online decoders that do not ask for a key are decode-only by design — useful for inspection, incomplete for auth. Production libraries in your language should perform verify. Decoding in DevTools while debugging is fine; skipping verify in the API is not.

Time claims are usually Unix timestamps in seconds since the epoch. A token with exp in the past should be rejected by verifiers. Decoders often highlight expired vs active status for quick triage.

• exp — stop accepting after this instant (with optional small clock skew)
• nbf — do not accept before this instant
• iat — when the token was issued; useful for session age and revoke windows

If a log shows a raw number and you need a calendar time, follow the Unix timestamp guide. Mixing seconds and milliseconds is a frequent bug: JWT numeric dates are seconds; JavaScript Date.now() is milliseconds.

Debugging “invalid token” errors

Check clock skew between laptop and server, wrong environment’s signing key, audience mismatch, and copied tokens that were truncated in chat apps. Decode first to see claims; then verify in the stack that issued the error.

Standard Base64 and Base64URL are siblings. URL-safe alphabets avoid characters that break query strings. Padding = may be stripped in JWTs. If you manually decode a segment with a generic Base64 tool, you may need to restore padding or switch to a URL-safe mode.

• Split on . — you should get three parts for a typical JWS JWT
• Decode part 1 and part 2 as Base64URL → UTF-8 JSON
• Leave part 3 as opaque signature bytes unless you are implementing crypto

Practice generic encode/decode via the Base64 tools when needed, but prefer a dedicated JWT decoder so header/payload split and claim formatting are automatic.

Malformed JSON inside a payload means a corrupt token or a non-JWT string. Validate structure before you assume claim names.

Tokens can grant access. Treat them like session cookies.

• Prefer staging tokens when you only need structure demos
• Use client-side decoders so the string is not uploaded if the tool is honest about local processing
• Redact screenshots: subject ids, emails, and internal URLs still leak from payloads
• Do not log full tokens in shared production logs if policy forbids it
• Rotate if a live access token was pasted into an untrusted channel

Signature algorithms and key handling belong in your auth service. Hashing tools can illustrate digests for teaching but do not verify a JWT by hashing the payload alone — verification follows the JWS algorithm with the correct key material. See the hash generator only for separate digest experiments, not as a JWT verifier.

User identifiers inside tokens are often UUIDs; for ID format context, see the UUID guide.

Use this flow when an API returns 401s or a client stores a token you need to inspect.

1. Copy the full JWT string (all three segments, no spaces).
2. Open the free JWT decoder.
3. Paste the token into the input.
4. Read the header: algorithm and type should match your issuer’s docs.
5. Read the payload: subject, roles/scopes, and custom claims.
6. Check expiration status and compare exp/iat to wall-clock time if needed.
7. Remember: readable claims ≠ verified claims — confirm signature verification in your application.

If the paste fails to parse, you may have a truncated token, a Bearer prefix still attached, or an encrypted JWE (different structure). Strip Bearer if present and confirm you are looking at a three-part JWS JWT.