A real, cryptographically random token, not a pattern-based fake
Requesting 32 bytes in hex format produces a 64-hex-character token like c849eabfba6c4486b09aaf0d729d0c2c5298eb2984978126ac43a2fc9c9de86b -- each byte of true randomness becomes 2 hex characters, so 32 bytes always produces exactly 64 hex characters.
This uses the browser's CSPRNG (cryptographically secure pseudo-random number generator, via the Web Crypto API), not Math.random() -- a meaningful distinction, since Math.random() is not designed to be unpredictable enough for security-sensitive values like API keys or session tokens, while a CSPRNG specifically is.
32 bytes (256 bits) of entropy is a common, solid choice for an API key or secret -- large enough that brute-forcing or guessing the value is computationally infeasible with current technology, which is why 256-bit keys are a standard recommendation across many security contexts.
What this generator won't do for you
CSPRNG in the browser. Treat the output as a secret and do not reuse samples. Every token this tool generates is genuinely random and unique -- there's no reason to reuse a sample token you've seen in documentation or an example; generate a fresh one for any real use, since reusing a previously-displayed value defeats the entire purpose of a random secret.
Generating a strong token here is only the first step -- how you store, transmit, and rotate that key in your actual application (environment variables, a secrets manager, never committed to source control) matters just as much as the token's randomness for real security.
Switching the charset option (from hex to something like base64 or alphanumeric) changes the token's character set and resulting string length for the same byte count, but doesn't change the underlying amount of entropy -- 32 bytes of randomness is 32 bytes of randomness regardless of how it's displayed as text.
Related security and encoding tools
If you need to validate that an existing API key matches a specific provider's known format (rather than generate a new one), the API Key Format Validator (Per-Provider Pattern) checks that.
For signing a payload with a secret like this one (proving it came from someone holding the key), the HMAC Signature Generator is the next step in a typical API-security workflow.
Frequently Asked Questions (FAQ)
Why does 32 bytes produce exactly 64 hex characters?
Each byte of raw randomness converts to exactly 2 hexadecimal characters (since one hex digit represents 4 bits, and a byte is 8 bits), so 32 bytes always produces 32 x 2 = 64 hex characters, regardless of what the actual random value is.
Why does this use the Web Crypto API instead of Math.random()?
CSPRNG in the browser. Treat the output as a secret and do not reuse samples. Math.random() is not designed to be cryptographically unpredictable and shouldn't be used to generate security-sensitive values like API keys. The Web Crypto API's CSPRNG is specifically built to produce output that's computationally infeasible to predict, which is what a real secret requires.
Is 256 bits (32 bytes) enough entropy for a real API key?
Yes -- 256 bits is a widely used, solid standard for cryptographic secrets, considered infeasible to brute-force with current or foreseeable computing power. It's a common recommendation across many security-sensitive applications.
Can I reuse a sample token shown in documentation or examples?
No. CSPRNG in the browser. Treat the output as a secret and do not reuse samples. A previously displayed value has already been potentially seen by others (in documentation, screenshots, or examples), which defeats the purpose of a secret. Always generate a fresh token for actual use.
Does changing the charset option affect the actual security of the key?
No, not the underlying entropy -- switching between hex, base64, or another charset changes how the same amount of random data is displayed as text (and its resulting string length), but the actual number of random bits generated stays tied to the byte count you specify.
