API Key Generator

Produce one or a batch of secret strings in a format that suits the thing you are protecting. Pick an alphabet, set a length, optionally add a prefix, and copy or download the result, all without the value ever leaving the browser.

Security Notice

This page runs entirely in your browser and every value it produces is generated locally — nothing is transmitted or stored on a server. That also means no one can recover a value for you: store generated secrets in a password manager, and treat masking as display-only rather than encryption. Review your own threat model before using any output in production.

Four Alphabets and a Length

A secret is only as strong as the pool it is drawn from and the number of draws taken, and this page lets you set both. You choose what characters are allowed, how many of them the result should contain, and how many separate secrets to make at once. Each value is assembled character by character from a random number, so the output has no pattern you could guess from a neighbouring key.

• The random format draws from upper-case letters, lower-case letters, digits and the eight symbols in the set. That is seventy possible characters for every position.
• The hexadecimal format draws only from the sixteen characters zero to nine and a to f, which is what many systems expect for an identifier or a checksum.
• The Base64 format draws from sixty-four characters: the letters, the digits, and the plus and slash symbols. It is compact but not all-url-safe because of those last two.
• The UUID-like format ignores the alphabet and the length entirely and stamps out a fixed pattern of thirty-six characters with hyphens in set places.
• A length slider covers sixteen to one hundred and twenty-eight characters and starts at thirty-two, and the number beside the slider updates as you drag it.
• The count box takes one to fifty keys and is held inside that range in code, so an out-of-range entry falls back to one.

Making a Set of Secrets

1. Choose a format. For a general secret, the random alphabet is the usual pick because of its larger pool.
2. Slide the length control or read the number beside it. Thirty-two characters is a reasonable default; go longer for anything that guards real data.
3. Type a prefix if the service you are feeding expects one, for example a short marker followed by an underscore, or leave the field empty.
4. Set how many keys you need. One is the default, and fifty is the ceiling for a single batch.
5. Press Generate. The page replaces the panel contents with the new set, one key per line.
6. Use Copy All to place the whole set on the clipboard, or Download to save it as a plain text file named for the purpose.

What the Output Looks Like

The four formats differ in alphabet size, and that difference is the main thing to weigh when choosing between them. Here is what each produces and how many possibilities a position carries.

• A random key at the default length of thirty-two draws from seventy characters, so there are seventy choices at every one of the thirty-two positions. That is an enormous space, and the longer you set the slider the wider it grows.
• A hexadecimal key draws from only sixteen choices per position. Sixteen characters are still a lot of combinations at length thirty-two, but for the same length a hex key is far weaker than a random one because the alphabet is smaller.
• A Base64 key draws from sixty-four choices per position, and it packs more variety into each character than hex while staying shorter than a symbol-heavy random string.
• A UUID-like key is not variable in length. It always takes the shape of eight characters, a hyphen, four, a hyphen, four, a hyphen, four, a hyphen, and twelve, making thirty-six characters in total, with the version position fixed at the digit four.
• The variant position in a UUID-like value is not freely random either. It is forced into one of four values, so that one character can only ever be an eight, a nine, an a or a b.
• Adding a prefix does not shorten the key. A three-character prefix and a thirty-two character body produce a thirty-five character string, because the two parts are simply joined end to end.

Which Format to Reach For

Alternative	Notes
Random with symbols	The strongest option here for the same length, because the alphabet is the widest at seventy characters. The trade-off is that symbols can be awkward in URLs, shells or hand-typed configuration, so it suits secrets that live in a file or a secret store rather than a query string.
Hexadecimal	A narrower alphabet and therefore fewer possibilities per character, but it is predictable, case-free in practice and safe anywhere a hex string is expected, such as an identifier, a salt or a checksum field.
Base64	A middle ground with sixty-four characters. It is denser than hex and more portable than a symbol-heavy random string, though the plus and slash it can emit are not friendly to every URL or file name.
UUID-like	Best when a system asks specifically for a UUID. It is fixed in shape, easy to recognise, and carries version and variant markers. It is not a substitute for a high-entropy secret, since much of its length is structure rather than randomness.

Where the Randomness Comes From

The page generates everything in the browser and sends nothing. The characters are drawn from the platform's cryptographic random source, which is the same facility a password manager would use, so there is no server that ever sees a key you make here. Two details are worth knowing before you rely on it for something important.

• The random, hex and Base64 formats fill a typed array from the cryptographic generator and then map each byte onto the alphabet. To keep that mapping even, the page uses rejection sampling: any byte value that would make some characters more likely than others is discarded and redrawn. For the seventy-character set that means 46 of the 256 byte values are skipped; for the sixteen-character hex and sixty-four-character Base64 sets nothing is skipped, because 16 and 64 divide 256 exactly. The result is that every character in every alphabet is equally likely.
• The UUID-like format draws from the same cryptographic generator. Sixteen random bytes are taken and then the version nibble and variant bits are forced into their fixed values, so the randomness inside the identifier is as strong as the other formats.
• A prefix is appended by plain text joining, so it is not counted toward the chosen length and it is not randomised. If a prefix is all that distinguishes your keys, it is not adding any strength.
• Nothing is saved between visits. A reload generates a fresh set and discards the one you were looking at, so download or copy any key you intend to keep before you navigate away.
• Copy All uses the clipboard interface and Download builds a temporary file in the page, so both actions stay on your machine. Neither contacts a network.

Key Generation Questions

Are these keys suitable for production secrets?

The material itself is sound. All four formats, including the UUID-like one, draw from the platform's cryptographic generator, and the character mapping uses rejection sampling so no character or byte value is favoured over another. The length is under your control for the three variable-length formats. The remaining caveat is not the generation but the storage: a key is only as safe as where you keep it, so generate it here and then place it in a proper secret manager rather than a document or a chat message.

Why does my UUID-style key ignore the length slider?

Because that format is not assembled character by character the way the others are. It is produced from a fixed template with the groups already in place, so the result is always thirty-six characters long and the slider has no effect on it. The fixed shape is the point of a UUID.

Does adding a prefix make the key longer?

Yes. The prefix is joined onto the front of the body as plain text, so a five-character prefix and a thirty-two character body give a thirty-seven character result. The length you chose applies to the body only.

Can I get the same key twice?

No, not by accident. Each position is drawn independently from the random source, and the pool is large, so repeating a value would require an extraordinary coincidence. If you see an identical key, that is a sign the page did not regenerate rather than a collision.

Last verified: October 7, 2026

Launch API Key Generator

All Tools · All Tools · About · How We Test · Contact · Privacy

Maintained by Huang Bin · Last updated October 3, 2026