About the JWT Decoder
This tool splits a JSON Web Token into its header and payload segments, base64url-decodes each one, and shows the resulting JSON so you can read every claim the token carries.
It also translates the standard time claims, exp (expiration), iat (issued at) and nbf (not before), from raw Unix epoch seconds into human-readable dates, and flags exp as EXPIRED once that moment has passed. That turns a wall of digits into something you can check at a glance while debugging an auth flow, an OAuth or OIDC integration, or an API access token.
Decoding happens entirely in your browser: the token is split and its base64url segments are decoded locally, so nothing you paste, including a live production token, is sent to a server. The tool decodes only; it does not check the signature, so it tells you what a token claims, not whether those claims are authentic.
It only needs the token to split into at least two dot-separated parts to decode the header and payload, so a token missing its signature segment (header.payload with no trailing .signature) still decodes fine, since the signature itself is never inspected here.
How to use it
- Paste the JWT (the header.payload.signature string) into the input box.
- The token is split on its dots and each segment is decoded automatically as you type.
- Read the decoded header JSON to see the signing algorithm (alg) and token type (typ).
- Read the decoded payload JSON to see every claim the token carries.
- Check the highlighted line for issued, not-before and expiry times shown as readable dates.
- Confirm whether the token is expired from the explicit EXPIRED or valid marker next to exp.
- Copy specific claim values out of the decoded JSON as needed.
Examples
- Paste an access token and read its sub, role and scope claims straight out of the decoded payload.
- Check a token whose exp claim renders with an EXPIRED marker because its expiry time has already passed.
- Inspect the header to confirm alg is HS256 or RS256 before wiring up signature verification on the server.
- Decode an ID token from an OIDC login flow to read its iss, aud and email claims.
- Paste a token with only header.payload (no signature segment) and confirm it still decodes, since only two dot-separated parts are required.
- Strip the leading Bearer prefix off an Authorization header value before pasting, to decode the bearer token underneath.
What this tool checks, and what it deliberately does not
This is a decoder, not a verifier. It reads the header and payload because those segments are just base64url-encoded JSON, no key required. Verifying the signature is a different operation entirely: it needs the issuer's secret or public key, which a client-side browser tool should never be asked to hold, so that step is out of scope on purpose.
That distinction matters for security. A decoded payload shows you what a token claims, sub, role, exp and so on, but proves nothing about whether those claims are genuine. Anyone can construct a JWT-shaped string with any payload they like; only signature verification (done server-side, with the correct key) proves a token was actually issued by who it says.
- Decodes: header JSON, payload JSON, and exp / iat / nbf rendered as readable dates
- Does not decode or verify: the signature segment is never checked against any key
- Security implication: never treat a decoded payload as authenticated without separately verifying the signature server-side
The exp, iat and nbf claims explained
These three registered claims from RFC 7519 are all expressed in Unix epoch seconds, not milliseconds, which is the single most common source of confusion when a token is generated by hand or by a non-standard library.
- iat (issued at): the instant the token was created
- nbf (not before): the token is not valid before this instant, even though it already exists
- exp (expiration): the token stops being valid at this instant; this tool marks it EXPIRED the moment it passes
Common problems when decoding a JWT
Most decode failures come from the pasted string not being a clean, complete JWT rather than from the token itself being broken.
- "not a JWT" error: fewer than two dot-separated parts, usually because only a fragment of the string was copied
- "could not decode" error: the header or payload segment is not valid base64url or does not parse as JSON, common after the string was double-encoded, URL-encoded, or truncated mid-copy
- A literal Bearer prefix or surrounding quotes copied along with the value from an Authorization header or a JSON field
Frequently asked questions
What is a JWT (JSON Web Token)?
A JWT is a compact, URL-safe token made of three base64url-encoded parts, a header, a payload of claims and a signature, commonly used to carry authentication and authorization data.
Does this tool verify the JWT signature?
No. It only decodes the header and payload. Verifying the signature requires the issuer's key and is a separate step this client-side tool intentionally does not perform.
What is the difference between decoding and verifying a JWT?
Decoding reveals the readable claims inside a token. Verifying checks the signature against a key to confirm the token is genuine and unmodified. This tool only decodes.
Can I use this as a bearer token decoder for an Authorization header?
Yes. Strip the leading Bearer prefix and paste just the token value; the decoder works the same way on any JWT regardless of where it came from.
Is decoding a JWT the same as decoding a JSON Web Signature (JWS)?
A standard JWT is itself a compact JWS: header, payload and signature, all base64url-encoded and dot-separated. Decoding a JWT here is decoding that same structure.
Can I decode an OIDC ID token with this?
Yes. An OIDC ID token is a regular JWT, so it decodes the same way and shows claims like iss, aud, sub and email in the payload.
Is my token sent to a server?
No. The token is split and its segments decoded entirely in your browser, so it is never transmitted anywhere.
How can I tell if a token has expired?
Look at the highlighted line showing exp as a readable date; it is marked EXPIRED once that time has passed and valid otherwise.
Why do I get a "could not decode" error?
The header or payload segment is not valid base64url, or it doesn't parse as JSON once decoded, often from a truncated, double-encoded or otherwise corrupted copy of the token.
What does the alg field in the header mean?
It names the signing algorithm the issuer used, such as HS256 or RS256, which whatever system verifies the token needs to know before checking the signature.