JWT Decoder — Decode JSON Web Tokens Online

#What this tool does

Paste a JWT and instantly see its decoded header, payload, and signature. The header reveals the signing algorithm and token type. The payload shows all claims — subject, expiration, issuer, and any custom data. The signature section displays the raw signature bytes.

All decoding runs client-side in your browser. No tokens are sent to any server.

#What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe format for transmitting claims between two parties. It consists of three base64url-encoded segments separated by dots:

header.payload.signature

JWTs are the standard mechanism for stateless authentication, API authorization, and single sign-on (SSO). The server issues a signed token after login, and the client includes it in subsequent requests — eliminating server-side session storage.

#JWT structure

A JWT breaks down into three parts. Here is a real token split across its segments:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Header — declares the token type and signing algorithm.

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

Payload — contains the claims. These are statements about the user and additional metadata.

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1716239022
}

Signature — produced by signing the encoded header and payload with a secret key (HS256) or private key (RS256). The server uses this to verify the token has not been tampered with. HS256 uses HMAC-SHA256 under the hood.

#Common JWT claims

These are the registered claims defined in RFC 7519:

• iss (issuer) — identifies who issued the token. Typically a URL or service name.
• sub (subject) — identifies the principal. Usually a user ID.
• aud (audience) — identifies the intended recipient. Reject tokens with an unexpected audience.
• exp (expiration) — Unix timestamp after which the token is invalid. Always check this server-side.
• iat (issued at) — Unix timestamp when the token was created.
• nbf (not before) — Unix timestamp before which the token must not be accepted.
• jti (JWT ID) — unique identifier for the token. Useful for preventing replay attacks.

All timestamps are Unix epoch seconds, not milliseconds. Use our timestamp converter to convert these to human-readable dates.

#JWT security considerations

JWTs are signed, not encrypted. Anyone with the token can decode the payload — this tool proves it. This has direct implications for what you put inside them:

• Never store secrets in the payload. Passwords, API keys, and sensitive PII are visible to anyone who has the token. See why API keys should never touch the client.
• Always verify signatures server-side. Decoding is not verification. A valid-looking payload means nothing without checking the signature against the signing key.
• Check the exp claim on every request. Expired tokens must be rejected. Clock skew tolerance of a few seconds is acceptable; minutes is not.
• Use short-lived tokens. Access tokens should expire in minutes, not days. Use refresh tokens for longer sessions.
• Prefer RS256 over HS256 in distributed systems. Asymmetric signing lets services verify tokens without sharing the secret key.

#Open source

This tool is powered by @azin-tech/mini-tools, an open-source developer toolkit. View source on GitHub.