JWT Decoder Guide: How to Decode & Inspect JSON Web Tokens (2026)

A JSON Web Token (JWT, pronounced "jot") is a compact, URL-safe string used to securely transmit information between two parties. It's defined by RFC 7519 and is widely used for authentication and authorization in web applications and APIs.

Why JWTs Are Popular

• Stateless: The server doesn't need to store session data — the token itself contains all necessary information.
• Compact: Small enough to be sent in HTTP headers, URL parameters, or cookies.
• Self-contained: The payload carries user identity and permissions, reducing database lookups.
• Cross-domain: Works seamlessly across different domains and microservices.

JWTs are used by major platforms like Google, Auth0, Firebase, AWS Cognito, and virtually every modern API that uses OAuth 2.0 or OpenID Connect.

Every JWT consists of three parts separated by dots (.):

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.signature

Each part is Base64URL-encoded JSON:

1. Header

The header typically contains two fields:

• alg: The signing algorithm (e.g., HS256, RS256, ES256)
• typ: The token type, usually "JWT"

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

2. Payload (Claims)

The payload contains claims — statements about the user and metadata. There are three types:

{
  "sub": "user_1234",
  "name": "Jane Doe",
  "role": "admin",
  "iat": 1711670400,
  "exp": 1711756800
}

3. Signature

The signature is created by signing the encoded header and payload with a secret key (HMAC) or private key (RSA/ECDSA). It ensures the token hasn't been tampered with. Verification requires the secret or public key — which is why browser decoders can read but not verify tokens.

Understanding standard claims is essential for debugging authentication issues:

The algorithm in the JWT header determines how the signature is created and verified:

Which Should You Use?

• HS256: Simplest option when both the issuer and verifier share the same secret (e.g., a single backend server).
• RS256: The most common choice for distributed systems — the private key signs tokens, and any service with the public key can verify them. Used by Auth0, Google, and AWS Cognito.
• ES256: Smaller signatures and faster verification than RSA — ideal for mobile and IoT applications.

Our free JWT decoder lets you inspect any token instantly without sending it to a server:

Step-by-Step

1. Copy your JWT — from your browser's DevTools (Application → Cookies or Network → Headers), API response, or terminal.
2. Paste into the decoder — the tool instantly splits the token into its three parts.
3. Inspect the header — check the algorithm (alg) and token type.
4. Review the payload — see all claims including user info, roles, and timestamps.
5. Check expiry status — the tool compares exp to your current time and shows a green "Valid" or red "Expired" badge.

When authentication breaks, JWTs are often the culprit. Here are the most common issues and how to diagnose them:

1. Token Expired (401 Unauthorized)

Decode the token and check the exp claim. If it's in the past, the token has expired. Solution: refresh the token using your refresh token endpoint, or request a new one.

2. Invalid Audience (403 Forbidden)

The aud claim doesn't match what the API expects. This happens when you use a token meant for one API with a different one. Check your OAuth configuration.

3. Token Not Yet Valid

If the nbf (Not Before) claim is set to a future time, the token won't be accepted yet. This can happen due to clock skew between servers.

4. Missing Required Claims

Some APIs require specific claims like role, scope, or permissions. Decode the token to verify these claims exist and have the expected values.

5. Algorithm Mismatch

The server expects RS256 but the token uses HS256 (or vice versa). This is also a known security vulnerability — always validate the algorithm server-side.

6. Clock Skew

If iat (issued at) is slightly in the future relative to the verifying server, it may reject the token. Most libraries allow a small leeway (typically 30–60 seconds).

JWTs are powerful but can be dangerous if misused. Follow these best practices:

• Keep tokens short-lived: Set exp to 15–60 minutes for access tokens. Use refresh tokens for longer sessions.
• Never store secrets in the payload: JWTs are encoded, not encrypted — anyone can decode and read the payload. Never put passwords, API keys, or sensitive data in claims.
• Always validate the algorithm: Explicitly set the expected algorithm server-side to prevent "alg: none" attacks.
• Use HTTPS only: Transmit tokens only over HTTPS to prevent man-in-the-middle interception.
• Store tokens securely: Use HttpOnly cookies (not localStorage) to prevent XSS attacks from stealing tokens.
• Validate all claims: Always verify iss, aud, exp, and nbf server-side — not just the signature.
• Rotate signing keys: Periodically rotate your signing keys and use the kid (Key ID) header to manage multiple keys.
• Implement token revocation: Since JWTs are stateless, consider a token blocklist or short expiry + refresh token pattern for revocation.

Choosing the right authentication mechanism depends on your use case:

Many modern applications use a combination: JWTs for short-lived access tokens, refresh tokens stored as HttpOnly cookies, and API keys for external integrations.