JWT Debugger

Decode & Verify JWT Tokens

JWT Debugger is an online tool for decoding, encoding, and verifying JSON Web Tokens. You can paste a JWT to decode its header and payload, view claims, check expiration, and verify signatures with HMAC algorithms (HS256, HS384, HS512). The tool also encodes new JWTs from header and payload JSON with your secret. It displays token statistics, formatted claim values (dates, booleans), and registered claim explanations. JWT Debugger is essential for developers working with authentication systems, APIs, and identity management.

JSON Web Tokens (JWTs) are a standard for securely transmitting information between parties as a compact, URL-safe string. They are widely used for authentication and authorization: after login, a server issues a JWT that the client sends with subsequent requests. The JWT contains claims (data) and a signature that verifies integrity. Understanding what is inside a JWT and whether it is valid is crucial for debugging authentication issues.

A JWT has three parts separated by dots: header, payload, and signature. The header specifies the algorithm (e.g., HS256). The payload contains claims (user ID, roles, expiration, etc.). The signature verifies that the token has not been tampered with. The tool decodes header and payload (which are base64url-encoded JSON), displays them formatted, and optionally verifies the signature if you provide the secret.

Decoding shows the token's contents, but signature verification confirms authenticity. Without verification, anyone can create a token with arbitrary claims. The debugger verifies HMAC signatures (HS256, HS384, HS512) using your secret. If the signature matches, the token was created by someone with the secret and has not been modified. Verification is optional for inspection but essential before trusting token claims.

Beyond decoding, the tool encodes new JWTs. Enter header and payload JSON, provide a secret, and generate a signed token. This is useful for testing APIs, creating mock tokens for development, and understanding how JWT encoding works. The generated token can be used in API testing tools or front-end development. Always use test secrets, not production secrets, in online tools.

Who Benefits from This Tool

JWT Debugger is for developers, security engineers, QA testers, and anyone who works with JWT-based authentication. Back-end developers debug authentication flows and token generation. Front-end developers inspect tokens stored in the browser. Security engineers audit JWT implementations for vulnerabilities. QA testers create test tokens for API testing. Anyone implementing or troubleshooting JWT authentication benefits from this tool.

Back-end developers implement JWT authentication in APIs and services. When tokens fail validation, debugging requires inspecting the token contents. The tool shows exactly what is in the header and payload, whether claims are present and correctly formatted, and whether the signature is valid. This accelerates debugging compared to writing code to decode tokens or reading raw base64.

Front-end developers receive JWTs from authentication endpoints and store them for API calls. Inspecting tokens helps understand what claims are available (user ID, roles, permissions), when tokens expire, and what the token contains. The tool provides this visibility without backend access. Front-end developers can also verify that token storage and transmission are working correctly.

Security engineers audit JWT implementations for issues: weak algorithms, missing claims, excessive token lifetimes, sensitive data exposure. The debugger reveals token contents and algorithm choices. Verifying signatures helps test that proper secrets are used. Auditing tokens from staging or test environments identifies security gaps before production deployment.

Key Features

Decode JWT

Paste a JWT to decode header and payload. The tool parses the three parts, base64url-decodes header and payload, and displays them as formatted JSON. Bearer prefix is automatically removed. Invalid tokens show clear error messages. Decoding reveals all token contents without needing the secret.

Verify Signature

Enter the secret to verify HMAC signatures. Supports HS256 (SHA-256), HS384 (SHA-384), and HS512 (SHA-512) algorithms. Secret can be plain UTF-8 text or base64-encoded. Verification confirms the token was signed with the provided secret and has not been modified. Invalid signatures are clearly indicated.

Encode JWT

Create new JWTs by entering header and payload JSON and providing a secret. The tool generates a signed token you can copy and use. Useful for testing APIs, creating mock tokens, and understanding JWT structure. Always use test secrets in online tools, never production secrets.

Claim Information

Display registered claims with explanations: iss (issuer), sub (subject), aud (audience), exp (expiration), nbf (not before), iat (issued at), jti (JWT ID). Timestamp claims show human-readable dates alongside Unix timestamps. The tool indicates whether the token is expired based on the exp claim.

