Developer guide

JWT decoding versus signature verification

A JWT can be readable and still be untrusted. Here is what each step tells you when debugging authentication.

Decoding reads the token

A compact JWT has three dot-separated parts: header, payload, and signature. The first two parts are Base64url-encoded JSON. Decoding them reveals fields such as alg, sub, iss, aud, and exp. Anyone holding the token can decode those fields; they are not encrypted.

For example, a decoded exp value lets you inspect the token's stated expiration time. It does not establish who created the token or whether its contents were changed.

Verification checks authenticity

Signature verification uses the signing key and the expected algorithm to check that the signed header and payload have not been altered. Your application must obtain the key from a trusted source and restrict acceptable algorithms according to its configuration. Never accept an algorithm merely because the token header requests it.

A valid signature is only part of validation. Check the expected issuer (iss), audience (aud), expiration (exp), and any relevant not-before (nbf) or application-specific claims. Apply an appropriate clock tolerance and follow your identity provider's key rotation guidance.

Which step should you use?

• Debugging: Decode a token to inspect its structure and timestamps. Treat every displayed claim as untrusted.
• Authorizing a request: Verify the signature and validate required claims with a maintained JWT library on the server or in the trusted application component.
• Sharing an example: Use a synthetic token or redact credentials. A real bearer token can grant access while it remains valid.

Payload Haven's inspector decodes the header and payload locally in your browser. It does not verify signatures.