Before You Paste That JWT: A Safe Debugging Checklist for Developers

JWTs are one of those things developers handle casually. You copy one from a request header, paste it into a decoder, check the payload, inspect the expiry, and move on.

That workflow is fast, but it can also be risky. A JSON Web Token is not encrypted by default. In most cases, it is only Base64URL encoded and signed. That means anyone with the token can decode the header and payload. If the token is still valid, anyone who obtains it may also be able to use it as a bearer credential.

Before pasting a JWT into any online tool, slow down for ten seconds and run through this checklist.

What a JWT Can Reveal

A JWT usually has three parts: header, payload, and signature. The header often contains the token type and signing algorithm. The payload contains claims. The signature proves the token has not been modified, assuming the server verifies it correctly.

header.payload.signature

The payload may include fields like this:

{
  "sub": "user_123",
  "email": "alex@example.com",
  "role": "admin",
  "scope": "read:users write:billing",
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "iat": 1762340000,
  "exp": 1762343600
}

That is already enough to expose user identity, roles, internal IDs, permissions, tenant names, or business context.

A JWT should not contain passwords, API keys, private tokens, database identifiers, full profile objects, or anything you would not want copied into logs, screenshots, issue trackers, or third-party tools.

The Safe JWT Debugging Checklist

1. Check Where the Token Came From

Before decoding the token, identify the source.

• Is this from local development?
• Is this from staging?
• Is this from production?
• Does it belong to a real customer or employee?
• Is it still valid?

Production tokens should be treated as secrets. Even if the payload looks harmless, the full token may still grant access until it expires or is revoked.

2. Decode Locally When Possible

For basic inspection, you do not need a server-side tool. JWT headers and payloads can be decoded directly in the browser. Use a tool that processes data locally, such as the Daily Drift Hub JWT Decoder, JSON Formatter, and Base64 Encoder.

• JWT Decoder: /tools/jwt-decoder/
• JSON Formatter: /tools/json-formatter/
• Base64 Encoder: /tools/base64-encoder/

The safest habit is simple: do not send sensitive tokens to a backend unless there is a strong reason.

3. Inspect the Header

Look for the algorithm.

{
  "alg": "RS256",
  "typ": "JWT"
}

• Avoid accepting unsigned tokens.
• Avoid weak or unexpected algorithms.
• Make sure your backend validates the expected algorithm.
• Do not trust the algorithm value blindly.

OWASP lists broken authentication as a major API security risk and calls out token validation problems such as accepting unsigned or weakly signed JWTs. Reference: https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/

4. Check Expiration

Look for the exp claim. A token without an expiration date is harder to contain if it leaks. A token with a very long lifetime increases the damage window.

• Does exp exist?
• Is the token already expired?
• Is the lifetime reasonable?
• Are refresh tokens handled separately from access tokens?

Use the Timestamp Converter at /tools/timestamp-converter/ to quickly convert Unix timestamps into readable dates.

5. Check Issuer and Audience

The iss and aud claims help prevent tokens from being accepted by the wrong service.

• iss: who issued this token?
• aud: which service is supposed to accept it?

Your API should reject tokens from unknown issuers and tokens meant for another audience.

6. Review Scopes and Roles

Claims like role, scope, permissions, or groups deserve extra attention.

• Overly broad scopes
• Admin roles in normal user tokens
• Internal permission names exposed to clients
• Tenant or organization IDs that should not be public

Avoid putting authorization logic only on the client. The server must enforce permissions on every protected endpoint.

7. Remove Sensitive Data From Payloads

JWT payloads often grow over time. A team starts with sub and email, then adds role, plan, workspace, feature flags, billing state, and profile metadata. That can become excessive data exposure.

OWASP warns that APIs can expose sensitive fields when they return more data than the client needs. The same principle applies to tokens and auth payloads. Reference: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/12-API_Testing/03-Testing_for_Excessive_Data_Exposure

Keep tokens small. Store only claims required for authentication and authorization.

8. Never Paste Live Tokens Into Tickets or Chat

When reporting an auth bug, do not paste a full live token into Slack, GitHub issues, Jira, or support chats.

• Redact the signature.
• Replace user identifiers.
• Use a short-lived test token.
• Include decoded claims only when needed.
• Share reproduction steps instead of credentials.

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.<redacted>.<redacted>

9. Verify Server Behavior

Decoding a token tells you what it contains. It does not prove your API validates it correctly.

• Expired tokens
• Tokens with modified payloads
• Tokens signed by the wrong key
• Tokens with the wrong issuer
• Tokens with the wrong audience
• Tokens missing required scopes

Use the API Request Builder at /tools/api-request-builder/ to test requests intentionally and inspect status codes, headers, and responses.

A Safer Debugging Workflow

• Copy the JWT from your browser or API client.
• Confirm whether it is production, staging, or local.
• If it is production, avoid pasting the full token anywhere.
• Decode it locally in the browser.
• Inspect alg, exp, iss, aud, sub, and scopes.
• Format the payload as JSON for readability.
• Redact sensitive values before sharing.
• Test server validation with expired or modified tokens.
• Rotate or invalidate the token if it was exposed.

Final Rule

A JWT is not just a string. It is often a credential, an identity document, and a snapshot of your authorization model.

Treat it like a secret first. Decode it carefully. Share it rarely. Keep the payload boring.

For quick inspection, use local, browser-based tools like the JWT Decoder, JSON Formatter, and Timestamp Converter so sensitive debugging data stays on your machine.