JWT Decoder

How to use this tool

Paste a three-part JWT and select Decode. Inspect the decoded header and payload; verify authenticity separately in your application.

Example

Input

eyJhbGciOiJub25lIn0.eyJzdWIiOiIxMjMifQ.

Output

Header: {"alg":"none"}; payload: {"sub":"123"}

What does this tool do?

A signed JSON Web Token commonly has three dot-separated segments: header, payload and signature. The first two contain Base64URL-encoded JSON.

Common mistakes and limitations

This tool decodes JWT data locally. It does not verify the token signature. Decoded claims, including expiry and identity, are untrusted. Encrypted five-part JWE tokens are not supported.

Read the three compact segments

A typical signed JWT has header.payload.signature segments separated by dots. Header and payload are JSON encoded with Base64URL, which substitutes URL-friendly alphabet characters and often omits padding. The header may name an algorithm and key identifier; the payload contains claims. The third segment is signature material, not another ordinary JSON object. Encrypted JWT formats can have a different structure and are outside this decoder’s scope.

Interpret claims without trusting them

The exp claim indicates expiry, iat an issued-at time and nbf a not-before time, conventionally as NumericDate seconds since the Unix epoch. Use the timestamp converter to inspect these values rather than treating them as milliseconds. Other claims may identify an issuer, audience or subject. Their presence does not prove that the issuer created the token or that the audience matches your application. Clock tolerance and claim requirements belong in the verifier.

Decoding is not signature verification

This tool does NOT verify JWT signatures. A malicious actor can construct readable header and payload values; decoding them is not authentication. A trusted verifier must select an allowed algorithm, obtain the correct trusted key, check the signature and enforce the required claims. Never decide access from this page’s output. Tokens may contain session authority or personal data, so use synthetic samples when investigating a format and avoid sharing screenshots or clipboard contents from a live token.

header.payload.signature
exp: 1704067200 → Unix seconds, not milliseconds

Investigate token failures in the verifier

If a token looks readable but an application rejects it, check issuer and audience expectations, time units, expiry and the trusted key-selection process in the application. Do not edit the decoded payload and assume the original signature remains valid. Changing a signed segment changes the bytes that must be verified. The tool cannot tell you which private keys, revocation rules or server session policies apply to your environment.

Frequently asked questions