JWT Debugger, Decoder & Encoder Studio

1. What is a JSON Web Token (JWT)?

A **JSON Web Token (JWT)** is a compact, URL-safe container used for authorization and stateless user session management across modern web applications, microservices, and mobile APIs. RFC 7519 specifies the format of JWTs as 3 Base64Url encoded segments separated by dots:

2. Standard RFC 7519 Registered Claims Reference

Registered claims are reserved key names defined by the IANA JSON Web Token Registry to ensure interoperability across OAuth2 and OpenID Connect (OIDC) identity providers:

Beyond these registered names, RFC 7519 also permits public claims (custom names registered in the IANA registry or namespaced as a URI to avoid collisions) and private claims — arbitrary key-value pairs agreed upon between the parties issuing and consuming the token, such as role, permissions, or tenant_id. This tool decodes and displays every claim present in the payload regardless of whether it's a registered, public, or private claim — it doesn't filter or hide any fields.

Where You'll Actually Encounter JWTs

JWTs most commonly travel inside the HTTP Authorization header as a Bearer token (Authorization: Bearer eyJhbGci...), which is the pattern used by most REST APIs, single-page applications calling a backend, and mobile apps authenticating against a cloud service. They also appear as the access and ID tokens issued by OAuth2 and OpenID Connect identity providers (Auth0, Firebase Auth, AWS Cognito, Okta, Keycloak), as session tokens stored in browser cookies or local storage by SPA frameworks, and as service-to-service authentication tokens in microservice architectures where an internal API needs to confirm which upstream service is calling it. Copying any of these values into this debugger — minus the "Bearer " prefix — will decode it the same way regardless of which system issued it, since the JWT format itself is a single open standard. A quick way to tell a JWT apart from a plain API key or opaque session ID at a glance: a JWT is always exactly three Base64Url segments separated by two dots, and the first segment, once decoded, always starts with a JSON object containing an "alg" field — plain API keys and random session identifiers have neither property. Recognizing this shape quickly is a handy debugging habit on its own, well before you paste anything into a decoder.

3. JWT Security Vulnerabilities & Prevention Best Practices

• Never Store Secrets Client-Side: HMAC secret keys must remain strictly confidential on backend servers.
• Reject 'alg: none' Attacks: Configure servers to explicitly enforce expected algorithms (e.g. HS256) and reject unsigned alg: none header manipulations.
• Use Short Expiration Times: Set access token expiry times (exp) between 15 minutes to 1 hour, paired with HTTP-only refresh tokens.

4. How Decode & Verify Mode Works, Step by Step

Paste any JWT string into the Encoded Token String box and the studio immediately runs it through processJWT(), which performs four distinct operations in sequence:

1. Structure check. The token is split on its dots; if it doesn't split into exactly 3 segments, the tool immediately flags "Invalid JWT Token Structure" rather than attempting a partial decode.
2. Header decode. The first segment is Base64Url-decoded and parsed as JSON, revealing the alg and typ fields in the color-coded rose panel.
3. Payload decode & expiration check. The second segment is decoded the same way, and if an exp claim is present, its Unix timestamp is compared against Date.now() to render a live "Token Active (expires in N minutes)" or "Token Expired on [date]" banner.
4. Signature verification. Only for HMAC algorithms (see the honest breakdown below), the tool recomputes the signature from the header and payload using your secret key and compares it byte-for-byte against the signature segment of the token you pasted.

You never need to click a "Decode" button — every keystroke in the token box, the secret field, or the "Secret is Base64" checkbox re-triggers this entire pipeline, so you can watch the signature status flip from "Verified" to "Invalid Signature" in real time as you experiment with a wrong character in the secret.

5. What Signature Verification Actually Does (and Where It Stops)

Many so-called "JWT debuggers" online only Base64-decode the header and payload and stop there — they never touch the third segment at all, which means they cannot tell you whether a token is genuine or forged. This tool is built to go further for the algorithm family where it's realistically possible to do so client-side, and to be transparent about the one family where it deliberately does not:

