Online JWT Debugger & Decoder

Decode JSON Web Tokens instantly. Verify signatures (HS256/RS256), inspect claims, and check expiration dates without secret keys.

EN TR RU

Input

JWT
Secret / Public Key (optional)
Decodes header/payload. Verification supports HS* and RS256 when key is provided.

Output

Demystifying Authentication: Anatomy of a JWT

In the world of RESTful APIs and distributed systems, the JSON Web Token (JWT) is the standard for secure information exchange. However, a JWT is just a long, cryptic string of characters separated by dots. When authentication fails, blindly staring at this string gets you nowhere. Our JWT Debugger acts as an X-ray for your tokens. It splits the structure into its three core components: the Header (algorithm info), the Payload (user data/claims), and the Signature. This visibility is essential for debugging login issues, permission errors, and session timeouts.

Signature Verification: HS256 vs. RS256

The integrity of a token relies entirely on its signature. A common pitfall in implementing JWT authentication is mismatching algorithms (e.g., configuring the server for RS256 but the client for HS256). Our tool parses the header to identify the algorithm (`alg`) instantly. Furthermore, it provides an interactive signature verification/generator field. By inputting your secret key (for HS256) or public key (for RS256/ES256), you can mathematically confirm if the token was tampered with in transit or if it was genuinely issued by your authorization server.

Inspecting Claims: Expiration, Issuer, and Scope

Debugging "401 Unauthorized" errors often boils down to checking the "Claims" within the payload. Is the token expired (`exp`)? Is it being used before its valid time (`nbf`)? Does it have the correct permissions (`scope` or `roles`)? Our decoder translates raw Unix timestamps into human-readable dates, allowing you to spot expiration issues immediately. It also formats complex JSON objects within the payload, making it easy to verify custom claims like `user_id`, `tenant_id`, or specific API access rights used in OAuth2 and OpenID Connect flows.

FAQ
Yes. We utilize a strict client-side-only architecture. All decoding and verification logic executes within your browser's memory. Your tokens and secrets never leave your device.
A standard JWT (JWS) is "Signed", not "Encrypted". The Base64Url encoding allows data transport but does not hide it. Never store sensitive info like passwords in the JWT payload.
This means the content has changed or the key is wrong. Ensure you are using the exact Secret Key (for HMAC) or the correct Public Key (for RSA) corresponding to the token issuer.
`kid` stands for Key ID. It hints to the server which specific key (from a set of keys) was used to sign the token. This is crucial for systems that rotate keys regularly.
Our tool focuses on standard JWS (Signed) tokens. Nested JWTs (a signed token inside an encrypted token) require decryption first, which is outside the scope of a standard debugger.