JSON Web Token Decoder

JWT decoder for inspecting token headers, payloads, claims, and expiry

When an authentication flow returns 401, a token seems to expire too early, or a role‑based access check fails, the first debugging step is usually "what is actually in this token?" This JWT decoder splits the token into header and payload, decodes the Base64‑encoded JSON, and displays it with human‑readable timestamps — all in the browser. No token is ever transmitted; decoding happens locally.

The decoder shows the exp claim converted to your local timezone with a valid/expired badge, the iat (issued‑at) time, and all custom claims. It does not verify the signature — that requires the secret or public key — but it gives you the full decoded content so you can check what the token carries before investigating why it is not being accepted.

Who uses it

• Frontend developers — debug login loops, expired sessions, and missing role/permission claims without pasting tokens into random online tools.
• Backend and API developers — verify token structure during OAuth, OpenID Connect, and custom JWT integration testing.
• QA and support engineers — read token claims to confirm whether a 401 or 403 response is a token issue or an authorisation logic bug.
• DevOps and security teams — inspect token payloads during incident response and integration troubleshooting.

How to use it well

1. Copy the full JWT from browser devtools (Application → Local Storage or Cookies), an Authorization header, or a curl response.
2. Paste it into the input field. The decoder immediately splits the three dot‑separated segments and decodes the header and payload.
3. Check the exp timestamp against the current time. The tool shows a valid/expired badge — but also verify the server clock, since clock skew can cause false expired tokens.
4. Read the claims. Look for sub (subject/user ID), aud (audience), iss (issuer), scope, roles, and any custom claims your application expects.

Practical tips

• Never paste production tokens into a tool that sends data to a server. This decoder runs locally, but still verify the workflow for your team's security policy.
• Compare exp and iat with both the user's timezone and the server clock — a five‑minute clock skew can cause silent failures.
• Remember that decoding is not verification. A token that decodes successfully can still be tampered with if the signature is not validated with the correct secret or public key.
• Check the alg field in the header. If it is none, the token is unsigned and should not be trusted.

Common use cases

• Debugging OAuth and OpenID Connect login flows when tokens are not accepted
• Reading role, scope, tenant, and permission claims during API integration testing
• Checking whether a token is actually expired before blaming the backend
• Explaining authentication bugs to teammates with readable header and payload output
• Verifying token structure during incident response — is the token malformed, expired, or missing expected claims?

Privacy and browser‑side processing

This JWT decoder runs entirely in your browser. Tokens you paste are never transmitted, stored, or logged. That said, JWT tokens often contain personally identifiable information (email, user ID, name) and can grant access to production systems — follow your team's security policy when handling them in any tool.

Related searches and tools

People who use this JWT decoder often also need JSON Formatter (pretty‑print decoded token payloads for deeper inspection), Base64 Encoder (manually encode or decode Base64‑URL segments), and URL Encoder (safe‑encode parameters for OAuth redirect URIs). All three run in‑browser.