JWT Debugger — Decode and Inspect JWT Tokens — Calculator
Decode and inspect JSON Web Tokens (JWT) client-side. View the header, payload, and signature information without sending data to any server.
JWT Debugger
Enter values and click Calculate
Enter Values
Embed Code
Copy and paste this HTML snippet into any web page to embed this calculator directly.
<iframe src="http://127.0.0.1:59362/embed/devtools/jwt-debugger?ref=embed" title="JWT Debugger — Decode and Inspect JWT Tokens — Calculator" width="100%" style="max-width:600px; border:none; height:500px;" loading="lazy"></iframe>
Direct Link
Share this link to let others open the calculator in their browser.
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
JWT Header
JSON object containing metadata about the token, typically including the signing algorithm (alg) and token type (typ). Common algorithms: HS256, RS256, ES256.
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.
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 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.
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 This Calculator
- 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
| From | To |
|---|---|
| HS256 (HMAC + SHA-256) | Symmetric signing — same secret for sign and verify. Fast but requires shared secret. |
| RS256 (RSA + SHA-256) | Asymmetric signing — private key signs, public key verifies. No shared secret needed. |
| exp claim | Expiration time (Unix timestamp). Tokens should not be accepted after this time. |
| iat claim | Issued-at time (Unix timestamp). When the token was created. |
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
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.
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.
Worked Examples
Inspecting an OAuth2 access token to check expiration time
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImtleS0xMjMifQ.eyJzdWIiOiJ1c2VyQGV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9hdXRoLmV4YW1wbGUuY29tIiwiYXVkIjoiYXBpLmV4YW1wbGUuY29tIiwiZXhwIjoxOTkyNTkyODAwLCJpYXQiOjE5OTI1OTEwMDAsInNjb3BlIjoicmVhZDpwcm9maWxlIHdyaXRlOnBvc3RzIn0.dGVzdC1zaWduYXR1cmU
Result:
Insight: Paste any JWT into the debugger and look at the payload. The "exp" claim (Unix timestamp) tells you exactly when the token expires. The "iat" claim shows when it was issued. The "aud" claim should match the API you are calling — if it says "api.example.com" but you are calling "other-api.com", the token will be rejected. The "scope" claim reveals what permissions the token grants. This is the fastest way to debug "401 Unauthorized" errors in OAuth2 flows.
Checking if a JWT uses a secure signing algorithm
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
Result:
Insight: Look at the decoded header's "alg" field. If it says "none" (as in this example), the token has NO signature and should NEVER be accepted by a server — this is the infamous "alg:none" attack. Valid algorithms include HS256, HS384, HS512 (symmetric/HMAC) and RS256, RS384, RS512, ES256, ES384, ES512 (asymmetric). If you see "none", "NONE", or "None" in production tokens, your JWT library is misconfigured and vulnerable.
Verifying a rarely-seen custom claim in a vendor API token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsInRlbmFudF9pZCI6InRlbmFudC1hYmMxMjMiLCJyb2xlIjoiYWRtaW4iLCJwZXJtaXNzaW9ucyI6WyJyZWFkIiwid3JpdGUiLCJkZWxldGUiXSwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5OTI1OTI4MDB9.dGVzdC1zaWduYXR1cmUtZm9yLWRlbW9uc3RyYXRpb24
Result:
Insight: Beyond standard claims (sub, iss, aud, exp, iat), many vendors add custom claims like "tenant_id", "role", "permissions", or "org_id". The JWT debugger shows ALL claims in the payload, even non-standard ones. This is critical when integrating with third-party APIs that embed routing or authorization data in the JWT — you can see exactly what the vendor expects your system to consume.
Limitations
- 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 (correct 3-part format, valid base64url) 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.
Frequently Asked Questions
Sources & References
Related Calculators
Reviews
No reviews yet. Be the first to share your experience with JWT Debugger — Decode and Inspect JWT Tokens — Calculator.
Write a Review