Overview
Decodes JSON Web Tokens entirely in your browser: the header and payload are Base64URL-decoded and pretty-printed as JSON, and the exp and nbf claims are checked against your own clock, with iat shown for context. It is an inspector, not a verifier — signature validation deliberately stays on your backend, where the keys live.
How It Works
Paste the full three-segment token (a leading Bearer, surrounding quotes and stray whitespace or line breaks are stripped for you). The header (algorithm, key id) and the payload (every claim, standard and custom) render as formatted JSON, and a colour-coded status banner reports whether the token is active, expired or not yet valid, with the exact expiry translated into your local time and shown in ISO form; a token with no exp claim is reported as structurally valid with no expiry. Copy buttons sit under the header and payload, with a download for the payload JSON. Malformed input produces a specific error rather than a blank screen.
Step-by-Step Usage Guide
- Copy the Bearer token from your app's network tab or Authorization header.
- Paste the three-segment string into the input area.
- Read the decoded header and payload claims in the two panels.
- Check the status banner for the expiry verdict and exact expiration time.
Technical Specifications & Standards
Under RFC 7519 a JWS token is Base64URL(Header) . Base64URL(Payload) . Signature. The decoder repairs Base64URL padding, maps the URL-safe alphabet back, and UTF-8-decodes both readable segments; the signature segment is neither displayed nor checked, because verification requires the HMAC secret or public key that should never be pasted into a browser tool. Only the time claims receive special treatment: exp and nbf decide the status banner and iat is reported as an issue time, each converted from seconds to a real date, while iss, sub, aud and custom claims appear as raw JSON for you to read yourself. A non-numeric exp is flagged instead of guessed at, and a payload that is valid JSON but not an object (null, an array or a plain value) gets its own explanation.
Targeted Use Cases
- Debugging 401 errors by checking whether the exp claim has actually passed.
- Inspecting the roles, scopes, and tenant ids embedded in OAuth2 access tokens.
- Reading OpenID Connect ID token claims during federated-login troubleshooting.
- Comparing token contents across environments before blaming the wrong service.
Notes & Gotchas
- An ACTIVE verdict means only that exp has not passed and any nbf has — a forged payload with a future expiry still shows as active. Real verification needs your backend and its keys.
- Only exp, nbf and iat are interpreted. Issuer, audience, subject and custom claims appear as plain JSON; read them yourself rather than assuming the banner covers them.
- Five-segment JWE (encrypted) tokens are reported as encrypted by design — there is no readable payload to decode without the key.
- Use the Copy header and Copy payload buttons, or the payload download, if you need the JSON elsewhere.
Frequently Asked Questions
Does this tool verify cryptographic signatures?
No — deliberately. Verification requires your backend's secret or public key, and a browser tool is the wrong place to paste either. This is an inspector for claims.
Is it safe to paste a production token?
Decoding happens locally in browser memory and nothing is transmitted — there is no server. Still, treat live credentials with care and avoid pasting admin tokens casually.
Why does my token fail to decode?
The most common causes are missing dot separators or a truncated string. Encrypted JWE tokens (five segments) get a specific message because their payload is intentionally unreadable, and a segment that decodes but is not valid JSON, or a payload that is not a JSON object, is reported separately.
What does the status banner check?
The nbf claim first (a future value shows not yet valid), then exp, converted to your local date and time, with iat shown for information. No other claim influences the verdict.