JWT Decoder
This tool decodes JWTs — it does not verify signatures. A decoded token is not a validated token.
Max 100 KB · Decodes automatically as you type · Signature is displayed, never verified
Unsecured token (alg: none) — no signature segment is present.
Claims summary
No exp, iat, or nbf claims present in this payload.
Processed entirely in your browser — nothing is sent to a server.
A JSON Web Token (JWT) is a compact, URL-safe way to represent a set of claims — statements about a user or a session — as a signed string. It’s the format most APIs use for bearer tokens: after a user authenticates, the server issues a JWT that the client attaches to later requests, typically in an Authorization: Bearer <token> header.
A JWT has three dot-separated segments: header.payload.signature. The header identifies the signing algorithm (such as HS256 or RS256) and token type. The payload holds the actual claims — anything from a user ID to permission scopes to standard timing fields like exp. The signature is a cryptographic value computed over the header and payload using a secret or private key that only the issuing server holds.
The header and payload are plain JSON, but they aren’t stored as raw JSON text — each is encoded with base64url, a URL-safe variant of Base64 that swaps +// for -/_ and omits padding, so the token can travel inside a URL or header without extra escaping. Decoding a JWT is the reverse of that: split the string on its dots, base64url-decode the first two segments, and parse each as JSON.
That’s the entirety of what this tool does. It does not, and cannot, verify the signature — doing so needs the issuer’s secret or public key, which never appears inside the token itself and which this tool has no way to obtain. A token that decodes cleanly here could still be expired, forged, or rejected outright by the API it’s meant for; decoding only shows what a token claims, never whether those claims are trustworthy.
Three timing claims get dedicated treatment, since they’re what most debugging sessions come down to: exp (expiration time), iat (issued-at time), and nbf (not-before time). Each is a Unix timestamp in the payload — this tool shows the raw number next to a readable UTC date, and flags plainly, with an icon and text rather than color alone, when exp has already passed.
Examples
- Inspecting an expired session — paste a token from a failing request and check whether its exp claim has already passed before looking anywhere else.
- Debugging a permissions mismatch — an API returns 403 Forbidden; decoding the token shows the actual role or scope claims the client is sending, which may not be what the frontend assumed.
- Checking the algorithm header — confirming a token was issued with the expected alg (e.g. RS256) rather than something unexpected like none, which some libraries accept by default if not configured carefully.
Frequently asked questions
Does this tool verify the JWT's signature?
Is my token sent to a server?
connect-src to a small, explicitly approved list that does not include any endpoint this tool could send a token to, so there is no code path by which a pasted JWT could leave your device.What do exp, iat, and nbf mean?
exp is the expiration time, after which the token should be rejected. iat is when the token was issued. nbf ("not before") is the earliest time the token is considered valid. This tool shows the raw number next to a readable UTC date for each.What is an unsecured JWT (alg: none)?
"alg": "none" has only two dot-separated segments — header and payload — with no signature at all. RFC 7519 permits this for cases like an already-trusted internal pipeline, but a production API that accepts an unsecured token as if it were signed has a serious vulnerability: anyone could construct one with arbitrary claims. This tool decodes it and notes the missing signature explicitly.