JWT Secret Generator

Just how infeasible is brute-forcing a 256-bit key

32 bytes is 256 bits, giving 2²⁵⁶ possible keys — roughly 10⁷⁷, a number with 78 digits. To put a number on "infeasible": even a hypothetical attacker computing a trillion (10¹²) HMAC guesses per second — far beyond what's actually achievable, since each guess is a full cryptographic hash operation, not a simple comparison — would need on the order of 10⁶⁵ seconds to exhaust the keyspace. The current age of the universe is roughly 10^17.6 seconds. That attack would take about 47 orders of magnitude longer than the universe has existed. This is why the actual security of an HMAC-signed JWT rarely comes down to key length at all — it comes down to whether the secret leaked, was guessable as a dictionary word, or was reused somewhere it shouldn't have been.

This tool deliberately won't generate anything shorter. The byte sizes are fixed to exactly 32, 48, or 64 — there's no option for a "quick" 16-byte key, because HMAC signing security depends on the key being at least as long as the hash's output size (RFC 2104's recommendation, echoed in RFC 7518 for JWS). A shorter key doesn't make signing faster in any way that matters; it just narrows the space an attacker has to search.

How to use this tool

1. Select the algorithm you will use for signing (HS256 is the default in most libraries).
2. Select the output format — Base64URL is the most portable; Hex is easiest to inspect.
3. Click Generate to create a fresh cryptographically secure key.
4. Copy the key and store it in your environment variables or secrets manager.
5. Use the JWT Generator to sign a token with this secret.

Why the format matters more for compatibility than security

All three output formats — Base64URL, Base64, and Hex — represent the exact same underlying random bytes from RandomNumberGenerator.GetBytes(). None is "more random" or "more secure" than another; they differ only in which characters the text representation uses, which matters entirely for where you're about to paste the value. Standard Base64 includes +, /, and trailing = padding — characters that need escaping in a URL query string or a YAML value, and that occasionally trip up naive .env file parsers that don't expect punctuation. Base64URL swaps those for - and _ and drops the padding specifically so the result is safe to drop into a URL or environment variable with zero quoting. Hex is the least space-efficient (twice the character count of Base64 for the same entropy) but the easiest to read character-by-character if you're manually diffing two keys or pasting into a tool that expects raw hex.

Format guide

Security best practices

Store secrets in environment variables or a secrets manager (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault). Never hard-code secrets in source code or commit them to version control. Rotate secrets periodically and immediately if suspected of compromise.

One thing to know before pasting this into the JWT Generator

Whichever format you pick here, the output is still just a string of printable characters representing those random bytes — it isn't the raw bytes themselves. This site's own JWT Generator signs whatever you paste into its Secret field as plain UTF-8 text, not by decoding it back into the original bytes first. For everything on this site that's invisible — generate here, sign there, decode there, all consistent. It only becomes relevant if you need a token signed here to verify against a separate system that base64-decodes the secret before hashing; in that case, confirm the other system treats the secret as raw text too, or the signatures won't match.