JWT Decoder
it only decodes,Signature not verified — so don't use it to judge whether a token is valid; it only shows what's inside.
A JWT consists of header.payload.signature . The first two are Base64URL-encoded JSON (readable), and the third is the signature. Only the first two are decoded here,The signature can't be verified without the key。
When to use it
- An API returns 401: check whether exp has already passed and how many minutes iat is from your local clock, ruling out plain expiry before touching any code.
- You want to see which claims the server actually issued (scope, roles, aud, custom fields) and what alg and kid the header carries — faster than reading docs and guessing field names.
When not to
- You need to know whether a token is genuine or tampered with. Decoding is Base64URL only: anyone can edit the payload and paste it back, so the server must verify the signature with a secret or a JWKS public key.
- You want to use the decoded roles or scope for access control in the frontend. Those claims are unverified — change one letter and you escalate privileges. Authorisation belongs on the server after verification; the UI may only hide entry points.
Decoding runs locally in your browser: the token is never uploaded, logged or sent anywhere. Limits: no signature verification and no checks of alg, iss, aud or revocation; only three-part JWS, not JWE (five-part encrypted tokens); validity is computed from your local clock and may be off; only decode production tokens on a page you trust.
Frequently asked
Is it safe to paste a JWT here?
Mostly, with caveats. Decoding runs in the page's JavaScript: no upload, no logging, no network request, and a refresh clears it. The exposure is outside the page — browser extensions, injected third-party scripts, a shared clipboard or history can all capture the token. A production access token is equivalent to a password, so troubleshoot with fake tokens where you can; if you must decode a live one, confirm the page is trustworthy and clear it afterwards.
With no signature check, what is this result good for?
Reading only: structure, claims, timestamps. It cannot prove who issued the token, whether it was revoked, or whether it is forged. Every security decision — allow, authorise, decrypt — must happen after the server verifies the signature and validates exp, nbf, iss and aud. The valid label shown here is one subtraction against your local clock; it does not mean the server will accept the token.
exp has not passed but the API returns 401 — why?
Four usual causes. Your machine's clock is a few minutes off, so the nbf or exp boundary fails. The server revoked the token or rotated keys (a JWT is stateless, so revocation needs a deny list or short lifetimes). aud or iss does not match, or the token type is wrong — an id_token used as an access_token. Or the gateway and the service disagree on time. Decoding can only rule out the clock-related causes.