Skip to main content
ilovecalcs logoilovecalcs.

Dev · Live

JWT Decoder & Debugger, inspect tokens instantly.

Paste any JSON Web Token to decode the header, payload, and signature in real-time. View expiration countdowns, claim analysis, and syntax-highlighted JSON entirely in your browser.

How it worksClient-side only

JWT Token Input

All decoding happens 100% locally in your browser. Your token is never sent to any server.

Decoded header, payload, and claims will appear here

Field guide

How JSON Web Tokens work.

A JSON Web Token (JWT) is a compact, URL-safe format for representing claims between two parties. It is widely used in authentication systems: after a user logs in, a server issues a JWT that the client presents on every subsequent request to prove identity, without the server needing to query a database on every call.

A JWT consists of exactly three segments separated by dots, each segment independently Base64Url-encoded:

Header . Payload . Signature

The Header

The header is a JSON object describing the token's type and the signing algorithm used. A typical header:

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

Common algorithms include HS256 (HMAC-SHA256, symmetric secret), RS256 (RSA-SHA256, asymmetric public/private key pair), and ES256 (ECDSA-SHA256, elliptic curve). The algorithm determines how the signature is generated and how it must be verified.

The Payload (Claims)

The payload is the body of the token. It containsclaims — statements about an entity (typically the user) plus optional metadata. JWT defines severalregistered claims with standard meanings:

  • iss (Issuer) — identifies the principal that issued the JWT. Typically a URL such as https://auth.example.com.
  • sub (Subject) — identifies the subject of the JWT. Usually a user ID or unique identifier.
  • aud (Audience) — identifies the recipients the JWT is intended for. Servers must reject tokens where aud does not include their own identifier.
  • exp (Expiration Time) — the Unix timestamp after which the token must not be accepted. Servers must validate this on every request. This tool displays a live countdown.
  • nbf (Not Before) — the Unix timestamp before which the token must not be accepted. Used to issue tokens that activate at a future time.
  • iat (Issued At) — the Unix timestamp when the JWT was issued. Used to determine the age of the token.
  • jti (JWT ID) — a unique identifier for the JWT, used to prevent token replay attacks when stored in a blocklist.

In addition to registered claims, applications add their ownprivate claims such as role,email, permissions, or any application- specific data.

The Signature

The signature is computed by concatenating the Base64Url-encoded header and payload with a dot, then signing with the algorithm specified in the header:

HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)

The signature prevents the payload from being tampered with. If any byte of the header or payload changes, the signature no longer matches, and any properly implemented server will reject the token. However, this only works if the server actually verifies the signature — a common mistake is trusting the decoded payload without verification.

Base64Url encoding

JWTs use Base64Url encoding rather than standard Base64. The difference is small but important: the characters+ and / are replaced with- and _, and the padding= characters are omitted. This makes JWTs safe to include in URLs and HTTP headers without percent-encoding.

Decoding is the reverse: replace - with+, replace _ with /, add padding to make the length a multiple of 4, then apply standard Base64 decoding. The result is a UTF-8 encoded JSON string.

Common security mistakes

  • Accepting alg: none. An attacker can craft a token with "alg":"none" and no signature. Servers must reject this unless explicitly designed to accept unsigned tokens.
  • Not validating exp. An expired token must be rejected even if the signature is valid. Always check the expiration claim server-side.
  • Storing sensitive data in the payload. JWT payloads are Base64-encoded, not encrypted. Anyone with the token can read the payload. Never put passwords, credit card numbers, or secrets in a JWT.
  • Using weak secrets for HS256. Symmetric HMAC keys shorter than 256 bits are vulnerable to brute-force and dictionary attacks. Use cryptographically random secrets of at least 32 bytes.
  • Trusting the client-decoded payload. Always re-decode and verify the JWT server-side. A client can present any token they choose; trust comes from the signature verification, not from the decoded content.

Privacy note

This decoder runs entirely in your browser. No token data, decoded claims, or any other information is transmitted to any server. You can use this tool to inspect real production tokens safely.