JWT Debugger

Decode, visualize, and cryptographically verify JSON Web Tokens directly in your browser. No server upload — your tokens stay private. Full support for HS256, RS256, ES256 signature validation with local cryptographic operations.

Paste the appropriate secret or public key. The tool auto-detects algorithm from token header.
Zero‑knowledge architecture – All JWT parsing, decoding, and signature verification happens inside your browser using Web Crypto API. No token data is ever transmitted to any server. Your secrets / public keys stay local.

Understanding JSON Web Tokens

JSON Web Token (JWT, RFC 7519) is an open standard for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are digitally signed using a secret (HMAC) or a public/private key pair (RSA or ECDSA). They are widely used in authentication, authorization, and API security (OAuth2, OpenID Connect).

JWT Structure: header.payload.signature

Header – contains metadata like the signing algorithm (alg) and token type (typ).
Payload – contains claims (registered, public, private).
Signature – ensures integrity and authenticity; created by signing the concatenated header and payload with the secret/key.

Why Cryptographic Verification Matters

An unverified JWT can be maliciously crafted. Attackers can alter claims (e.g., elevate privileges, extend expiry) if the signature is not validated. This tool performs full signature validation for HS256 (HMAC-SHA256), RS256 (RSA-SHA256) and ES256 (ECDSA-SHA256) using Web Crypto API, ensuring you can trust the token before accepting its contents.

Security Best Practices:
  • Never expose your HS256 shared secret or private keys in client-side code; use this tool only for debugging tokens you own.
  • Always validate exp (expiration), aud (audience), and iss (issuer) claims.
  • Prefer RS256/ES256 for distributed systems to avoid sharing secrets.
  • Use short-lived tokens and implement refresh token rotation.

Algorithm Support & Validation Details

Algorithm Key type Verification method (local) Use case
HS256 Symmetric secret HMAC-SHA256 recomputed & compared in constant-time Single-server / internal microservices
RS256 RSA public key (PEM) WebCrypto RSASSA-PKCS1-v1_5 with SHA-256 OAuth2 / OpenID Connect, distributed trust
ES256 ECDSA public key (PEM) WebCrypto ECDSA with P-256 curve & SHA-256 Modern, lightweight public key signatures

Generating Test Key Pairs (RS256 / ES256)

? Generate RSA key pair (for RS256) using OpenSSL: 

# Generate private key
openssl genrsa -out private.pem 2048
# Extract public key
openssl rsa -in private.pem -pubout -out public.pem

Paste the contents of public.pem (including -----BEGIN PUBLIC KEY----- ... -----END PUBLIC KEY-----) into the verification key field to test RS256 signatures.

⚡ Generate ECDSA key pair (for ES256): 

openssl ecparam -genkey -name prime256v1 -out private_ec.pem
openssl ec -in private_ec.pem -pubout -out public_ec.pem

Note: For HS256, simply use any strong random string as the shared secret.

Critical JWT Attack Vectors & Mitigations

Algorithm Confusion Attack (RS256 → HS256)

If a server accepts tokens with the alg header set to HS256 but expects an RS256 public key, an attacker can sign the token using the public key (which is often exposed) as if it were an HMAC secret. The server will then verify the token as valid, leading to privilege escalation.

Defense: Always enforce strict algorithm mapping. Reject tokens where the alg does not match the expected key type. Our verification tool rejects HS256 when a public key is provided and flags algorithm mismatches.

kid (Key ID) Injection & Path Traversal

The kid (Key ID) header parameter is used to reference a specific key from a set. Attackers can inject kid values like ../../../../etc/passwd or http://evil.com/key.json to force the server to load an arbitrary key file or URL, potentially bypassing signature verification.

Defense: Whitelist allowed kid values, avoid dynamic file reads, and never use user-controlled input to load cryptographic keys. Our inspector displays the kid field if present, allowing you to audit it.

jku (JWKS URL) Injection

The jku (JSON Web Key Set URL) header tells the server where to fetch the public key. Attackers can point jku to a malicious URL hosting their own key, thereby creating a valid signature for any forged token.

Defense: Strictly whitelist trusted jku endpoints or ignore jku entirely. Prefer pre‑configured keys. Use this debugger to inspect any suspicious jku or kid fields.

Pro tip: Paste any JWT into this tool and review the header for unexpected fields like kid, jku, or x5u. Always verify signatures with the correct expected key before trusting the token.

Real-world applications

  • API Authentication: JWT as Bearer token in Authorization header.
  • Single Sign-On (SSO): SAML alternatives with OpenID Connect.
  • Client-side sessions: Stateless session management reduces database load.
  • Security auditing: Debug tokens from logs or intercepted requests (with permission).
Expert Review – This JWT toolkit was developed by getzenquery Tech team and follows the RFC 7519 specification. Cryptographic operations leverage the native Web Crypto API, ensuring FIPS-compliant implementations in modern browsers. Reviewed by the TokenSecLab team, last updated April 2026. All attack examples and defensive strategies are derived from OWASP API Security Top 10 and industry best practices.

Frequently Asked Questions

It proves the token was issued by a party possessing the secret/private key and that the content hasn’t been tampered with. Without verification, JWTs can be forged.

Absolutely. All processing occurs locally in your browser – no data leaves your device. You can even disconnect from the internet after the page loads.

Make sure you paste the correct public key (PEM format including BEGIN/END lines). Also verify the token hasn't been altered and the algorithm in header matches the key.

For security reasons, 'none' algorithm is flagged as insecure and verification will always fail. We enforce strict validation per best practices.

Our tool displays the full header JSON. Look for unexpected kid, jku, or x5u fields. If they point to external URLs or unusual paths, the token might be malicious.
References: RFC 7519 | Auth0 JWT Handbook | JWT.io | OWASP API Security Top 10