JWT Generator: Sign Tokens with HMAC-SHA

How to use the jwt generator

1. Select the signing algorithm: HS256, HS384 or HS512.
2. Edit the Header JSON if you need custom fields. The alg value is always set to the algorithm you selected.
3. Enter your claims in the Payload JSON field.
4. Type your shared secret into the Secret Key field. Use a strong key from a jwt secret generator for production tokens.
5. Copy the generated token from the output area.

How HMAC-SHA signs a JWT

A JSON Web Token consists of three Base64URL-encoded parts separated by dots: the header, the payload and the signature. To create the signature, the jwt generator concatenates the encoded header and payload with a dot, then applies the HMAC algorithm using your secret key.

For HS256, the formula is:

HMAC-SHA256(base64url(header) + "." + base64url(payload), secret)

The resulting hash bytes are then Base64URL-encoded and appended as the third segment. HS384 uses SHA-384 (producing a 48-byte signature) and HS512 uses SHA-512 (producing a 64-byte signature). The underlying SHA-2 algorithms process data in 512-bit blocks for SHA-256 and 1024-bit blocks for SHA-384 and SHA-512.

Common JWT claims reference

While you can put any valid JSON in the payload, registered claim names have specific meanings defined in RFC 7519. Using them correctly ensures other systems interpret your token properly.

Base64URL encoding vs standard Base64

JWTs use Base64URL encoding rather than standard Base64. The differences are small but critical for URLs and HTTP headers. Standard Base64 uses + and / as characters 62 and 63, while Base64URL replaces them with - and _. Additionally, Base64URL omits the trailing = padding characters.

When this jwt generator encodes your header and payload, it strips all whitespace from the minified JSON before encoding. This ensures the byte sequence is deterministic, matching what server-side libraries produce. If you manually format your JSON with spaces or newlines before pasting it in, the tool minifies it via JSON.stringify(JSON.parse(input)) to guarantee consistency.

Security considerations for HMAC secrets

The security of an HMAC-signed JWT relies entirely on the secrecy and strength of the shared key. If an attacker obtains the secret, they can forge arbitrary tokens. For HS256, RFC 7518 recommends a key length of at least 256 bits (32 bytes). For HS384, use at least 48 bytes, and for HS512, use at least 64 bytes.

Never hard-code secrets in client-side JavaScript. This tool is designed for development, debugging and testing workflows where you need to quickly create a signed token. For production applications, generate and store keys securely on your server. You can use a jwt secret generator to create cryptographically strong random keys.

Because symmetric algorithms like HS256 require both the signer and verifier to share the same secret, they are best suited for closed systems where you control both ends. If you need to allow third parties to verify tokens without sharing your signing key, consider asymmetric algorithms like RS256 instead.

Debugging and verifying tokens

If a receiving service rejects your token, the most common causes are mismatched algorithms, extra whitespace in the JSON, or incorrect secret encoding. Ensure the alg field in your header exactly matches the algorithm expected by the verifier. A header specifying HS256 sent to a service expecting RS256 will always fail.

You can decode and inspect the contents of any JWT without the secret using a jwt decoder. This helps verify that your payload structure is correct before troubleshooting the signature. If you need to compute raw HMAC hashes outside of the JWT format, the hmac sha256 generator provides direct access to the underlying cryptographic primitive.

Worked examples