JWT Decoder

Decode and inspect a JSON Web Token. Signature verification needs the signing key and must be done server-side — this tool only displays the contents.

How to use

  1. Copy the JWT from your app, API response, or Authorization header.
  2. Paste it into the box. Decoding runs automatically as you type.
  3. Read the decoded header and payload; the signature is shown as-is for reference.
  4. Check the time-claims summary (iat, exp, nbf) to spot expired tokens.

What does it do?

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.

Is my data private?

Yes — and this matters for a JWT tool. We don't save any token you paste here. Nothing is stored, logged, or retained, and the token is discarded the moment you close or refresh the tab. There's no record on our side of what you decoded. Verify in your browser's developer tools if you like. Still, a real JWT typically grants access until it expires — treat any live token like a password.

Frequently asked questions

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).

Related tools