JWT Parsing Tool

JWT (JSON Web Token) is an open standard (RFC 7519) for securely transmitting information between parties. JWT consists of three parts separated by dots: Header contains the token type and signing algorithm, Payload contains claims data, and Signature is used to verify token integrity. JWT is commonly used for authentication and information exchange scenarios. When working with JWTs, it is important to distinguish decoding from verification. The header and payload are only Base64URL-encoded, so they can be read even when the signature is invalid. Trust comes from server-side validation of the signature, algorithm, expiration time, issuer, and audience. Sensitive data should not be placed in an unencrypted payload because anyone holding the token can read it. Debugging a token can clarify its contents, but it is not the same as accepting it.

JWT (JSON Web Token, RFC 7519) is composed of three parts - Header.Payload.Signature - joined by the English period '.'. Header: describes the token type and signing algorithm, e.g. {"alg":"HS256","typ":"JWT"}. alg decides how the Signature is computed; the common ones are HS256 (HMAC-SHA256), RS256 (RSA-SHA256), ES256 (ECDSA-SHA256), and none (no signature - forbidden in production). Payload: also called claims, a set of JSON fields. RFC 7519 defines 7 standard registered claims: iss (issuer), sub (subject, usually a user ID), aud (audience), exp (expiration), nbf (not before), iat (issued at), and jti (unique ID). Developers can add any private fields on top, such as userId, role, tenant. Signature: Base64URL-encode the Header and Payload, join them with a dot, then sign with the algorithm specified by alg using a key. HS256 uses HMAC-SHA256(secret, header_b64 + '.' + payload_b64); RS256 uses an RSA private key. The receiver recomputes the signature the same way and checks whether the two match. Base64URL vs standard Base64: '+' becomes '-', '/' becomes '_', and the trailing '=' padding is dropped, so the result can be put in URL paths and query strings without triggering percent-encoding. Note that Base64URL is just an encoding - it provides no encryption or security, and anyone can decode and read the payload. Security boundary: JWT only guarantees 'not tampered with', not 'content is sensitive'. A common mistake is stuffing user phone numbers, ID numbers, or password hashes into the payload, where everyone can see them.

• Three-part structure: Header.Payload.Signature, each Base64URL-encoded; the signature is HMAC(secret, header_b64 + '.' + payload_b64) or RSA(privateKey, same input).
• Base64URL swaps '+' -> '-', '/' -> '_', and drops the trailing '=' padding, so the encoded result can sit directly in a URL (no percent-encoding triggered).
• This tool only verifies HMAC-family signatures (HS256/HS384/HS512) locally. Asymmetric algorithms such as RS256 or ES256 require a public key held by the issuer's JWKS endpoint, so signatures for those tokens must be checked on a server that holds the public key — the page can still decode the header and payload but cannot verify them.
• Standard claims: iss (issuer), sub (subject), aud (audience), exp (expiration Unix timestamp in seconds), nbf (not before), iat (issued at), jti (JWT ID, prevents replay).
• alg=none attack: the alg field must be strictly validated and the none algorithm must be rejected, otherwise an attacker can forge any token; algorithm-substitution attacks (verifying an HS256 token using the public key as the secret) must also be prevented.
• JWT is not encrypted: the payload is plaintext Base64URL-encoded, not encrypted; for confidential content use JWE (JSON Web Encryption), but in practice the common pattern is to keep sensitive data on the backend and reference it via the sub field.