JWT Decoder guide

How a JWT is built

A JSON Web Token (RFC 7519) is a compact way to pass claims, such as a user ID and an expiry time, between systems. It consists of three parts separated by dots: a header that names the signing algorithm, a payload with the claims, and a signature over the first two parts. Each part is base64url-encoded.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9      header:    {"alg":"HS256","typ":"JWT"}
.eyJzdWIiOiIxMjMiLCJleHAiOjE3NTc5MDAwMDB9  payload:   {"sub":"123","exp":1757900000}
.3q2-7wrBx...                            signature: HMAC-SHA256 over header.payload

Anyone can decode the header and payload; base64url is an encoding, not encryption. The signature is what makes the token trustworthy: only a party with the right key can produce it, and any change to the header or payload breaks it. Encrypted tokens also exist (JWE), but most tokens in APIs and login systems are signed only.

How to use the JWT Decoder

1. Open the JWT Decoder and paste a token. It is decoded in your browser as you type.
2. Read the header and payload as formatted JSON, and the notes about algorithm, expiry and claims.
3. To verify the signature, enter the HMAC secret (tick base64url if the secret is encoded that way) or paste a public key in PEM or JWK format.
4. Press Verify signature and read the result.

Registered claims

{
  "iss": "https://auth.example.com",
  "sub": "user-8812",
  "aud": "https://api.example.com",
  "iat": 1789462800,
  "exp": 1789463700,
  "scope": "orders:read"
}

Time claims are Unix timestamps in seconds, not milliseconds. The decoder converts them into readable durations, such as "expired 3 hours ago" or "valid for another 14 minutes", using your device's clock. If the device clock is wrong, those durations are wrong too.

What the decoder warns about

Verifying signatures

With HMAC algorithms, the same secret signs and verifies, so everyone who can verify can also create tokens. Asymmetric algorithms separate the two: the issuer keeps the private key and publishes the public key, often as a JWKS document, so any service can verify without being able to issue. For systems where many services consume tokens, asymmetric keys are the safer design.

Verification uses the browser's WebCrypto implementation. A successful verification proves the token was signed with the matching key; it does not check iss, aud or whether the token has been revoked, which remain the job of the receiving server.

Common JWT mistakes

• Accepting the algorithm from the token. Configure the expected algorithms on the server; never let the alg header choose, which is how none and key-confusion attacks work.
• Weak HMAC secrets. Short or guessable secrets can be brute-forced offline from a single token. Use at least as many random bytes as the hash output, for example 32 bytes for HS256.
• No expiry, or very long lifetimes. Tokens cannot easily be revoked, so keep access tokens short-lived and use refresh tokens for long sessions.
• Sensitive data in the payload. Anything in the payload is readable by whoever holds the token, including browser extensions and logs.
• Not checking aud. A token issued for one service should not be accepted by another that happens to trust the same issuer.
• Storing tokens where scripts can read them. Tokens in localStorage are exposed to any XSS; HttpOnly cookies avoid that for browser sessions.

The CSP guide covers limiting script injection, which protects tokens stored in the browser. For inspecting the JSON inside tokens in more detail, the JSON Formatter can pretty-print decoded payloads.

FAQ

Sources

• RFC 7519: JSON Web Token (JWT)
• RFC 7515: JSON Web Signature (JWS)
• RFC 7518: JSON Web Algorithms (JWA)
• RFC 8725: JSON Web Token Best Current Practices
• RFC 7517: JSON Web Key (JWK)