JWT Decoder
Decode a JWT's header and payload, with expiry status and registered claims called out.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
The signature can't be verified here — that requires the issuer's secret or public key, which never leaves their server.
How to use the JWT Decoder
- Paste a JSON Web Token — the three dot-separated parts, header.payload.signature.
- Read the decoded header and payload as formatted JSON.
- Check the registered claims, such as issuer, subject, and expiry, and the badge showing whether the token has expired.
About the JWT Decoder
A JWT (JSON Web Token) is a compact, URL-safe token used for authentication and authorization — most login sessions and API tokens use this format. It's made of three Base64URL-encoded parts separated by dots: a header (describing the signing algorithm), a payload (the actual claims, like user ID or expiry time), and a signature (which proves the token hasn't been tampered with).
This tool decodes the header and payload back into readable JSON, entirely in your browser, and highlights common registered claims — issuer, subject, issued-at, and especially expiration — so you can quickly check what a token contains or why an API is rejecting it as expired. It does not and cannot verify the signature, since that requires the issuer's private secret or key.
Worked example
Example: decoding the sample token `eyJhbGciOiJIUzI1NiJ9...` reveals a header of `{\"alg\":\"HS256\",\"typ\":\"JWT\"}` and a payload containing the subject and issued-at claims — exactly what any HS256-signed token would expose once decoded, even without the signing secret.
How a JWT is put together
The header and payload are JSON objects, each encoded with Base64URL and joined with a dot. The signature is computed over exactly those two encoded parts. With HS256, it's an HMAC using a shared secret; with RS256 or ES256, it's made with the issuer's private key and checked with their public key. Change a single character of the payload and the signature no longer matches, which is why a server can trust a token it verifies — and why decoding alone proves nothing about who created it.
This tool expects the common signed form with three parts. Encrypted tokens (JWE) have five parts and can't be read without the decryption key.
Debugging a rejected token
When an API answers 401 Unauthorized, the decoded token usually shows why. Check these in order:
- exp: has the token expired? The status shown here uses your device's clock.
- nbf and iat: a token issued 'in the future' often means the server's and client's clocks disagree. Many servers allow a minute or two of leeway.
- aud: does the audience claim match the API you're calling? Tokens for one service are often rejected by another.
- iss: is the token from the issuer and environment you expect, such as staging rather than production?
- Scopes or roles: is the permission the endpoint needs actually in the payload?
Security reminders
Anyone holding a JWT can read it and usually use it until it expires, so treat tokens like passwords: don't put them in URLs, logs, or screenshots. Never put secrets in the payload. On the server, always verify the signature with a fixed list of accepted algorithms, and never accept the 'none' algorithm, which some older libraries allowed by mistake.
Frequently asked questions
- Is decoding a JWT the same as verifying it?
- No — decoding just reads the Base64URL-encoded JSON in the header and payload, which anyone can do without any secret. Verifying confirms the signature was produced by the expected issuer using their secret or private key, which this tool deliberately doesn't attempt, since that secret should never be pasted into a third-party website.
- Why shouldn't I paste a JWT with sensitive data into an online tool?
- A JWT payload is only Base64URL-encoded, not encrypted — anyone who has the token can already read its contents, including this decoder. This tool runs entirely client-side and never sends your token anywhere, but as a habit, avoid pasting tokens from production systems into any site unless you've confirmed it doesn't transmit data.
- What do exp, iat, and nbf mean?
- These are standard (registered) claims defined by the JWT spec: iat is when the token was issued, exp is when it expires and should no longer be accepted, and nbf ('not before') is a time before which the token isn't valid yet. All three are Unix timestamps in seconds, which this tool converts to readable dates.
- Why does decoding fail with 'invalid Base64URL-encoded JSON'?
- This usually means the pasted text isn't a complete JWT — a common cause is copying only part of the token, extra whitespace or line breaks getting included, or pasting something that isn't a JWT at all (like an opaque API key). A valid JWT always has exactly three dot-separated segments.