Decode JWTs Safely Without Cloud Debuggers
That production JWT in your clipboard? Decode it locally. Here’s what to check - and why random JWT websites are a bad habit.
We’ve all done it: copy a token from DevTools, paste it into the first JWT site that loads, squint at the payload. Five minutes later you remember that token can hit staging - or worse, production.
If it can call an API, treat it like a password. Decode and verify on your machine instead of feeding another SaaS form.
What’s inside a JWT
Three Base64URL chunks, separated by dots. Header (algorithm, type). Payload (claims). Signature (proof someone with the key signed it).
Reading the first two is cheap. Checking the signature needs a key or JWKS - and that check should stay local when you can swing it.
A workflow that doesn’t leak
- Drop the token into JWT Decoder and read the header and claims.
- Check
exp,nbf, andiatwith JWT Expiration Checker so you’re not debugging an already-dead token. - Got the signing key? Run JWT Verify for a local signature check.
- Close or clear the tab when you’re done - especially after touching real tokens.
Stuff that should make you pause
alg: none, or an algorithm swap you didn’t expect.- Scopes that are way too broad, or a missing
audcheck. - Tokens that live for days when the app should be using short-lived access tokens.
Where to go next
Longer walkthrough: Debug JWT in your browser. Topic hub: Learn: JWT. For a chained private flow, open the JWT workflow.