JWT Generator

The JWT Generator creates JSON Web Tokens from a header, payload, and signing settings. A JWT has three Base64URL-encoded parts and is commonly used to carry claims such as user ID, roles, expiration time, issuer, and audience between services. This tool helps with API testing, local development, education, debugging, and quickly producing example tokens. A generated token is only trustworthy when key management, algorithm choice, expiration, and server-side validation are handled correctly. Secrets should not be pasted into public examples, weak algorithms or overly long lifetimes are risky, and sensitive personal or business data should not be placed in an unencrypted payload.

The JWT generator and parser are inverse processes: parsing takes the three parts apart, generating assembles them. The core is computing the Signature segment. Assembly flow: 1) Build the Header JSON, e.g. {"alg":"HS256","typ":"JWT"}; 2) Build the Payload JSON with standard and private claims; 3) Base64URL-encode Header and Payload separately to get h_b64 and p_b64; 4) Join h_b64 and p_b64 with a period to form input = h_b64 + '.' + p_b64; 5) Compute the signature: HMAC-SHA256/384/512(secret, input) depending on alg; 6) Base64URL-encode the signature result; 7) The final token is input + '.' + sig_b64. HMAC-SHA256 signing: use the secret as the key (>= 32 bytes) and run HMAC over the input. Internally HMAC runs two SHA-256 rounds: the secret first derives ipad/opad keys, then SHA256(secret XOR ipad || msg) XOR opad. Key strength: secret length directly determines security. RFC 7518 requires HS256 keys to be >= 256 bits (32 bytes). In production always use a cryptographically secure RNG (e.g. crypto.randomBytes); never use strings like 'secret', 'password', or '123456'. Common pitfalls: 1) alg-substitution attack: the server must strictly validate alg, and must not read alg from the token header and dispatch to the matching algorithm; 2) Weak keys: a too-short secret can be brute-forced; 3) Payload tampering: HMAC guarantees integrity - if an attacker changes the payload, server-side verification fails; 4) Token leak: JWTs cannot be revoked, so once a token is out, the only fix is to wait for it to expire. Scope of this tool: only HS256/HS384/HS512 are generated. Asymmetric algorithms such as RS256 (RSA) and ES256 (ECDSA) require a private key kept on the issuer side and are produced by a backend signing service or a dedicated SDK, not by this page.

• HMAC-SHA256 signing core: HMAC(secret, header_b64 + '.' + payload_b64), output a 256-bit signature and Base64URL-encode it.
• HS256 key length must be >= 32 bytes (256 bits); recommend generating with crypto.getRandomValues or crypto.randomBytes - short keys are vulnerable to dictionary attacks.
• This tool only generates HMAC-signed tokens (HS256/HS384/HS512). Asymmetric algorithms such as RS256 or ES256 require a private key kept on the issuer side and are not produced here — use a backend signing service or a dedicated SDK for those.
• iat/exp/nbf are all Unix timestamps in seconds (not milliseconds); servers usually require exp > now(), nbf <= now(), and iat <= now().
• alg=none attack: maintain a server-side whitelist of allowed algorithms (e.g. ['HS256']); never pick the algorithm dynamically from the token header. Many JWT libraries historically allowed alg=none by default - that's a known vulnerability.
• A JWT cannot be revoked once issued - the only recourse is to wait for exp. For active revocation, maintain a jti blacklist or use a short-lived access token plus a refresh token.