JWT Decoder & Inspector

A JSON Web Token (JWT, RFC 7519) is a compact way to carry a set of claims between two parties, most often to say who someone is or what an application may do for them. In its usual signed form it is one line of text made of three Base64url segments separated by dots: header.payload.signature. Servers issue them after login, and clients send them back, typically in an Authorization: Bearer header.

A JWT is self-contained, which is why it is convenient and also why it needs care: whoever holds a valid token can use it, and everything in a signed token can be read by whoever holds it.

1. Copy the whole token. If it came from an Authorization header, the "Bearer" prefix is optional here.
2. Paste it into the box above and choose Inspect token, or turn on live inspection.
3. Read the Overview for the status and time checks, then the Header and Payload tabs for the decoded JSON.
4. Open Security Analysis for findings, and Signature if you want to check the signature with a key you supply.

Decoding means splitting on the dots, reversing the Base64url encoding of each segment, and parsing the first two as JSON. No key is needed, which is the point: it shows readability, not authenticity.

The header describes the token. alg names the signing algorithm, typ is usually JWT, and kid hints at which key was used. Other parameters such as jku, jwk, x5u and x5c point to or carry keys, and crit lists extensions a verifier must understand. All of these are chosen by whoever made the token, so a verifier must not simply believe them.

The payload holds the claims. Some are registered with standard meanings, some are common conventions, and the rest are private to an application. This tool labels each claim as registered, common or custom, and never invents a meaning for a custom one.

• iss (issuer): who says they issued the token.
• sub (subject): who or what the token is about.
• aud (audience): who the token is meant for, as a string or an array of strings.
• exp (expiration time): the moment the token stops being acceptable.
• nbf (not before): the moment it starts being acceptable.
• iat (issued at): when it was issued.
• jti (JWT ID): a unique identifier. Having one does not by itself prevent replay.

Common claims such as scope, roles, client_id, azp, nonce and sid are conventions that differ between identity providers, so check your issuer's documentation.

exp, nbf and iat are NumericDate values: seconds since 1970-01-01 UTC, not milliseconds. A token whose exp equals or precedes the current time is expired, and one whose nbf is still in the future is not valid yet. A common bug is issuing milliseconds, which makes a token appear to expire thousands of years from now; the tool flags values that look like that.

The check here compares claims with this device's clock and is labelled claim-based. A token inside its window can still be forged, revoked or meant for someone else, and clock differences of a few seconds between machines are why many verifiers allow a small tolerance, which you can set explicitly.

Verification recomputes or checks the signature with a key and confirms that the token was made by a holder of that key and has not been changed. It is a different job from decoding. Even a successful verification establishes only that the signature matches the key you supplied. It does not establish that you should trust that key's owner, that the token is for your service, that it has not been revoked, or that it authorizes anything.

A well-known family of mistakes comes from letting the token choose how it is verified. An unsecured token with alg set to none carries no signature at all, and algorithm-confusion attacks re-sign a token with HMAC using a public key as the secret. A safe verifier decides in advance which algorithms and keys it accepts. This tool's optional verification follows that rule: the key you choose decides which algorithms are allowed.

A signed token (JWS) is readable but tamper-evident, with three segments. An encrypted token (JWE) hides its claims from anyone without the key and has five segments: protected header, encrypted key, initialization vector, ciphertext and authentication tag. There are also JSON serializations of both, which look like objects rather than a dotted string.

This tool decodes compact signed tokens, shows the protected header of compact encrypted tokens, and explains the JSON forms without decoding them. It does not decrypt anything.

• Wrong number of segments: a signed token has exactly three. Two usually means the signature was cut off; more than three can mean two tokens were pasted together.
• Invalid Base64url character: look for plus or slash signs (standard Base64 rather than Base64url), spaces or line breaks.
• Payload is not JSON: the segment decoded but the text is not an object, or it is encrypted or compressed.
• Signature does not match: check the secret's exact characters and encoding, including a stray trailing newline, and make sure you are using the right key for that issuer.
• Token looks expired or not yet valid: compare clocks, and confirm exp and nbf are in seconds.
• Looks like a random string: opaque tokens are not JWTs and cannot be decoded; the issuer validates them.

• Verify the signature on every token, with an explicit allow-list of algorithms and keys you configured, and reject alg: none.
• Check iss, aud, exp and nbf against your own expected values.
• Do not fetch keys from URLs inside the token, and do not trust keys embedded in it.
• Keep tokens short-lived and have a plan for revocation.
• Never put secrets or unnecessary personal data in a signed token.
• Use long random secrets for HMAC, and prefer asymmetric keys when many parties must verify.
• Do not log full tokens or put them in URLs.

For more background, read JWT explained.

• JSON Formatter for formatting and checking a decoded header or payload.
• Log Sanitizer for removing tokens and other secrets from logs before you share them.
• HTTP Security Headers Analyzer for the headers around your authenticated responses.
• CSP Analyzer for reviewing the policy that protects pages handling tokens.