JWT Debugger — Decode and Inspect JWT Tokens — Calculator

How JWT Debugger Works

JWT = Base64Url(Header) + "." + Base64Url(Payload) + "." + Signature Header: {"alg": "HS256", "typ": "JWT"} Payload: {"sub": "123", "iat": 1516239022}

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.

Header

JWT Header — JSON object containing metadata about the token, typically including the signing algorithm (alg) and token type (typ). Common algorithms: HS256, RS256, ES256.

Payload

JWT Payload (Claims) — JSON object containing the claims — statements about the user or entity. Includes registered claims (iss, sub, exp, iat), public claims, and private claims.

Signature

JWT Signature — Cryptographic hash of the encoded header and payload combined with a secret key. Verifies that the token was not tampered with and, for HS algorithms, confirms the issuer knows the secret.

Base64URL

Base64URL Encoding — A URL-safe variant of base64 encoding that uses "-" instead of "+", "_" instead of "/", and omits padding "=" characters. Used to make JWT tokens safe for HTTP headers and URLs.

Claims

Registered Claims — Standardized JWT claim names: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID). These provide interoperability between systems.

How to Use

1. Copy your JWT token from your application, authentication provider, or API response.
2. Paste the complete JWT token (all three dot-separated segments) into the input field.
3. Review the decoded header to see the signing algorithm and token type used.
4. Examine the decoded payload to inspect all claims, including expiration (exp) and issuer (iss).
5. Check the signature segment and validation status to confirm the token has the correct structure.

Quick Reference

Common Uses

• •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

Understanding the Result

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.

Worked Examples

Frequently Asked Questions

Does the JWT Debugger verify the signature?

No, this tool only decodes and inspects the JWT structure. It does not verify the cryptographic signature, which requires the secret key (for HMAC) or public key (for RSA). Signature verification must be done server-side with the appropriate key material.

What is the algorithm confusion attack?

An attacker modifies the JWT header to change the "alg" field from a public-key algorithm like RS256 to a symmetric algorithm like HS256. If the server's verification code does not enforce the expected algorithm, the attacker can sign the token using the public key (which is often publicly available) as the HMAC secret. Always validate the algorithm against an expected allowlist.

Is JWT payload data encrypted?

No, JWT payloads are base64url-encoded, not encrypted. Anyone with access to the token can decode and read the payload. Do not put sensitive information like passwords, credit card numbers, or personal health data in a JWT payload. For confidentiality, use JWE (JSON Web Encryption) which encrypts the payload.

What is the maximum size of a JWT?

JWTs can theoretically be any size, but in practice they should be kept under 8KB or even 4KB. Many HTTP servers and proxies have header size limits (e.g., NGINX defaults to 8KB for headers). Since JWTs are typically sent in the Authorization header, exceeding header size limits will cause requests to fail.

What happens when a JWT expires?

The "exp" claim contains a Unix timestamp after which the token should not be accepted. The verifying server checks this timestamp and rejects expired tokens with a 401 Unauthorized response. Clients must then obtain a new token, typically using a refresh token in OAuth2 flows.

Pro Tips

• →Always validate the "alg" field against an allowed list on the server. Never trust the token's own algorithm claim without verification. This prevents algorithm confusion attacks where an attacker changes RS256 to HS256.
• →Check the "exp" (expiration) claim in human-readable form. A Unix timestamp like 1992592800 corresponds to a specific date. Many "auth errors" in production are simply expired tokens — check exp first before debugging anything else.
• →Be cautious with sensitive data in JWT payloads. The payload is base64url-encoded (not encrypted), so anyone with the token can read it. Never put passwords, credit card numbers, or PII in JWT claims. Use opaque tokens or JWE (JSON Web Encryption) for confidential payloads.
• →Set short expiration times for access tokens (15-60 minutes) and use refresh tokens for longer sessions. This limits the damage if an access token is leaked. Rotate signing keys regularly, especially for RS256/ES256 where the public key might be widely distributed.
• →Always transmit JWTs over HTTPS. A JWT sent over plain HTTP can be intercepted and replayed by anyone on the network. Add the "jti" (JWT ID) claim to enable token revocation — without it, you cannot invalidate a specific token before it expires.

Limitations to Know

• •This tool decodes and inspects JWT structure only. It does NOT perform cryptographic signature verification — that requires the secret key (for HMAC) or public key (for RSA/ECDSA). A token that "passes" validation here may still be cryptographically invalid or tampered.
• •The tool does not check token expiration (exp claim) against the current time — it displays the raw value for you to interpret. It does not detect if the token has been revoked.
• •For JWE (JSON Web Encryption) tokens, the payload cannot be decoded without the decryption key — this tool only handles unencrypted JWS (JSON Web Signature) tokens.
• •Always use server-side JWT libraries with proper key management for production authentication.

Sources

• RFC 7519 — JSON Web Token (JWT)
• JWT.io — JSON Web Token Debugger