The practical takeaway: if you paste in an HS256/384/512 token and provide the correct secret, a "Signature Verified!" result here is a real, mathematically meaningful confirmation that the token hasn't been tampered with since it was signed with that secret. If you paste in an RS256 or ES256 token, treat this tool strictly as a decoder for that token — for actual signature validation of asymmetric tokens, you need a library or endpoint that has access to the issuer's public key or JWKS endpoint.

6. Using Encode / Generate Mode to Build Test Tokens

Switching to the "Encode / Generate JWT" tab turns the same Header and Payload panels into editable JSON fields. Edit the claims directly (change sub, add a custom claim, adjust exp to test an expiry scenario), set a secret, and the tool Base64Url-encodes both segments, computes a fresh HMAC signature with CryptoJS, and assembles a complete, genuinely valid three-part JWT string back into the token box. This is useful for generating realistic test fixtures for your own backend's auth middleware, or for constructing an intentionally-expired token to confirm your server correctly rejects it. The two preset buttons ("Valid Auth Token" and "Expired Token") demonstrate this exact same generation pipeline with pre-filled claims, so you can see a live example before building your own.

7. Real-World Use Cases for a JWT Debugger

8. Common JWT Mistakes This Tool Helps You Catch

• Confusing "decoded" with "verified." Anyone can Base64-decode a JWT without any key at all — that only proves the token is well-formed, not that it's authentic. Only a passing signature check (HMAC here, or public-key verification on your backend for RS256/ES256) proves authenticity.
• Forgetting the 'Secret is Base64' checkbox. Some backend frameworks store the signing secret as a Base64-encoded string rather than raw text — leaving this checkbox in the wrong state will make a genuinely valid token appear to fail verification.
• Assuming expiration is enforced automatically. This tool (and JWTs in general) only carry the exp timestamp as data — actual rejection of expired tokens has to be implemented explicitly on your server; the token itself doesn't stop working on its own.
• Editing the payload without regenerating the signature. Because the signature covers the header and payload together, changing even one character in the decoded JSON (in Decode mode) and pasting it back in as a new token will always fail verification unless you re-sign it in Generate mode.
• Trusting client-side claims for authorization decisions. A JWT payload is only Base64-encoded, not encrypted — anyone holding the token can read every claim inside it, even without the secret. Never put secrets or sensitive personal data directly into a JWT payload.

9. Privacy: Why Client-Side JWT Debugging Matters

A JWT often carries session identifiers, user IDs, roles, and sometimes email addresses or internal permission flags — and its signing secret is one of the most sensitive values in an entire authentication system. This tool performs Base64Url decoding, JSON parsing, and HMAC signature computation entirely inside your browser tab using native JavaScript and the CryptoJS library loaded once from a CDN; there is no fetch or form submission anywhere in the decoding, verification, or generation logic that would transmit your token or secret key to any server. That distinction matters in practice: pasting a production signing secret into a tool that silently phones it home to a third-party server would be a serious security incident, whereas a tool that keeps everything local carries no such risk beyond your own machine's security.

10. How This Compares to jwt.io and Backend Libraries

The best-known JWT inspection tool on the web is jwt.io, and this studio deliberately borrows its core idea: paste a token, see the decoded parts, verify the signature if a secret is supplied. The functional difference worth knowing before you paste in anything sensitive is how each tool handles the secret key and the network. This page runs its HMAC computation with the CryptoJS library loaded once from a CDN and executed entirely in your tab, with no server round-trip for the decode, verify, or generate operations. Backend libraries — jsonwebtoken in Node.js, PyJWT in Python, or the built-in JWT support in frameworks like Spring Security and ASP.NET — remain the correct choice for actually issuing and verifying tokens inside a running application, since they're maintained alongside security patches, support the full range of asymmetric algorithms with proper key management, and are designed to run in a trusted server environment rather than a browser tab. Use a browser-based debugger like this one for inspection, learning, and quick manual checks; use a vetted server-side library for anything that issues or verifies tokens in production.