JWT Decoder & Inspector

A JSON Web Token is three Base64URL-encoded sections joined by dots: a header, a payload and a signature. The first two are ordinary JSON that has been encoded so it survives inside a URL, an HTTP header or a form field. Reading them needs no secret, which is what makes a JWT decoder possible at all — and also what makes the most important warning about JWTs so easy to forget.

This JWT decoder unpacks the header and payload of any token you paste, renders both as formatted JSON, converts the registered time claims into readable dates, and tells you whether the token is currently expired, not yet valid, or inside its window. A leading Bearer prefix is stripped automatically, and the signature is shown but clearly labelled as unchecked — because a decoder that implied verification would be a security trap.

The three parts of a JWT

Base64URL is standard Base64 with plus and slash replaced by hyphen and underscore and the padding removed, so the token is safe in a URL. Encoding is not encryption. Anyone holding a token can decode and read every claim, so a JWT payload is effectively public to whoever receives it.

Decoding a JWT is not verifying it

This tool unpacks the header and payload and shows them to you. It does not check the signature, because that requires the issuer's secret or public key, which your browser does not have and should not want. A token can be perfectly readable and completely forged. The only component entitled to trust a JWT is the one that verifies the signature with the correct key, and that check belongs on the server, never in client-side code alone.

The JWT claims that matter

Standard claims use short registered names:

• iss — the issuer that created the token
• sub — the subject, usually a user identifier
• aud — the audience the token is intended for
• exp — expiry, a Unix timestamp after which the token must be rejected
• nbf — not before, a timestamp before which it is not yet valid
• iat — issued at, the moment the token was created

The exp, nbf and iat values are integers counting seconds since the Unix epoch, so this tool converts them to readable dates and tells you whether the token is currently expired, not yet valid, or inside its window.

The algorithm-none trap

Because the header states which algorithm signed the token, a naive verifier that believes that field can be tricked by an attacker who sets the algorithm to none and drops the signature entirely. Serious libraries reject an unverified or downgraded algorithm and make you declare which algorithms you accept. It is a neat illustration of the whole subject: reading a token and trusting a token are two completely different operations, and only the second one is a security decision.

Debugging auth with a JWT decoder

Almost every "my token doesn't work" ticket ends the same way: someone decodes the JWT and reads the claims. The exp is in the past, or the aud does not match the resource server, or the issuer string has a typo, or the token is from the test tenant. A JWT decoder turns that hour of guessing into a thirty-second read — paste the token, look at the exp rendering, compare the iss and aud strings with what the server expects, and the problem usually names itself.

Decode JWT tokens locally, never upload them

Access tokens carry user identifiers, scopes, tenant names and sometimes personal data. Pasting a live token into a hosted decoder means handing that material — plus the token itself, which until expiry is a bearer credential — to whoever operates the site. This JWT decoder runs entirely in the browser: the token is split, Base64URL-decoded and rendered locally, and nothing is transmitted or stored. Decode, read, close the tab.

Common JWT decoder workflows

• "Is this token expired?" — the fastest answer to the most common question.
• "Which tenant or user is this?" — reading sub, tenant and custom claims during a support session.
• "What scopes did the auth server actually grant?" — comparing requested and granted scopes.
• "Why does the signature look wrong?" — inspecting the alg field before suspecting the key.
• "What did I just receive?" — understanding a token handed over by an unfamiliar integration.

Each one begins the same way: paste, decode, read. None of them requires the secret — which is precisely why decoding is safe to do anywhere, and verifying is not.