手把手解码 JWT：三段结构与常见陷阱

A JSON Web Token looks like three random strings glued with dots, but each part is just encoded data. Learning to read it takes two minutes and pays off in every auth debugging session.

The anatomy of the three parts

Split the token on dots: header.payload.signature. Header and payload are JSON objects encoded with URL-safe Base64 — not encrypted. The signature is raw bytes produced by HMAC or an RSA/ECDSA operation over the first two parts.

You can decode the first two parts by hand: add padding, swap - for + and _ for /, then Base64-decode. Or simply paste the token into the JWT Decoder, which formats the JSON and flags standard claims.

Claims worth reading first

• exp — expiry time as a Unix timestamp. Convert it with the Timestamp Converter when a session dies mysteriously.
• iss and aud — who issued the token and who it is for. Mismatches cause most unexpected 401 responses.
• sub — the user or system subject the token authorizes.

Decoding is not verification

Anyone can decode a JWT — that is its design. Verification means recomputing the signature with the signing key and comparing it; a decoded token proves nothing. Never make authorization decisions from payload content alone.

Common debugging scenarios

• Expired-token errors: check exp against your server clock, not your laptop clock.
• Garbled signature: normal — it is binary data, not text.
• Wrong audience: compare aud with the value your API actually verifies.

The JWT Decoder shows the header, the formatted payload and claim-by-claim explanations entirely offline, so even production-shaped tokens are safe to inspect.