πŸ”
/

JWT Token Inspector & Debugger 100% Client-Side β€’ Web Crypto HMAC β€’ Zero Latency

Decode, inspect, verify, and generate JSON Web Tokens (RFC 7519). Features real-time bidirectional synchronization, three-color token inspection, cryptographic Web Crypto HMAC validation, expiration auditing, and zero server exposure.

⚑ Sample Tokens:

πŸ”’ Encoded Token

Header
.
Payload
.
Signature
Paste or Edit Raw Token: Auto-decodes live
βœ“ Valid JWT Structure βœ“ Signature Verified

πŸ”“ Decoded Token Data

Edit JSON to automatically re-encode & sign token
HEADER: Algorithm & Token Type
PAYLOAD: Data Claims & Subject
VERIFY SIGNATURE: HMAC Secret
Enter secret key for in-browser cryptographic verification via Web Crypto API:
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

πŸ“Š Decoded Claims Inspector & RFC 7519 Meanings

Parsed subject claims and registered token metadata
Claim Key RFC Description / Meaning Parsed Claim Value
Loading token claims...

πŸ’» Server-Side Verification Snippets


    

πŸ“˜ The Complete Guide to JSON Web Tokens (JWT)

JSON Web Token (RFC 7519) is a compact, URL-safe specification for securely transferring claims between distributed parties. Replicating the functionality of jwt.io with enhanced client-side privacy.

🧱 The Three Parts of a JWT

A JWT consists of three parts separated by dots (.): Header (defines algorithm e.g. HS256 and token type), Payload (contains subject identity and claims), and Signature (ensures the token has not been tampered with).

πŸ” Encoding ≠ Encryption

JWT payloads are Base64URL-encoded, not encrypted. Anyone who intercepts the token can read all payload claims. Never store sensitive credentials (passwords, social security numbers, unencrypted secret keys) inside a standard JWT payload.

πŸ›‘οΈ Symmetric vs. Asymmetric Signing

HMAC algorithms (HS256, HS384, HS512) use a single shared secret for both signing and verification. Asymmetric algorithms (RS256, ES256) use a private key to sign and a public key (often shared via JWKS endpoints) to verify.

⏰ Expiration & Clock Skew

Always enforce an expiration claim (exp) with a short lifespan (e.g. 15 minutes to 1 hour). Pair with refresh tokens in authentication systems. Modern verifiers allow a small clock skew (typically 1–2 minutes) to account for slight server time divergence.

⚠️ Security Warning: "alg: none"

Early JWT vulnerabilities allowed attackers to bypass verification by setting {"alg": "none"} and stripping the signature. Secure verification libraries must explicitly restrict allowed algorithms and reject unsigned tokens.

πŸ”’ 100% Client-Side Privacy Guarantee

All token parsing, Base64URL encoding, and cryptographic HMAC signature validation execute 100% locally in your client browser using the native Web Cryptography API. Zero tokens or secrets are ever uploaded to any server.