JWT Debugger Guide: Decode, Inspect, and Debug JSON Web Tokens Safely

TL;DR — Paste any JWT into the JWT Debugger to instantly see the decoded header, payload, expiration time, and scopes. Everything runs in your browser — your production tokens never reach a server. For raw Base64 work, see the Base64 Converter; for nested JSON inside claims, the JSON Formatter.

Why JWT bugs are the worst kind of auth bugs

You ship a feature, QA passes, prod looks fine — then random users report being logged out, or worse, seeing the wrong role. The token looks right but something inside it isn’t. Without a fast way to inspect what’s actually in the JWT, you’re stuck reading server logs or attaching a debugger.

A JWT is just three Base64Url-encoded pieces glued with dots: header.payload.signature. The first two are plain JSON — readable in milliseconds if you have the right tool.

Anatomy of a JWT

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTcxNzE1NjgwMH0.signature
└────── header ─────┘ └─────────────── payload ─────────────────┘ └─sig─┘

• Header — algorithm (alg) and token type (typ). Watch for alg: "none", a classic vulnerability.
• Payload — the claims. Standard ones: iss (issuer), sub (subject/user ID), aud (audience), exp (expiry), iat (issued at), scope/roles.
• Signature — HMAC or RSA signature over the first two parts. Proves the token hasn’t been tampered with.

The 5 claims to check first when auth misbehaves

1. exp — the #1 cause of "random" logouts. Convert the Unix timestamp; if it’s in the past, the token is expired.
2. iss — issued by the right authority? Mismatched issuers between dev/staging/prod cause silent rejections.
3. aud — intended for your service? A token minted for the mobile app won’t work on the admin API.
4. scope / roles — does the user actually have admin, or did the role get stripped during refresh?
5. sub — the right user ID? You’d be surprised how often a shared dev account masks the bug.

Debug a JWT in 10 seconds

1. Copy the token from your network tab or Authorization header.
2. Open the JWT Debugger and paste.
3. Read the header and payload panes. exp/iat auto-convert from Unix time to human-readable dates.
4. Compare against what your code expects. Done.

Common JWT mistakes that bite

• Trusting JWT claims without verifying the signature. Anyone can mint a fake JWT. Always verify on the server before reading claims.
• Putting secrets in the payload. JWT payload is Base64, not encrypted. If it’s in the token, it’s readable. For encryption, use JWE — not JWS.
• Long-lived access tokens. 24h+ is a footgun. Use short access tokens (5–15 min) + refresh tokens.
• No clock-skew tolerance. Servers with 30s clock drift will reject perfectly valid tokens around the exp boundary.

Why pasting production JWTs into random sites is dangerous

The other big "free jwt debugger" sites send your token to their server for decoding. A leaked production access token grants whatever the user can do — read PII, charge cards, call internal APIs. The UtilToolkits JWT Debugger decodes locally with JavaScript. No network round-trip, no logging, no risk. Verify in DevTools Network tab.

FAQ

Is a JWT encrypted?

No — a standard JWS-format JWT is signed but not encrypted. Anyone with the token can read the claims. For encryption use JWE.

How do I check if a JWT is expired?

Decode it and compare the exp claim (Unix seconds) to the current time. The JWT Debugger does this for you and shows the time-to-live in human terms.

Can I verify a JWT signature in the browser?

Yes for HMAC if you have the secret, and for RSA/ECDSA if you have the public key. The debugger supports verification when you paste the key.

What’s the difference between JWT and OAuth?

OAuth is a delegation protocol; JWT is a token format. OAuth often uses JWT as the access-token format, but they solve different problems.

Auth-debugging toolkit

• JWT Debugger — decode, inspect, verify.
• Base64 Converter — for raw segment-level decoding.
• JSON Formatter — for unpacking complex claims.