Debugging JWTs without leaking secrets
How to inspect JWT problems safely in logs, support tickets, CLI tools, screenshots, and incident channels without spreading bearer tokens.
JWT debugging often starts with someone pasting a token into chat. That solves the immediate mystery and creates a new incident candidate. Bearer tokens are credentials. If they enter Slack, tickets, screenshots, log search, browser history, or a third party decoder, they may remain accessible long after the bug is fixed. Safe debugging is a habit, not a tool preference.
Redact before sharing
Most JWT questions can be answered with the header and payload, not the signature, and often not even with full claim values. Replace sub, email, session identifiers, and tenant ids with stable placeholders. Keep timestamps, issuer, audience, algorithm, and kid because those fields usually matter. If the signature must be tested, use a staging token or a locally generated reproduction, not a live user credential.
A useful redaction format keeps structure visible:
{"iss":"https://issuer.example","sub":"user_123_redacted","aud":"api","exp":1770000000}
That is enough for most reviews of lifetime, audience, and claim shape. It is not enough for an attacker to replay the request.
Logs that help without hurting
Application logs should record verification outcome, issuer, audience, kid, algorithm, token age, and failure reason. They should not record the raw Authorization header. If you need correlation, hash the token or jti with a server side salt and log the hash. That lets you find repeated use without turning the log platform into a credential store.
Tooling habits
Prefer local decoding tools that do not send data over the network. Browser based decoders are fine for public examples, not production tokens. Shell history is another leak path: commands like jwt decode eyJ... can persist in history files. Use files with restricted permissions or paste into tools that explicitly avoid history. Clear clipboard managers when handling sensitive tokens.
Support and incident channels
Support teams need scripts for asking customers to redact tokens. Security teams need a standard snippet for incident rooms: no raw bearer tokens, no screenshots containing headers, no forwarding HAR files without scrubbing. HAR files are especially risky because they contain cookies, Authorization headers, URLs, and response bodies in one convenient bundle.
Practical workflow
When debugging, first reproduce with a test account. Capture the verifier error and token metadata. If production evidence is required, extract only the minimal fields with an approved scrubber. Store raw artifacts, if unavoidable, in the incident vault with expiry and access control. The discipline feels slow until the day a copied token becomes the second problem.