JWT解码器

What the JWT decoder is for

A JSON Web Token is the compact credential that rides in the Authorization: Bearer header of countless APIs, and when authentication misbehaves the first question is always “what is actually inside this token?” This tool splits a JWT apart, decodes its header and payload from base64url into readable JSON, and turns the numeric timestamp claims into human dates — all inside your browser. Reach for it when a request is being rejected as unauthorised, when you need to confirm which user or which scopes a token carries, when you are checking an expiry time, or when you simply want to understand a token someone handed you without pasting a live credential into a random website.

How a JWT is structured

A signed JWT is three base64url segments joined by dots, in the shape header.payload.signature. The header is a small JSON object that names the signing algorithm, such as HS256 or RS256, and the token type. The payload is a JSON object of claims: standard ones include iss (issuer), sub (subject), aud (audience), exp (expiry), iat (issued-at) and nbf (not-before), alongside any custom fields the issuer added. The signature is computed over the first two segments using the algorithm the header declares, and it is what lets a server prove the token was not altered in transit.

Base64url is a URL-safe cousin of ordinary Base64: it substitutes - and _ for + and / and normally drops the = padding, so a token can travel in headers and links untouched. This tool reverses that encoding on the header and payload, pretty-prints the resulting JSON, and converts the exp, iat and nbf values — which are Unix timestamps counted in seconds — into readable dates so you can see at a glance whether the token is still live. The algorithm field also hints at how the token would be checked: HS256 is a symmetric HMAC built on a shared secret, whereas RS256 and ES256 are asymmetric, where anyone can verify with the public key but only the issuer can sign with the private one.

Concrete examples and use cases

• Debugging a 401 response: decode the token and check whether exp has already passed — most “expired” bugs are really a clock or timezone slip.
• Confirming authorisation: read the scope or roles claim to verify the token grants what the endpoint actually requires.
• Checking identity: inspect sub and iss to confirm the token was issued to the right subject by the right authority.
• Spotting the alg: none trap: a token that claims no algorithm at all must be rejected outright by any correct verifier.

The critical caveat: decoding is not verifying

This is the gotcha that matters most. A JWT payload is only encoded, not encrypted, so anyone holding the token can read every claim inside it — never place a password or a genuine secret in a payload, and treat the whole token as a bearer credential to be protected in transit and at rest. Just as importantly, this tool decodes a token; it does not verify the signature. A readable payload tells you nothing about whether the token is authentic, because anyone can hand-craft a fake JWT with any claims they like. Only the issuing server, holding the secret or the public key, can validate the signature and confirm the token is trustworthy, and that check must always happen server-side on every request.

Everything stays on your device

Decoding happens entirely in your browser: the token you paste is never transmitted, never uploaded and never logged. That is exactly the behaviour you want from a JWT tool, because a real token is a live key to an account — pasting one into a server-side decoder would mean handing your credential to a stranger. Keeping the work local removes that risk completely and lets the tool run with your connection switched off. Our own platform uses signed session tokens for authentication, and the developer documentation explains how they are issued and how your integration should present and refresh them safely.