JWT Decoder

What Is a JWT?

A JWT (JSON Web Token) is a compact, URL-safe token format defined in RFC 7519. It is used to securely transmit claims between parties as a JSON object. JWTs are the backbone of modern authentication and authorization systems — used in OAuth 2.0, OpenID Connect, API authentication, and single sign-on (SSO) flows across virtually every web application.

The key property of a JWT is that it is self-contained: the token itself carries all the information needed to verify the user's identity and permissions, without requiring a database lookup on every request. This makes JWTs ideal for stateless, distributed architectures where multiple services need to authenticate the same user.

JWT Structure — Three Parts Explained

Every JWT consists of three Base64URL-encoded parts separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Part 1: Header

The header is a JSON object that describes the token type and the signing algorithm. It always contains "typ": "JWT" and an "alg" field specifying the algorithm used to sign the token.

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

Common algorithms include HS256 (HMAC-SHA256, symmetric), RS256 (RSA-SHA256, asymmetric), and ES256 (ECDSA-SHA256, asymmetric). RS256 and ES256 are preferred for production systems because they allow public key verification without sharing the signing secret.

Part 2: Payload (Claims)

The payload contains the claims — statements about the user and additional metadata. RFC 7519 defines several registered claims with specific meanings:

• →sub (Subject) — The principal that is the subject of the JWT, typically a user ID.
• →iss (Issuer) — The entity that issued the token, e.g. "https://auth.example.com".
• →aud (Audience) — The intended recipient of the token, e.g. your API's identifier.
• →exp (Expiration Time) — Unix timestamp after which the token must not be accepted.
• →iat (Issued At) — Unix timestamp when the token was issued.
• →nbf (Not Before) — Unix timestamp before which the token must not be accepted.
• →jti (JWT ID) — A unique identifier for the token, used to prevent replay attacks.

In addition to registered claims, you can include any custom claims: user roles, permissions, email addresses, or application-specific data.

Part 3: Signature

The signature is computed by encoding the header and payload, then signing with the algorithm specified in the header. For HS256: HMAC-SHA256(base64url(header) + "." + base64url(payload), secret). The signature ensures the token has not been tampered with — any modification to the header or payload invalidates the signature.

Decoding vs. Verifying a JWT

This is a critical distinction that many developers confuse:

Decoding simply Base64URL-decodes the header and payload to read their contents. Anyone can decode a JWT — the payload is not encrypted, only encoded. This tool decodes JWTs for inspection purposes.

Verifying checks the signature against a known secret or public key to confirm the token was issued by a trusted party and has not been modified. Verification requires the signing secret (for HS256) or the public key (for RS256/ES256). Never trust a JWT's claims without verifying the signature in your application code.

This decoder is for inspection and debugging only. For production signature verification, use a trusted JWT library in your language of choice.

Common JWT Security Vulnerabilities

The "alg: none" Attack

Some early JWT libraries accepted tokens with "alg": "none" in the header, treating them as valid without any signature verification. An attacker could forge any token by setting the algorithm to none and omitting the signature. Always use a library that explicitly rejects the none algorithm.

Algorithm Confusion (RS256 → HS256)

If a server uses RS256 (asymmetric) but an attacker changes the header to HS256 (symmetric) and signs the token with the server's public key, a vulnerable library might verify it using the public key as the HMAC secret. Always specify the expected algorithm explicitly when verifying tokens.

Sensitive Data in Payload

JWT payloads are Base64URL-encoded, not encrypted. Anyone who intercepts the token can read the claims. Never store passwords, credit card numbers, or other sensitive data in a JWT payload. If you need encrypted tokens, use JWE (JSON Web Encryption) instead of JWS (JSON Web Signature).

Missing Expiration

Always include an exp claim. A JWT without an expiration is valid forever — if it is stolen, the attacker has permanent access. Short-lived access tokens (15 minutes to 1 hour) combined with refresh tokens are the recommended pattern.

JWT vs. Session Tokens vs. API Keys

Session tokens are opaque random strings stored server-side. The server looks up the session on every request. They are easy to revoke but require server-side state and don't scale well across multiple services.

JWTs are self-contained and stateless. The server verifies the signature without a database lookup, making them ideal for microservices and distributed systems. The tradeoff is that revoking a JWT before expiration requires a token blacklist or short expiration times.

API keys are long-lived credentials for machine-to-machine authentication. They are simpler than JWTs but carry more risk if compromised. For generating secure random API keys and tokens, use our Password Generator with maximum entropy settings.

JWT Libraries by Language

Use a well-maintained JWT library rather than implementing JWT verification yourself:

• →Node.js: jsonwebtoken or jose (Web Crypto API based)
• →Python: PyJWT or python-jose
• →Go: golang-jwt/jwt
• →Java: jjwt (Java JWT) or nimbus-jose-jwt
• →PHP: firebase/php-jwt or lcobucci/jwt
• →C#/.NET: System.IdentityModel.Tokens.Jwt (Microsoft)
• →Rust: jsonwebtoken crate

Test JWT parsing and generation in the Developer Lab with live code execution in your language of choice.

Privacy — Your Tokens Stay in Your Browser

JWT tokens often contain sensitive user data: user IDs, email addresses, roles, and permissions. This decoder runs entirely in your browser — your token is never transmitted to any server. The decoding is performed using standard JavaScript string operations and atob() for Base64 decoding.

You can safely inspect production tokens, debug authentication issues, and verify claim structures without any risk of token exposure. For additional security tooling, explore our Password Generator for creating cryptographically secure secrets and API keys.