JWT Decoder & Validator

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

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

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

How to Use the JWT Decoder

Paste any JSON Web Token into the input field at the top of the page. The decoder works automatically — as soon as a valid three-part token is detected, it splits the string at the two dot separators and Base64URL-decodes each segment without requiring any interaction from you.

The results are presented in three tabs. The Header tab shows the algorithm (alg) and token type (typ). The Payload tab displays all claims in formatted JSON, including registered claims such as exp, iat, sub, and iss alongside any custom claims your application defines. The Signature tab shows the raw Base64URL-encoded signature string along with the algorithm used to create it.

The decoder also checks the exp claim against the current time and displays a clear expiration status — active, expired, or no expiration set — so you can immediately tell whether a token is still valid without manually converting a Unix timestamp. You can copy any individual section to the clipboard with a single click, which is useful when you need to inspect a header or payload in isolation or paste it into another tool. JWTs use Base64URL encoding — try our Base64 Encoder to understand the encoding format in more detail.

What is a JWT?

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519 for securely transmitting claims between two parties. Unlike traditional server-side session cookies, JWTs are stateless — the server does not need to store session data in a database or memory store because all the information the server needs is embedded in the token itself and protected by a cryptographic signature.

A JWT consists of three parts separated by dots: a header, a payload, and a signature. Each part is independently Base64URL-encoded, making the entire token safe to use in URLs and HTTP headers. The header and payload are plain JSON objects that anyone can read; the signature is what prevents tampering. When the server receives a token, it re-computes the expected signature from the header and payload using its secret key and compares it to the signature in the token. If they match, the token is authentic.

JWTs replaced session cookies as the dominant auth mechanism in single-page applications and microservices because they are self-contained — a downstream service can verify a token without making a network call to a central auth server, which dramatically reduces latency and infrastructure complexity.

JWT Structure

• Header — Contains the signing algorithm (e.g., HS256, RS256) and token type (JWT).
• Payload — Contains claims: registered (iss, exp, sub), public, and private claims.
• Signature — Created by signing the encoded header and payload with a secret or private key.

Common JWT Claims

• iss (Issuer) — Who issued the token.
• sub (Subject) — The subject of the token.
• exp (Expiration) — When the token expires (Unix timestamp).
• iat (Issued At) — When the token was issued.
• aud (Audience) — Intended recipient of the token.

Common Use Cases

JWTs are used extensively across modern web and mobile infrastructure. Understanding where tokens appear in practice helps you know when to reach for this decoder during development and debugging.

API authentication with Bearer tokens is the most common pattern. A client authenticates once, receives a JWT, and then includes it in every subsequent request as an Authorization: Bearer <token> header. The API validates the token on each request without a session lookup.

OAuth 2.0 access and refresh tokens are frequently issued as JWTs by authorization servers such as Auth0, Okta, and AWS Cognito. The access token carries the user's scopes and identity; the refresh token is used to obtain a new access token after expiry.

Single Sign-On (SSO) systems use JWTs to pass identity assertions between an identity provider and multiple service providers. A user logs in once and the JWT is accepted by all services in the federation without re-authentication.

Inter-service communication in microservices architectures relies on JWTs to propagate identity and authorization context as requests fan out across services. Each service can independently verify the token using the issuer's public key.

Mobile application authentication uses JWTs because they can be stored on-device and included in requests to backend APIs, and because the stateless verification model works well when clients may be offline or on unreliable connections.

Best Practices & Tips

Working with JWTs safely requires understanding both what they protect and what they do not.

Always check exp before trusting a token. A token that was valid yesterday may be expired today. Validate the expiration claim on every request server-side — do not rely on the client to discard expired tokens.

Never store secrets in the JWT payload. The payload is Base64URL-encoded, not encrypted. Anyone who intercepts or obtains the token string can decode and read every claim. Store only non-sensitive identifiers such as user IDs and role names.

Use short expiration times. Access tokens should typically expire in 15 minutes to 1 hour. Use refresh tokens with longer lifetimes to issue new access tokens without forcing the user to re-authenticate. Short-lived tokens limit the damage if a token is stolen.

Validate the signature server-side on every request. Client-side decoding (like this tool does) is useful for inspection and debugging, but production systems must verify the signature cryptographically before acting on any claim. JWT signatures use HMAC-SHA256 — explore hashing with our Hash Generator.

Prefer RS256 over HS256 for public clients. RS256 uses an asymmetric key pair — the private key signs tokens and only your server holds it, while the public key can be distributed to any service that needs to verify tokens. HS256 requires sharing the same secret with every verifier, which is a security risk at scale.

Store tokens in httpOnly cookies rather than localStorage. Tokens stored in localStorage are accessible to any JavaScript running on the page, making them vulnerable to XSS attacks. An httpOnly cookie is inaccessible to JavaScript and is sent automatically by the browser.

Related Guides

• What is JWT? JSON Web Tokens Explained — understand the structure, claims, and security of JWTs
• How to Debug JWT Authentication Issues — step-by-step troubleshooting for common JWT errors
• Hashing Explained: MD5, SHA-256 & More — the cryptography behind JWT signatures