JWT Decoder

What is a JWT?

A JSON Web Token (JWT, defined in RFC 7519) is a compact, URL-safe way to pass claims between two parties, most often to carry authentication and authorisation data in web APIs. A signed JWT has three Base64url-encoded segments separated by dots: header.payload.signature.

• Header — a JSON object naming the signing algorithm (alg, e.g. HS256) and usually the type (typ).
• Payload — the claims, such as sub (subject), iat (issued at) and exp (expiry).
• Signature — computed over header.payload. It proves the token has not been altered since it was signed by someone holding the key.

The header and payload are only encoded, not encrypted, so anyone who has the token can read them. Never put secrets in a JWT payload, and always send tokens over HTTPS. The JWT explained guide covers claims, algorithms and common mistakes in more depth.

How to use the JWT decoder

1. Paste the token into the Input (JWT) pane — just the token, without a Bearer prefix.
2. Click Decode. The right-hand pane shows the header and payload as indented JSON, under // HEADER and // PAYLOAD labels.
3. To check an HMAC signature, type the secret into the Secret for HMAC verification (optional) field and click Verify Signature. The result appears below the panes.
4. Use Copy or Download to keep the decoded text. Clear empties the token, the output and the secret field.

What the decoder shows

• Dates — numeric exp, iat and nbf claims are Unix timestamps in seconds. The tool adds the matching date as a comment in ISO 8601 format, in UTC (the trailing Z). It does not say whether the token has expired; compare exp with the current time yourself.
• Signature — the signature segment itself is not shown in the output; it is used only by Verify Signature.
• Download — saves the output as jwt-decoded.json. Because it includes the // labels and date comments, remove those before using the file as strict JSON.

How signature verification works here

For tokens whose header says HS256, HS384 or HS512, the tool computes the HMAC (SHA-256, SHA-384 or SHA-512) of header.payload with your secret using the browser's Web Crypto API, encodes it as Base64url and compares it with the token's signature. You then see either Signature is VALID for the given secret or Signature does NOT match this secret.

A few details matter. The secret is used as typed, as UTF-8 text; if your server stores the key Base64-encoded, the result will not match unless you use the raw key. For any other alg — RS256, ES256, PS256 or none — the tool says verification is not supported. A VALID result only means the signature matches that secret: it does not check exp, nbf, the issuer or the audience, which your application must do.

Example

This HS256 token was signed with the test secret my-test-secret:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTQyIiwibmFtZSI6IkFkYSBMb3ZlbGFjZSIsImlhdCI6MTc2NzIyNTYwMCwiZXhwIjoxNzY3MjI5MjAwfQ.g-mkskeRxy9WbUGRi7prFMhmTuU5w7ZEl-p76Jr7G1o

Decode shows:

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

// PAYLOAD
{
  "sub": "user-42",
  "name": "Ada Lovelace",
  "iat": 1767225600,  // 2026-01-01T00:00:00.000Z
  "exp": 1767229200  // 2026-01-01T01:00:00.000Z
}

Verifying with my-test-secret reports a valid HS256 signature; any other secret reports a mismatch. Note that the token expires one hour after it was issued — an expiry this tool shows but does not enforce.

Common errors and how to fix them

Decoding problems appear above the panes and in the output pane, starting with Invalid JWT:.

Frequently asked questions

Guides

Related tools