Build a payload with custom claims, choose HS256, HS384, or HS512, enter a secret, and generate a signed JSON Web Token entirely in your browser using the Web Crypto API. Pairs directly with the JWT Decoder.
This tool builds a complete, correctly-signed JSON Web Token from a payload you define and a secret you provide, using the exact same HMAC-SHA signing process any real JWT-issuing backend uses under the hood. It's designed for learning how JWTs are structured, testing how a downstream service handles specific claim combinations, or generating a token for local development and debugging — without needing to spin up an actual authentication backend or write a one-off signing script just to produce a test token.
Signing starts by building the header (an object with alg and typ fields) and the payload (your claims), each converted to JSON and then Base64URL-encoded — a URL-safe variant of standard Base64 that avoids characters with special meaning in URLs. These two encoded segments are joined with a dot to form the 'signing input.' The Web Crypto API then computes an HMAC (Hash-based Message Authentication Code) over that signing input, using your secret as the HMAC key and the hash function specified by your chosen algorithm (SHA-256 for HS256, and so on). The resulting signature is itself Base64URL-encoded and appended as the token's third and final segment — the complete token is simply these three segments joined by dots: header.payload.signature.
HMAC signing is symmetric by design — the exact same secret used to produce a signature is also the only value that can verify it, since HMAC has no separate public counterpart to a private signing key the way asymmetric algorithms do. This has a direct practical consequence: whatever secret you type into this tool must be the exact same secret configured wherever you intend to verify the resulting token (your API server, or the JWT Decoder tool if you're just testing) — even a single differing character in the secret produces a completely different, non-matching signature, with no partial credit for being 'close.'
A production JWT signing secret should be long (at least 256 bits, i.e. 32+ random bytes for HS256, more for HS384/HS512) and genuinely random — never a short, memorable phrase or a value reused from another system — since a weak or guessable secret undermines the entire point of signing, letting an attacker who guesses or brute-forces it forge arbitrary valid tokens. This tool's default example secret ('your-256-bit-secret,' the same one used by jwt.io's own examples) is intentionally a well-known, public placeholder meant only for learning and testing — never use it, or any other secret typed into a client-side tool like this one, for a real production system.
This tool is designed to pair directly with the JWT Decoder: generate a token here with your chosen claims and secret, then paste it into the Decoder to confirm the header and payload decode back to exactly what you intended, and enter the same secret there to confirm the signature verifies successfully. Working through this full round trip — generate, decode, verify — is one of the fastest ways to build an accurate mental model of how JWT-based authentication actually works underneath the libraries that normally handle it automatically, since you're performing each step explicitly rather than trusting a framework to do it invisibly.
JWT Generator creates signed tokens for testing and learning. These related developer tools cover the rest of the JWT and authentication workflow.