JWT Decoder

The decoder splits a three-part compact token into header, payload, and signature segments. It Base64URL-decodes the first two segments, parses their JSON, and displays the signature segment without checking it. RFC 7519 defines JWT as a compact claims representation; common registered claims include iss, sub, aud, exp, nbf, iat, and jti. Decoded claims are readable, but not automatically trustworthy.

Decoding is useful for examining what an application received before investigating verification failures:

• Inspect alg, kid, and typ header parameters used during key and algorithm selection.
• Review subject, issuer, audience, roles, scopes, and application-specific claims.
• Convert NumericDate claims such as exp, nbf, and iat from epoch seconds into readable dates.
• Compare token claims with the issuer, audience, and authorization rules expected by an API.
• Remember that every displayed header and claim remains untrusted until the token is verified.

A token might decode to header {"alg":"HS256","typ":"JWT"} and payload {"sub":"123","iss":"https://issuer.example","aud":"api","exp":1916239022}. The tool can show the expiration time and compare timestamp claims with the current clock. An authentication service must still allow the expected algorithm, verify the signature with the correct key, and enforce issuer, audience, time, and application policy.

• The displayed signature is not verified. A favorable timestamp badge does not mean the token is authentic or acceptable.
• This decoder expects three segments; it does not decrypt a five-part encrypted JWE.
• It does not check key trust, issuer, audience, nonce, revocation, permissions, or server-specific clock leeway.
• Decoding runs in the browser, but bearer tokens are credentials. Avoid live production tokens, shared devices, clipboard history, browser extensions, and screen sharing.