How to inspect JWT tokens safely

A JWT is three segments

Most signed JWTs contain a Base64URL-encoded header, a Base64URL-encoded payload and a signature separated by periods. The first two segments are readable, not encrypted.

Decoding is not verification

A decoder can display claims but cannot prove who issued them. Verification must check the signature, allowed algorithm, issuer, audience and time-based claims with trusted key material.

• Never grant access based on decoded text alone
• Reject unexpected algorithms
• Check exp and nbf
• Avoid pasting production tokens into server-backed websites

Debug with minimal exposure

Use short-lived development tokens, redact identifiers in screenshots and prefer a local browser decoder when a real token must be inspected.

Inspect a token whose signature is deliberately invalid

This synthetic token is intentionally unsigned in any meaningful sense: its final segment is the word signature. JWT Decoder can still expose the header and payload. Successful decoding demonstrates that the segments contain readable data; it does not demonstrate a valid signature or an authenticated user.

Change the sub claim in a locally constructed payload and the decoder will show the changed value as well. Authorization must come from a verifier that checks the permitted algorithm, signature, issuer, audience and time constraints against an application's trusted configuration. Never accept the token's own algorithm label as the entire verification policy.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFkYSIsImlhdCI6MTUxNjIzOTAyMn0.signature

{
  "header": {
    "alg": "HS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "1234567890",
    "name": "Ada",
    "iat": 1516239022
  },
  "signature": "signature"
}

Separate inspection from authentication

XXF's decoder parses the first two segments and displays the third; it does not validate the token structure for use as a credential or fetch verification keys. It is useful for debugging serialization and claims, not for deciding whether a request should be granted access.

Use a synthetic token when reporting a bug. Even though decoding runs in the tab, a real bearer token can be exposed through a screenshot, clipboard history, browser extension or public issue. Revoke an accidentally shared token through the issuing system rather than assuming that hiding its decoded view invalidates it.

• Keep real bearer tokens out of bug reports
• Treat every displayed claim as untrusted
• Verify signatures in the consuming application
• Check issuer, audience and time constraints after verification