Token Statistics

View token metrics: total length, header length, payload length, signature length, algorithm, type, and claim count. Statistics help understand token size and structure. For performance-sensitive applications, token size matters; statistics reveal how much data is in the payload.

Add Claims

When encoding, quickly add standard claims with proper values: exp (1 hour from now), iat (current time), nbf (current time), jti (random ID). Buttons insert claims with sensible defaults; edit values as needed. This accelerates token creation for testing.

How to Use

1. To decode: paste a JWT into the token input. The tool automatically parses and displays header and payload. "Bearer " prefix is removed automatically. Review the decoded JSON to see all claims and values.
2. To verify: enter the secret (matching the one used to sign the token). Select the correct encoding (UTF-8 or base64). Click verify. The tool indicates whether the signature is valid. A valid signature means the token was created with that secret and is unmodified.
3. To encode: switch to encode mode. Edit the header JSON (set algorithm) and payload JSON (add your claims). Enter a secret. Click encode. The tool generates a signed JWT you can copy for testing.
4. Review claim information: registered claims (exp, iat, etc.) show human-readable descriptions and formatted values. Check expiration to see if the token is still valid. Timestamp claims display both Unix time and readable date.
5. Use add claim buttons for quick payload editing: add exp (expiration 1 hour out), iat (issued now), etc. Buttons insert properly formatted claims; modify values as needed for your test scenario.

Common Use Cases

• Debugging authentication failures by inspecting JWT contents and signatures
• Verifying that tokens contain expected claims (user ID, roles, permissions)
• Checking token expiration to diagnose "token expired" errors
• Creating test tokens for API development and testing
• Auditing JWT implementations for security (algorithm, claims, lifetime)
• Understanding JWT structure when learning about token-based authentication
• Inspecting tokens received from OAuth/OIDC identity providers
• Verifying that refresh token rotation produces valid new tokens
• Debugging cross-service authentication in microservices
• Creating mock tokens for front-end development without backend
• Testing JWT validation logic by creating tokens with various claims
• Verifying signature algorithm matches between token and validation
• Checking token payload size for performance-sensitive applications
• Demonstrating JWT concepts in education and training

Tips & Best Practices

Never paste production secrets into online tools. The tool runs in your browser, but treat secrets as sensitive. Use test or development secrets for debugging. For production token inspection, decode without verification (safe) or use local tools. Decoding reveals claims without the secret; verification requires it.

Check exp (expiration) first when debugging authentication failures. Expired tokens are the most common issue. The tool shows both the Unix timestamp and human-readable date. If exp is in the past, the token is expired regardless of other factors. Generate a new token or extend the lifetime.

Understand the difference between decode and verify. Decoding shows what is in the token; anyone can decode any JWT since the payload is just base64url encoding. Verification confirms the token was signed with a specific secret. A decoded token with expected claims is not automatically trustworthy; always verify signatures in production systems.

When creating test tokens, set reasonable expiration times. Very short expirations (seconds) are useful for testing expiration handling. Longer expirations (hours, days) work for development convenience. Match your token lifetime to how you will use it in testing. Remember, you can generate new tokens quickly with this tool.

Review all claims, not just standard ones. Custom claims (user roles, permissions, tenant IDs) often cause issues when missing or malformed. The decoded payload shows all claims. Verify that your application's expected claims are present and have correct types (string vs number, array vs object).

Limitations & Notes

The tool supports HMAC algorithms (HS256, HS384, HS512) for signature verification. RSA (RS256, RS384, RS512) and ECDSA (ES256, ES384, ES512) require public/private key pairs and are not supported. For asymmetric algorithms, use language-specific JWT libraries or specialized tools.

JWTs contain claims as plain JSON; sensitive data in payloads is visible to anyone with the token. Never include passwords, secrets, or highly sensitive data in JWT payloads. Claims are not encrypted (standard JWTs use JWS for signatures; JWE for encryption is different and not supported here).

The tool does not validate issuer, audience, or other semantic constraints. It decodes and verifies signatures but does not check whether claims make sense for your application. Semantic validation (correct issuer, intended audience, required scopes) is application-specific and should be implemented in your code.

FAQs