JWT Decoder: Inspect Token Headers, Payloads, and Expiration

A JWT is a compact representation of claims. A commonly encountered signed JWT has three dot-separated parts:

header.payload.signature

The first two segments are encoded with Base64URL, which uses URL-safe characters. Encoding is not encryption. Anyone who receives an ordinary signed JWT can usually decode its header and payload without knowing a secret or private key.

A header often resembles this:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-2026-08"
}

Common header parameters include alg (the algorithm the token claims was used, such as RS256, ES256, or HS256), typ (an optional type indicator, commonly JWT), and kid (a key identifier that may help the verifier choose a public key).

The header is untrusted until signature verification succeeds. An attacker can construct a token that claims any algorithm or key ID. A secure verifier must enforce an allowlist of expected algorithms and select trusted keys according to policy — it must not blindly trust the header. If the decoder shows "alg": "none", that does not make the token legitimate; it indicates an unsecured token that most authentication systems should reject.

The payload contains claims, which are name-value pairs about the token or subject:

{
  "iss": "https://identity.example.com",
  "sub": "user_4821",
  "aud": "inventory-api",
  "iat": 1787068800,
  "nbf": 1787068800,
  "exp": 1787072400,
  "scope": "inventory:read"
}

Registered claims have standardized names such as iss, sub, aud, exp, nbf, iat, and jti. Public claims use collision-resistant names, and private claims are agreed upon by the systems that issue and consume the token. JWT does not dictate a universal authorization model — one provider might use a space-separated scope string, another an array named roles. Read claims according to the issuer's documented contract.

If a decoded payload contains a numeric exp value, the tool multiplies it by 1,000 to convert epoch seconds to milliseconds, builds a date, and compares that instant with Date.now() in the browser. It then shows whether the token is active or has already expired, rendering the date in your device's local time. When no usable exp value is present, it reports Token parsed successfully (No exp claim found).

This is useful for a quick diagnosis, but it is not complete validation: the device clock may be wrong; production validators may permit a small clock-skew tolerance; exp may have an invalid type; a token can be unexpired but forged; and nbf, iat, iss, and aud are not checked. A missing exp does not mean the token is permanent — the issuer may enforce expiry elsewhere.

Not every token is a three-part readable JWT. A signed token commonly uses JWS compact serialization with three sections. An encrypted JWE compact token commonly has five sections, and its protected content cannot be read without decryption material. An opaque access token may be a random-looking reference with no locally decodable JSON.

This decoder attempts to parse the first two dot-separated sections as JSON. It is intended for readable JWT headers and payloads, not JWE decryption or opaque-token introspection. A five-part encrypted token will not yield a normal payload here — its second section is not JSON, so decoding reports a failure.

Base64URL replaces characters that are awkward in URLs: - is used instead of +, _ is used instead of /, and trailing = padding is often omitted. The decoder converts the URL-safe alphabet back, restores the required padding, decodes the text with Unicode handling, and parses JSON. A generic Base64 decoder may fail if it does not account for these differences.

The decoded bytes must represent valid text that parses as JSON. Corrupted segments, invalid character encoding, or non-JSON data cause the tool to show a decoding error.

The decoder processes the pasted string in the browser and does not need a JWT parsing library from a remote service. Even so, bearer tokens are credentials. Prefer expired, revoked, redacted, or locally generated sample tokens for troubleshooting.

Avoid placing a live production token in screenshots, shared documents, chat messages, bug reports, or clipboard managers. If a live credential may have been exposed, revoke it or terminate the associated session according to your identity provider's procedure. Clearing a text box does not undo disclosure elsewhere.