Decode JWT tokens online —
free & 100% private

Everything inside a JWT, at a glance

Your token stays in your browser

No account. No upload. No nonsense.

Related JSON tools

Common questions answered

What is a JWT (JSON Web Token)?

A JSON Web Token (JWT) is a compact, URL-safe token format for authentication and authorization. A JWT has three Base64URL-encoded parts separated by dots: a header (algorithm), a payload (claims like user ID, roles, expiration), and a signature (integrity verification). JWTs are the standard for stateless authentication in REST APIs and single-page applications.

This decoder splits a JWT into its three parts and displays each as formatted JSON. The header shows the signing algorithm (HS256, RS256), the payload reveals all claims with human-readable timestamps, and the signature section shows the raw data. Decoding happens entirely in your browser — critical since JWTs contain sensitive user data and permissions.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6
IkFsaWNlIiwiaWF0IjoxNjk3MDAwMDAwfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

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

Payload:
{
  "sub": "1234567890",
  "name": "Alice",
  "iat": 1697000000
  // Oct 11, 2023 04:53 UTC
}

Get the most out of this tool

• Check the "exp" claim to verify a token has not expired — the decoder shows expiration as both timestamp and readable date.
• Never paste JWTs into server-based decoders — they contain your user ID, permissions, and potentially sensitive claims.
• The decoder shows the algorithm in the header — verify it matches what your server expects to detect algorithm confusion attacks.

Understanding JSON Web Tokens

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims between two parties. Defined in RFC 7519, JWTs are the most widely used token format for stateless authentication on the web. When a user logs in, the server generates a JWT, signs it with a secret or private key, and sends it to the client. The client stores it (typically in memory or localStorage) and attaches it to subsequent requests in the Authorization header as a Bearer token.

A JWT consists of exactly three Base64url-encoded parts separated by dots: the header, the payload, and the signature. The header identifies the token type and the signing algorithm — most commonly HS256 (HMAC-SHA256) for symmetric keys or RS256 (RSA-SHA256) for asymmetric key pairs. The payload contains the claims: statements about the user and any additional metadata the application needs.

The payload carries standard claims defined by the RFC. The sub (subject) claim identifies who the token is about — usually a user ID. The iss (issuer) claim identifies which service issued the token. The aud (audience) claim restricts which services should accept the token. The exp (expiration time) claim defines when the token expires as a Unix timestamp. The iat (issued at) claim records when the token was created. The nbf (not before) claim prevents the token from being used before a specific time.

The third part — the signature — is what makes JWTs trustworthy. For HS256, the server concatenates the encoded header and payload with a dot, then computes an HMAC using a secret key known only to the server. Anyone who receives the JWT can decode the header and payload and read the claims, but only the server that holds the secret can verify that the signature is valid. This is why JWTs are called "signed" tokens — the signature guarantees integrity, not confidentiality.

Because the payload is only Base64url-encoded (not encrypted), JWTs should not contain sensitive personal information unless the entire token is additionally encrypted using JWE (JSON Web Encryption). Storing passwords, credit card numbers, or government IDs in JWT payloads is a serious security mistake. Treat the payload as public — anyone who intercepts the token can read it.

Algorithm confusion attacks are a known JWT vulnerability class. An attacker might modify the header to change the algorithm from RS256 (asymmetric) to HS256 (symmetric), then sign the token using the server's public key as the HMAC secret. A vulnerable server using the algorithm specified in the token header instead of the expected algorithm would accept this forged token. Always verify that the algorithm in the decoded header matches what your server expects, not whatever the token claims.

Token expiration is the first thing to check when debugging authentication failures. The exp claim is a Unix timestamp (seconds since January 1, 1970). This decoder displays it as both the raw timestamp and a human-readable date so you can instantly see whether the token has expired. Clock skew between the issuing server and the validating server can cause tokens to be rejected slightly before their displayed expiration — allowing a small leeway (typically 30–60 seconds) in your validation logic is standard practice.

When developers use this tool

Common JWT security mistakes to avoid

• Never paste production tokens into server-based decoders: A JWT contains your user's identity and permissions. Pasting it into a third-party website risks token theft. This decoder runs entirely in your browser — your token is never transmitted anywhere.
• Do not store sensitive data in the payload: The payload is Base64url-encoded, not encrypted. Anyone who possesses the token can decode and read the claims without any key. Sensitive data belongs in a separate encrypted field or not in the token at all.
• Always validate the exp claim server-side: The expiration claim is only meaningful if your server actually checks it. Libraries like jsonwebtoken (Node.js) and golang-jwt/jwt handle this automatically — do not skip the verify step by decoding manually.
• Reject the "none" algorithm: Some early JWT libraries accepted tokens with the algorithm set to "none", meaning no signature was required. Always configure your library to reject this algorithm explicitly, regardless of what the token header claims.
• Use short expiration times: JWTs cannot be revoked without a server-side blocklist. Keep access token lifetimes short (15 minutes to 1 hour) and use refresh tokens for longer sessions. This limits the damage if a token is compromised.

Additional frequently asked questions