JWT Decoder

Decode, inspect, and debug JSON Web Tokens — 100% in your browser.

Your token never leaves your browser. Zero server calls.
This tool decodes JWTs — it does not verify signatures. Never trust a JWT without server-side signature verification.

How This JWT Decoder Works

A JSON Web Token consists of three base64url-encoded parts separated by dots: header.payload.signature. This tool splits the token, decodes each part, and presents the data in a readable format with claim explanations and expiration checking.

What It Shows

  • Header: The signing algorithm (alg) and token type (typ). Common algorithms include HS256, RS256, and ES256.
  • Payload: The claims — data like user ID (sub), issuer (iss), expiration (exp), and any custom claims.
  • Signature: The cryptographic signature used to verify the token's integrity (cannot be decoded without the key).
  • Expiration check: Compares the exp claim against the current time to show if the token is valid or expired.
  • Claim explanations: Hover over any standard claim to see its purpose and meaning.

Frequently Asked Questions

What is a JSON Web Token (JWT)?

A JWT is a compact, URL-safe token format defined by RFC 7519. It's widely used for authentication (login sessions), authorization (API access), and information exchange. A JWT contains a JSON header, a JSON payload with claims, and a cryptographic signature.

Is it safe to paste my JWT into this tool?

Yes. This tool runs 100% in your browser. Your token is never sent to any server — all decoding happens client-side using JavaScript. You can verify this by checking your browser's Network tab: you'll see zero requests when you decode a token.

Does this tool verify JWT signatures?

No. This tool decodes JWTs to inspect their contents. It does not verify signatures. Signature verification requires the signing key (secret or public key), which should never be shared with a client-side tool. Always verify signatures on your backend.

What do the standard JWT claims mean?

The standard (registered) claims are: iss (issuer — who created the token), sub (subject — usually a user ID), aud (audience — intended recipient), exp (expiration time), nbf (not before — earliest valid time), iat (issued at — creation time), and jti (JWT ID — unique identifier). This tool shows labels and descriptions for all of these.

How do I check if a JWT is expired?

Paste the JWT into this tool. It automatically reads the exp claim, converts it from a Unix timestamp to a human-readable date, and compares it to the current time. You'll see a green badge ("Valid for X") or a red badge ("Expired X ago") at the top of the results.

JWT Examples & Common Patterns

Explore these examples to understand different JWT structures. Click any example to decode it live.

Standard Auth Token

A typical authentication JWT with standard claims: sub (user ID), name, email, iat, exp, iss, and aud. Uses HS256 signing.

Header:  { "alg": "HS256", "typ": "JWT" }
Payload: { "sub": "1234567890", "name": "Jane Developer",
           "email": "jane@example.com", "exp": <now+24h> }

Decode it: Notice the green "Valid for 24h" badge and the human-readable timestamp conversions for iat and exp.

Expired Token with Roles

A JWT that expired 1 hour ago. Includes roles array and scope string — common patterns in API authorization tokens.

Header:  { "alg": "RS256", "typ": "JWT", "kid": "key-2024-03" }
Payload: { "sub": "user_42", "roles": ["admin", "editor"],
           "scope": "read write", "exp": <now-1h> }

Decode it: See the red "Expired" badge. The kid in the header identifies the signing key — critical for key rotation in production systems.

Enterprise Token with Nested Claims

A complex JWT with nested objects, arrays, OIDC claims (azp, nonce), and custom organization data. Uses ES256 signing.

Header:  { "alg": "ES256", "typ": "JWT", "kid": "ec-prod-1" }
Payload: { "sub": "org:acme:user:12345", "roles": [...],
           "permissions": [...], "org": { "id": "...", plan: "enterprise" } }

Decode it: Notice the nested org object and the permissions array. The nbf (not before) claim restricts when the token becomes valid.

Malformed / Invalid JWT

A string that isn't a valid JWT — doesn't have the correct 3-part structure or valid base64url encoding. See how the tool handles errors.

not.a.valid-jwt-at-all!

Decode it: The tool shows a clear error explaining what's wrong. Common causes: truncated tokens, accidental whitespace, or copying the wrong string.