JWT Decoder & Inspector
The problem: Debugging auth means pasting production JWTs into random decoder websites — leaking live tokens to unknown servers.
ASG Privacy VerifiedVerified
100% In-Browser Execution. Zero server uploads. Your data never leaves this tab — disconnect your internet and the tool keeps working.
JWT Decoder & Inspector: the complete guide
A JWT decoder unpacks JSON Web Tokens into their three readable parts — header, payload and signature — so you can inspect claims, check expiry and debug authentication without shipping the token to a third-party website. JWTs are the lingua franca of modern auth: OAuth providers, API gateways and session systems all issue them, and every one is a base64url-encoded JSON document hiding in plain sight. The problem is that 'decoding' on most of the web means pasting a live, sometimes production-privileged token into someone else's server — an unnecessary risk when the format is trivially decodable with browser APIs. This inspector splits the token on dots, decodes each segment with proper base64url handling and UTF-8 correctness, and renders the header (algorithm, type), the payload (subject, issuer, scopes) and the signature as raw bytes. Numeric claims like iat, exp and nbf are rendered as human-readable dates alongside their epoch values, and a live status badge tells you whether the token is expired or valid — computed locally, updated in real time.
Anatomy of the three segments
Every JWT is header.payload.signature, dot-separated and individually base64url-encoded. The header names the signing algorithm — HS256 for shared secrets, RS256 or ES256 for key pairs — and the token type. The payload carries the claims: registered ones like sub (subject), iss (issuer), aud (audience), iat (issued at), exp (expiry) and nbf (not before), plus whatever custom claims your system adds, from role arrays to tenant IDs. The signature is binary data that the issuer computed over the first two segments; this tool shows it as its raw base64url string and deliberately does not attempt to decrypt or verify it, because verification requires the signing key and has no business happening in a browser tool. Understanding the split matters for debugging: a token with a malformed payload section means truncation in transit, an undecodable header suggests a non-JWT opaque token, and a payload that decodes but lacks exp means your expiry logic depends on server state instead of the token.
Expiry, issued-at and not-before as human dates
JWT date claims are POSIX seconds — ten digits, unintuitive, and easy to misread by a factor of a thousand if milliseconds sneak in. The inspector converts iat, exp and nbf to full localized dates and times, and computes a live status: whether the token is currently expired, and if not, precisely how long remains until it is. That transforms common debugging conversations. 'Why did my API call fail?' becomes 'your token expired 14 minutes ago.' 'How long are our refresh tokens?' becomes a direct read of the exp minus iat difference. The nbf check catches the classic clock-skew problem where a freshly issued token is rejected because the client's clock is behind the issuer's. All date rendering uses your browser's own locale and timezone, so the times match what you see in your logs rather than forcing UTC arithmetic in your head. The status updates in real time — leave the decoded token on screen and watch it flip to expired at the exact second.
Why zero-server decoding is the security baseline
Decoding a JWT requires no secret — the first two segments are, by design, readable by anyone holding the token. But that cuts both ways: any website you paste a token into can also read everything in it, including user IDs, emails, role assignments, tenant identifiers and internal URLs. During debugging you routinely handle tokens for your own admin account, staging services or customer support sessions — pasting those into a random decoder site is a genuine data leak with no upside. This inspector runs the entire decode in your tab with atob, TextDecoder and JSON.parse. Load the page once and go offline: decoding continues to work, proving there is no telemetry path. Paste freely, inspect thoroughly, and rest assured the token's contents never exist anywhere except your machine's memory. For teams with security policies that forbid third-party tools for production data, this is the tool you can actually put in the runbook.
Practical debugging patterns
Three workflows cover most JWT debugging. First, expiry triage: paste the failing token, read the exp date and the live remaining-time badge — most auth failures are exactly this, and the fix is a refresh call you can now time precisely. Second, claim audits: decode the token your frontend received and confirm the roles, scopes or plan fields your API checks are actually present and spelled correctly; silent claim mismatches cause more authorization bugs than any cryptographic issue. Third, algorithm sanity: confirm the header says the algorithm your verifier expects — a token signed RS256 arriving at an HS256-configured verifier is a common misconfiguration with a one-line diagnosis here. A note on verification: this tool intentionally does not verify signatures, since doing so requires the secret or public key. Verification belongs inside your backend with a proper library; inspection here tells you what the token says, and your server decides what to trust.
Step by step: how to use JWT Inspector
- 1
Copy the complete JWT — all three dot-separated parts. Browser storage inspectors, curl responses and auth headers are common sources.
- 2
Paste it into the input area. The tool accepts tokens with or without the leading 'Bearer ' prefix.
- 3
Read the decoded header: confirm the algorithm (alg) and type (typ) match what your system expects.
- 4
Inspect the payload claims: subject, issuer, audience, scopes and any custom fields your application attaches.
- 5
Check the date claims — iat, exp, nbf are rendered as local dates with a live valid/expired badge and remaining time.
- 6
Copy any decoded section for your issue tracker, then fix the underlying flow: refresh the token, correct the claim, or align the algorithm.
Security & privacy
This inspector decodes tokens entirely within your browser using standard Web APIs — there is no server component to receive them and no telemetry around your input. Live tokens from production systems frequently carry user identifiers, roles and internal audience claims; here they never leave your device, and you can prove it by disconnecting from the network after the page loads and decoding offline. Signature verification is intentionally absent: it requires the signing key, which should never be pasted into any browser tool, and belongs to your backend runtime. The tool shows you what a token claims — your server, with the key, decides what is true.