JWT Decoder

Look Inside Any JSON Web Token

JSON Web Tokens are the workhorse of modern authentication: compact strings that carry signed claims about a user from one service to another. Every JWT is three Base64URL-encoded segments joined by dots — a header describing the signing algorithm, a payload of claims, and a signature. When login breaks, a request returns 401, or you simply need to know what a token says about its bearer, the answer is inside those segments. This decoder opens them instantly: paste a token, read the JSON. Critically, it does so entirely in your browser — and with tokens, that is not a nicety but a requirement, because a JWT pasted into a server-side tool is a credential handed to a stranger.

How to Use It

1. Paste the JWT — with or without a leading Bearer prefix, which is stripped automatically.
2. Read the decoded header and payload as formatted JSON.
3. Check the claim summary: registered claims like iss (issuer), sub (subject), aud (audience) are labeled, and every timestamp claim — exp, iat, nbf — is translated from epoch seconds into a readable date.
4. The expiry verdict is computed live: a clear “expired 2 hours ago” or “valid for another 13 minutes” against your system clock.

The Decoder's Most Common Catch: Expiry

A remarkable share of real-world authentication bugs reduce to one fact the decoder surfaces in bold: the token is expired. Access tokens commonly live minutes to hours; a stored token from yesterday fails today with an unhelpful 401. Decode it, read the exp line, and the mystery evaporates. The neighboring claims solve the next tier of bugs: an aud naming a different service (token sent to the wrong API), an iss from the staging identity provider in a production request, a missing role or scope claim the endpoint requires. Thirty seconds in the decoder routinely replaces an hour of speculative debugging.

Decoding Is Not Verifying — Understand the Difference

The header and payload of a JWT are merely encoded, not encrypted: anyone holding the token can read them, exactly as this tool demonstrates. The signature is what makes a token trustworthy, and verifying it requires the issuer's secret or public key — deliberately outside this tool's scope. The practical rules follow directly: never put secrets in JWT payloads (they are readable by design); never treat decoded claims as authenticated until a server has checked the signature; and treat every token as a live credential — share screenshots of decoded payloads, not the token string itself, and prefer expired tokens in documentation. This decoder enforces the right habit by never transmitting your paste anywhere: the token's bytes stay on your machine from paste to close.

Small Conveniences That Add Up

• Whitespace and line breaks from copied logs are cleaned automatically.
• Malformed tokens produce a specific diagnosis — wrong segment count, illegal Base64URL characters — rather than a generic failure.
• Custom claims appear in full alongside the registered ones, formatted and copyable.

One final workflow tip: when reporting an authentication bug to a teammate or vendor, paste the decoded payload (with sensitive values redacted) rather than the raw token. It communicates everything relevant — issuer, audience, expiry, scopes — without handing anyone a usable credential, and it spares the recipient the decode step. Small courtesy, better security, faster resolution.