JWT Debugger — Decode and Inspect JWT Tokens

The Formula

A JSON Web Token (JWT) is a compact, URL-safe token format consisting of three base64url-encoded segments separated by dots: a header containing the signing algorithm and token type, a payload containing claims (data), and a cryptographic signature that verifies the token integrity. The signature is created by signing the encoded header and payload with a secret key.

Variable Definitions

How to Use This Calculator

1. 1

   Copy your JWT token from your application, authentication provider, or API response.

2. 2

   Paste the complete JWT token (all three dot-separated segments) into the input field.

3. 3

   Review the decoded header to see the signing algorithm and token type used.

4. 4

   Examine the decoded payload to inspect all claims, including expiration (exp) and issuer (iss).

5. 5

   Check the signature segment and validation status to confirm the token has the correct structure.

Quick Reference

Common Applications

• Authenticating users in single-page applications and mobile apps via bearer tokens
• Securing API-to-API communication with signed tokens that verify the caller identity
• Implementing stateless session management where the server does not store session data
• Exchanging identity information between services in microservice and OAuth2/OIDC architectures
• Creating secure password reset links and email verification tokens with expiration

JSON Web Token structure with three base64url-encoded segments separated by dots

Understanding the Concept

JSON Web Tokens (JWT) have become the de facto standard for authentication and information exchange in modern web applications and API-driven architectures. A JWT is composed of three parts, each base64url-encoded and separated by a dot character. The header typically specifies the signing algorithm (e.g., HS256 for HMAC with SHA-256, or RS256 for RSA with SHA-256) and the token type ("JWT"). The payload contains claims — statements about the entity (usually a user) and additional metadata. Registered claims like "exp" (expiration time), "iat" (issued at), "sub" (subject), and "iss" (issuer) provide standardized fields that any JWT-compliant system can understand. The signature is the most critical part for security. For HMAC-based algorithms (HS256), the signature is computed by taking the base64url-encoded header and payload separated by a dot, and signing them with a shared secret key. For RSA-based algorithms (RS256), a private key is used for signing and a public key for verification. The signature ensures the token has not been tampered with and, for HS algorithms, proves that the signer knows the shared secret. JWTs are commonly used in OAuth2 and OpenID Connect flows, where an authorization server issues a token to a client application after successful authentication. The client then presents this token to APIs, which verify the token's signature and check its claims before granting access. One critical security consideration is that JWTs should always be transmitted over HTTPS and should have short expiration times (typically 15-60 minutes for access tokens). The token payload is base64-encoded, not encrypted — anyone who intercepts the token can decode and read the payload contents, so sensitive data should never be placed in the payload without additional encryption. JWTs are also a common attack vector for vulnerabilities like algorithm confusion attacks, where an attacker changes the "alg" header to "none" to bypass signature verification.

Frequently Asked Questions

Sources & References