JWT Decoder & Inspector — Free HTML CSS JS Snippet

A JSON Web Token is three base64url-encoded segments joined by dots: a header describing the signing algorithm, a payload carrying claims, and a signature proving the first two segments weren't tampered with. Debugging a JWT usually means copy-pasting it into some third-party website — this snippet does the same decoding entirely in the browser, with no network request and no token ever leaving the page.

Base64url is not the same as base64

JWTs use base64url encoding (RFC 4648 §5), which swaps + and / for - and _ and drops trailing = padding so the token is safe to embed in URLs and HTTP headers without escaping. The browser's built-in atob() only understands standard base64, so base64UrlDecode() first reverse-swaps those characters and re-pads the string to a multiple of four characters before calling atob(). The result is then run through TextDecoder('utf-8') on a Uint8Array built from the decoded binary string — a detail that matters because atob() alone mangles any non-ASCII characters in claim values (unicode names, for example) if you skip the byte-array round trip.

Splitting and rendering the three segments

decode() calls token.split('.') and immediately checks the result has exactly three parts. A token with the wrong number of segments is flagged as malformed rather than silently decoding garbage. Each of the three raw segments is also rendered as a colored inline chip in the .segments row so you can see visually which characters of the raw token correspond to header, payload, and signature — useful when comparing two tokens byte-for-byte.

Header and payload are parsed as JSON, independently

The header and payload segments are decoded and JSON.parsed in separate try/catch blocks. This means a JWT with a valid header but a corrupted payload (or vice versa) still shows you the segment that *did* parse correctly, with a clear message on the one that didn't — rather than a single try/catch around the whole token that would hide which half failed.

Expiry detection using the `exp` claim

Per RFC 7519, the exp claim is a Unix timestamp (seconds, not milliseconds) after which the token should be rejected by any consumer. The tool compares payload.exp against Math.floor(Date.now() / 1000) and flips the status badge to an amber "Expired" state when the token is past its expiry — a fast way to check "is this the stale token I've been debugging with all morning" without doing the math by hand.

Signature is shown, never verified

The signature segment is displayed raw as the third panel, but this tool makes no attempt to verify it — verifying an HMAC-signed token requires the shared secret, and verifying an RS256/ES256 token requires the issuer's public key, neither of which a client-side decoder should ever ask you to paste in. The note under the signature panel is intentional: decoding a JWT tells you what it *claims*, not whether it's authentic. Trusting a JWT's contents always requires signature verification on a server that holds the correct key.

Claim chips for common fields

Below the three panels, decode() builds small chips for whichever of alg, typ, iat, exp, and sub are present, formatting the Unix timestamps into a readable UTC string via fmtTime(). This gives an at-a-glance summary without having to mentally parse the raw JSON for the fields you check most often when debugging an auth issue.