Generate cryptographically random API keys and tokens in hex, Base64URL, Base62 or UUID v4, with an optional prefix.
Keys come from the browser's crypto.getRandomValues, the same source used for real credentials. Math.random is never involved.
Store the hash of a key on your server, not the key itself, and show the full value to the user only once.
Base64URL is compact and safe in a URL or a header. Hex is easy to read in logs. Base62 avoids punctuation entirely. UUID v4 is the right choice when the key is also a database identifier.
32 bytes, which is 256 bits, is the sensible default. A prefix like sk_live_ makes it obvious in a log what kind of key leaked and which environment it belongs to.
Show the full key to the user once, then store only its hash. If your database is ever read, hashed keys are useless to whoever read it.
They come from crypto.getRandomValues, the browser's cryptographically secure random source, which is the same one used to generate real session tokens. Math.random is predictable from a few outputs and is never used here.
256 bits, so 32 bytes, is the standard answer and leaves no realistic chance of a guess. Anything under 128 bits is worth revisiting. Length in characters depends on the encoding: 32 bytes is 64 hex characters but only 43 in Base64URL.
Two reasons. It tells you at a glance what a leaked string is, and it lets secret scanners recognise your keys in public repositories. GitHub scanning works precisely because ghp_ is a recognisable pattern.
Store a SHA-256 hash of it, not the key. When a request arrives, hash the presented key and look up the hash. Keep the prefix and the last four characters in plain text so users can tell their keys apart in a list.
The generation itself is sound and nothing leaves your tab. What you should think about is the screen you generated it on and where you paste it next. For automated systems, generate keys on the server that issues them.
It uses only letters and digits, so there is nothing to escape and nothing that can be mangled by a shell, a URL or a CSV file. It is a good default when a key gets copied through unpredictable places.
A version 4 UUID carries 122 random bits, which is enough entropy. The catch is that UUIDs are conventionally treated as identifiers rather than secrets, so people log them freely. If you use one as a key, make sure your team knows it is a secret.
Have a rotation path before you need one. Support two valid keys at once so a customer can switch without downtime, and revoke immediately on any suspicion of a leak. A fixed schedule matters less than being able to rotate quickly.
Online UUID v4 and v7 generator, free. Bulk generation with uppercase and no-dash formatting. Cryptographically secure and generated in your browser.
Open ToolOnline password generator, no sign-up. Create strong, random passwords with customizable length and character sets. Generated locally and never stored.
Open ToolSign a message with a secret key using SHA-1, SHA-256, SHA-384 or SHA-512. Hex and Base64 output.
Open Tool