JWT (JSON Web Token) is an open standard defined by the IETF in RFC 7519 (RFC 7515 describes the JWS signing form, RFC 7516 describes JWE encryption, RFC 7517 defines JWK keys) for securely transferring 'asserted' user information between HTTP requests, OIDC flows and microservice calls. A standard JWT string is composed of three Base64URL-encoded segments: Header (algorithm and type), Payload (Claims, the user data) and Signature (a key-based signature over the first two). The three segments are joined by a literal dot `.`, e.g. `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.
**JWT is not encryption.** This is the most common misconception. The Payload is plaintext by default — anyone can Base64URL-decode it and read the contents. JWT provides **tamper-evidence**, not confidentiality: the server re-signs Header.Payload with the shared key and compares to the token's Signature. If they match, the token has not been altered in transit. This is the 'train ticket with an anti-counterfeit stamp' metaphor: the inspector cares whether the ticket is genuine, not whether the QR code is unreadable.
JWT cleanly divides responsibilities across 13 algorithms. **HMAC family** (HS256/HS384/HS512) uses a symmetric key for both signing and verifying, fast and simple, suitable for a single service or a trusted cluster; the secret must be at least the digest length (e.g. ≥ 32 bytes for HS256). **RSA family** (RS256/RS384/RS512) uses RSASSA-PKCS1-v1_5, the most common asymmetric scheme — signers hold the private key, verifiers hold the public key. **RSA-PSS family** (PS256/PS384/PS512) uses the newer RSA-PSS padding with stronger security guarantees, preferred by AWS SigV4 and modern OIDC identity providers. **ECDSA family** (ES256/ES384/ES512) uses elliptic curves (P-256/P-384/P-521 respectively) with shorter signatures and better performance. **EdDSA** (mainly Ed25519) is extremely fast and deterministic (same message + same key = same signature every time) and is the recommended algorithm in OAuth 2.1 and new protocols.
Security is where JWT trips up in production. The OWASP JWT Cheat Sheet calls out at least four hard rules: (1) never put passwords, national IDs, card numbers or API keys as plaintext into the Payload; (2) the server must **never trust the alg field** declared in the Token Header — it must verify with a hard-coded algorithm, otherwise an attacker rewriting the header to `alg: none` bypasses everything (this is the root of historical CVEs such as CVE-2015-9235); (3) HMAC secrets must be random and at least 32 bytes, never short strings; (4) verification is more than signature checks — you must also validate `exp` (expiration), `nbf` (not-before), `iss` (issuer) and `aud` (audience). This tool highlights every one of these Claims in the UI so you can tell at a glance whether a failure is a signature problem, a timing problem, or a Claims problem.
JWT is not a replacement for sessions. Sessions store user state on the server (Redis or a database); JWT packs the state into the token. Microservice architectures, stateless APIs, mobile clients and CORS-heavy setups benefit from JWT; traditional enterprise systems and flows that require instant revocation (e.g. 'kick this user out now') are still better served by sessions. This tool covers both pure JWT debugging and the Token-parsing / signature-verifying / Payload-editing steps of a session-to-JWT migration.