Build and sign JWT tokens with custom claims, expiration, and HMAC algorithms (HS256/384/512). Set registered claims via form, add custom JSON payload — all signed locally in your browser.
The JWT Token Builder creates JSON Web Tokens (JWT) with custom headers, registered claims, and custom payload data. It supports HMAC-based signing (HS256, HS384, HS512) using the Web Crypto API, ensuring cryptographically correct signatures. Unlike online tools that send your secret to a server, this builder runs entirely in your browser — your secret key never leaves your device.
All token generation happens in your browser using the Web Crypto API. Your secret key is never transmitted to any server. However, never use tokens generated by any online tool in production with a secret key you plan to use in your real system. This tool is designed for development and testing — generate production tokens server-side with proper key management.
Essential terms and definitions related to JWT Token Builder.
A compact, URL-safe token format (RFC 7519) for securely transmitting claims between parties. A JWT consists of three Base64URL-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm, the payload contains claims, and the signature verifies integrity.
Hash-based Message Authentication Code — a mechanism for verifying both data integrity and authentication using a cryptographic hash function and a secret key. In JWTs, HMAC algorithms (HS256/384/512) create a signature by hashing the header and payload with the secret key. Both the token creator and validator must share the same secret.
Key-value pairs in the JWT payload that make assertions about the subject. Registered claims (iss, sub, exp) have predefined meanings in RFC 7519. Public claims should use collision-resistant names. Private claims are custom fields agreed upon between the token creator and consumer.
The JWT Builder supports HMAC-based algorithms: HS256 (HMAC with SHA-256), HS384 (HMAC with SHA-384), HS512 (HMAC with SHA-512), and "none" (unsigned). All HMAC signing is performed using the Web Crypto API for cryptographic correctness. RSA and ECDSA algorithms require public/private key pairs and are not supported in this browser-based tool.
No. All JWT generation and HMAC signing happens entirely in your browser using the Web Crypto API (crypto.subtle). Your secret key never leaves your device. The tool makes no network requests during token generation.
JWT registered claims are standardized fields defined in RFC 7519: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). They have specific meanings that JWT libraries and validators understand. All registered claims are optional but recommended for security.
While the tokens generated by this tool are cryptographically valid, you should not use any online tool to generate production tokens with your real secret keys. This tool is designed for development, testing, and learning. Generate production tokens server-side with proper key management, rotation, and environment isolation.
The "none" algorithm creates an unsigned JWT (also called an "unsecured JWT"). The token has no signature, so anyone can read and modify the payload. This is only useful for development and testing — never accept "none" algorithm tokens in production, as it is a common JWT security vulnerability.
The JWT Decoder takes an existing token and splits it into readable header and payload. The JWT Builder goes in the opposite direction: you define the claims and algorithm, and the tool creates a signed token. Use the Builder to create test tokens and the Decoder to inspect tokens you receive from APIs.
Common errors developers encounter and how to resolve them.
Generated token fails validation on the server Ensure the secret key matches exactly between this tool and your server — trailing spaces, newlines, or encoding differences (UTF-8 vs Base64) are the most common causes. Also verify the algorithm matches: if your server expects HS256, generate with HS256. Check that the "exp" claim has not already expired.
Custom claims JSON parse error Custom claims must be valid JSON. Common mistakes: using single quotes instead of double quotes, trailing commas, or unquoted keys. Correct format: {"role": "admin", "permissions": ["read", "write"]}.