Random String Generator

Two numbers decide everything here: how many characters you allow, and how many positions you fill. The strength of the result is the second multiplied by the base-2 logarithm of the first, and nothing else about the string matters.

alphabet   size   bits per character
0-9          10   3.32
a-z          26   4.70
a-z0-9       36   5.17
Crockford    32   5.00
Base58       58   5.86
A-Za-z0-9    62   5.95
Base64 URL   64   6.00

A 32-character alphanumeric string is 32 × 5.95, which is 190 bits. A 16-character one is 95. Doubling the alphabet buys you one bit per character; doubling the length doubles the total. Length is the lever.

Why hex and Base64 are the tidy ones

Sixteen characters is exactly four bits and 64 is exactly six, so those two alphabets divide into raw bytes with nothing left over. Every other size lands on a fraction, so 22 characters of Base64 hold sixteen whole bytes and 22 characters of Base58 hold roughly 128.9 bits of something that has to be converted, not sliced.

In practice this only matters when the string has to be turned back into bytes. If it is only ever compared as text, pick the alphabet that reads well.

The modulo bias, and it is the one real trap here

randomByte() % 62

That line appears in a great many code samples and it is skewed. A byte holds 256 values, and 256 is 4 × 62 with 8 left over, so eight of the characters can be produced by five different bytes while the other 54 can only be produced by four. Those eight come up 25% more often than the rest, every time, in a value whose whole purpose is to be unpredictable.

The fix is to discard any byte at or above 248, which leaves a range that divides evenly. That costs about 3% of the bytes drawn and nothing else. This tool does that, and switches to 16-bit draws if you give it an alphabet longer than 256 characters.

Requiring one of each set costs you something

The usual way to guarantee a digit is to generate the string and then overwrite a position with one. That makes that position a digit far more often than chance, and an attacker who knows the rule knows where to look. This tool redraws the whole candidate instead and keeps redrawing until it qualifies, which leaves every acceptable string exactly as likely as every other.

It still shrinks the space, because the strings that fail the rule are no longer possible. At 16 characters the loss is a fraction of a bit. At 4 characters with four required sets it is severe, and the entropy figure above does not account for it. Composition rules are worth less than length in almost every case.

What a prefix does and does not do

sk_live_ in front of a key is a good idea and adds no strength whatsoever. It is there so that a leaked key can be recognised on sight, by a person reading a log or by a secret scanner watching public repositories, and so that a test key cannot be mistaken for a live one. The entropy figure above deliberately ignores it, because an attacker knows it too.

This is not the tool for a memorable password

A string from here is meant to be pasted, stored in a password manager, or written into a config file. If a person has to type it from memory, a handful of random words beats a shorter random string on both counts: more entropy and far easier to carry. Six words from a 7,776-word list is 77 bits, which is more than a 12-character alphanumeric password and immeasurably easier to say aloud.

Where the randomness comes from

crypto.getRandomValues, the browser's cryptographic generator, the same one behind session tokens and key material. Not Math.random, which is seeded per page, recoverable from a short run of its own output, and fine for scattering particles but not for anything anybody might want to guess.

Nothing generated here is sent anywhere or written down. Reloading the page loses every value on screen. Correct behaviour for a secret, and an annoying one if you have not copied it yet.