JWT Decoder

A JSON Web Token is three base64url-encoded segments joined by dots: header.payload.signature. The header and payload are JSON; the signature is an HMAC or RSA/ECDSA output over the first two segments. This tool splits on the dots, base64url-decodes each part, parses the JSON, and surfaces standard time claims like exp as human-readable dates. It does not verify the signature — see the FAQ below for why.

Example

The sample token from the JWT spec (HS256 signed with the secret your-256-bit-secret):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded header:

{
  "alg": "HS256",
  "typ": "JWT"
}

Decoded payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Why is my JWT signature marked as invalid?

This decoder does not check signatures (see the FAQ), but if a server-side verifier is rejecting your token, these are the usual culprits.

• Wrong secret or key. A single character difference in the HMAC secret produces a completely different signature. Verify the JWT_SECRET env var on the validating service matches the issuer.
• Algorithm mismatch. A token signed with HS256 cannot be verified with RS256. Check the alg claim in the header and make sure the verifier is configured for the same algorithm.
• Expired token. Even a correctly signed JWT fails validation once exp is in the past. The time-claims summary shows this explicitly after decoding.
• Clock skew. nbf (not-before) in the near future plus server clock drift causes "token not yet valid" errors. Allow a small leeway (e.g., 60 seconds) in your verifier.
• Whitespace in the pasted token. Copy-paste sometimes includes a leading space or a trailing newline. A JWT must be exactly header.payload.signature with no surrounding whitespace.
• alg: none. If the header says "alg": "none" the token is unsigned. Reject these at the verifier — never treat them as valid.

Can this tool verify the JWT signature?

No, and that is intentional. Verifying a signature requires the signing key — an HMAC shared secret or an asymmetric public key. That key belongs on the server that issues or consumes the token, not pasted into a web page. This tool decodes and displays only; verification happens server-side in your backend.

What is inside each of the three JWT segments?

A JWT is header.payload.signature. The header is JSON describing the algorithm (alg) and token type. The payload is JSON containing claims like sub, iat, exp. The signature is the base64url-encoded output of signing the first two segments with the secret or private key. The first two are just encoded, not encrypted.

My JWT has expired — how do I tell?

Look at the exp claim in the payload. It is a Unix timestamp in seconds. If Date.now() / 1000 is greater than exp, the token is expired. This tool renders exp, iat, and nbf as human-readable dates under the payload so you can tell at a glance without doing the math yourself.

What does alg: none mean and why is it dangerous?

alg: none is a JWT feature where the signature is empty and not checked. Many libraries historically accepted such tokens, letting attackers forge JWTs by crafting a payload and setting alg to none. If you see this header value, the token is unsigned — do not trust any server that accepts it.

Do you save the JWTs I paste here?

No. We don't save any token you paste into the decoder. Whatever you drop in is discarded when you close or refresh the tab — nothing is logged, and there's no record on our side of the tokens you inspected. Still, a JWT grants access until its exp: treat it like a password and rotate any production token you debug.

The signature section shows a blob I cannot read — is that normal?

Yes. The signature is binary output from HMAC or RSA/ECDSA, base64url-encoded. It is not meant to be human-readable — it only serves as a cryptographic check. The decoded header and payload are the JSON parts you act on. An empty signature means the token is unsigned (alg: none).