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 Builder & Decoder is a critical security tool for developers working with JSON Web Tokens, designed with a strict zero-data-transmission policy. When debugging authentication flows, pasting real user tokens or private keys into online tools poses a massive security risk. This utility performs all decoding, encoding, and signature verification entirely locally in your browser. Whether you are inspecting the payload of a stale session token or manually signing a new JWT with a secret key for API testing, this tool ensures your credentials never leave your machine.
All cryptographic operations are executed using the Web Crypto API or local JavaScript libraries (like `jose` or `crypto-js`). When decoding, it simply base64url-decodes the header and payload segments. When signing or verifying, it uses the provided secret or key to run the HMAC SHA-256 (or RSA) algorithm locally, generating the signature hash and comparing it against the token.
1. Safely inspecting the payload claims of a production JWT to debug user role or expiration issues.
2. Manually generating and signing custom JWTs with specific claims for testing backend authentication middleware.
3. Verifying if a token signature is valid against a known secret during local API development.
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"]}.