Three dot-separated sections
A commonly used signed JWT contains a Base64URL header, a Base64URL payload, and a signature. The first two sections are readable without a secret. Encrypted tokens use a different structure and are not supported by this decoder.
base64url(header).base64url(payload).signature
Read claims in context
The header may include alg and typ. The payload may include iss (issuer), sub (subject), aud (audience), exp (expiration), iat (issued at), and nbf (not before). Applications can also include custom claims. These names describe their intended meanings; the values remain untrusted until verification.
Time claims use seconds
NumericDate claims use seconds since the Unix epoch. JavaScript Date expects milliseconds, so multiply the value by 1,000. An exp timestamp in the past indicates that the claimed expiration has passed. A future timestamp does not prove a token is authentic.
Decoding is not verification
An attacker can create an arbitrary header and payload. Verification must use trusted key material, an allowed algorithm, and application-specific checks such as issuer and audience. Never let the token alone decide which algorithms or keys are trusted. This tool reads content but does not verify signatures.
Keep tokens private
Tokens may expose personal information or act as bearer credentials. Avoid sharing live tokens in screenshots, tickets, logs, or public tools. This decoder processes input locally and does not store it.