JWT Debugger & Decoder

Splitting Three Dots Into Something Readable

A JWT is structurally just three Base64url-encoded segments joined by dots — header.payload.signature — and that's exactly the shape the decoder operates on. It splits the token string on the two dot separators, converts each of the first two segments from Base64url padding to standard Base64 (replacing - with + and _ with /, then restoring the = padding Base64url strips out), decodes each with the browser's built-in atob(), and parses the resulting string as JSON. The header decodes to a small object declaring the signing algorithm — HS256, RS256, or ES256 being the common ones — and the payload decodes to the claims object: sub, iss, exp, iat, aud, plus whatever custom fields the issuer added. The signature segment is displayed as raw Base64url text rather than decoded, because unlike the other two segments it isn't JSON at all — it's a binary HMAC or signature output, and this tool deliberately never attempts to verify it, since real verification requires the secret or public key, which should never be typed into a browser-based tool.

Decoding One Token vs. Auditing an Entire Fleet's Tokens

Pasting a single token here and reading the result is effectively instant — the decode work is three string operations and a JSON.parse, negligible even on modest hardware. That single-token workflow doesn't scale to the kind of auditing task that comes up periodically: confirming that every service in a fleet issues tokens with a sane expiry window, or checking that no token anywhere in a log sample uses alg: none. At that scale, the right tool is a script — a few lines of Python using the base64 and json standard library modules, or a one-liner with a JWT CLI — run over a batch of captured tokens, with this decoder reserved for the follow-up step of eyeballing one specific token the script flagged as suspicious. The tool's job is fast single-token inspection; bulk auditing belongs in code that can loop.

Catching a Bad Token Before It Reaches Production

Decoding belongs earlier in the pipeline than most teams initially put it. During integration testing against an identity provider — Okta, Auth0, Keycloak, Azure AD — decoding the ID token and access token the provider actually issues, rather than trusting the documentation's example payload, catches mismatches (a missing scope, an unexpected audience, a shorter-than-expected expiry) before application code that assumes those claims are present ships to production. The same check fits naturally as a manual gate during code review of a new microservice's auth flow: decode a sample token, confirm the algorithm isn't none, and check that no sensitive data — a password, a full credit card number — has been accidentally embedded in the payload, which is unencrypted and trivially readable by anyone who intercepts the token. It is not, however, something to automate as a CI assertion against production tokens themselves, since that would mean storing or transmitting live bearer tokens through a build pipeline — the decoding step belongs in manual review and staging-environment testing, not in a job that handles real credentials.

Rules Worth Hardcoding Into Your Verification Layer

• Never treat decoding as proof of authenticity: A forged token with an arbitrary payload decodes perfectly cleanly — only cryptographic signature verification with the correct key catches a forgery, and this tool deliberately does not perform that check.
• Pin the expected algorithm server-side, never trust the token's own alg header: Historically, some libraries accepted alg: none or let an RS256 token be re-verified as HS256 using the public key as an HMAC secret — always hardcode the expected algorithm in your verification call.
• Compare exp and iat in the same units you generate them in: Both are Unix seconds, not milliseconds — comparing against Date.now() without dividing by 1000 makes every token look wrong by a factor of a thousand.
• Treat any real bearer token as a password, including in this tool: Decoding a token is harmless, but pasting a live production token into any tool, browser tab, or chat message exposes whatever access it grants until it expires.

Frequently Asked Questions