How to Decode a JWT Safely

What a JWT contains

A common signed JWT has three dot-separated parts: header, payload, and signature. The first two are Base64URL-encoded JSON and can be decoded by anyone who sees the token. Encoding is not encryption.

The header describes metadata such as the signing algorithm. The payload contains claims. The signature allows a verifier with the correct key and rules to detect modification.

Decoding is not verification

A decoder can display claims but cannot prove they came from a trusted issuer. Applications must verify the signature, restrict accepted algorithms, identify the correct key, and validate claims such as issuer, audience, expiration, and not-before time.

Never make an authorization decision based only on decoded payload text. An attacker can create a plausible-looking payload and an invalid signature.

Handle tokens like credentials

JWTs commonly grant access and may contain personal or internal information. Avoid pasting live tokens into remote tools, tickets, chat, or screenshots. Prefer local decoding and use short-lived, redacted, or test tokens when demonstrating a problem.

Clock and claim pitfalls

Expiration values are usually NumericDate seconds since the Unix epoch. Allow only a deliberate amount of clock skew. Validate audience and issuer against fixed expected values instead of merely checking that those fields exist.