Consonant Generator

What this page draws

This page draws from one fixed pool: the 21 letters of the English alphabet that the engine’s alphabet table does not flag as vowels. The table marks exactly A, E, I, O, U as vowels, so the consonant filter keeps everything else — B C D F G H J K L M N P Q R S T V W X Y Z — in alphabet order, with Y among them. Each press of Generate asks the engine for the number of letters you typed, anywhere from 1 to 100, and every one of those letters is an independent draw in which each of the 21 entries has exactly the same probability: 1 in 21, or about 4.76% per draw. The result box lists the letters in the order they were drawn and reports the exact pool size they came from, so what you read is never a guess about what was drawn from.

The pool is fixed here because this page answers one question quickly. Everything a pool can become — filtered, trimmed by an exclude list, narrowed by an include list, doubled into mixed case — is the subject of the guide How letter pools are built, which walks through each stage with real engine calls, and of the main generator, where those options are exposed. The rest of this page explains what happens between the button and the letters: where the bytes come from, how a byte becomes a consonant without bias, why streaks are normal, what “no repeats” changes, and where the tool deliberately stops.

How a consonant is drawn

The engine never asks the browser for a letter. It asks for random bytes from the Web Crypto API (crypto.getRandomValues), the same operating-system-backed source browsers use for encryption keys and secure tokens, and it maps those bytes onto the pool itself. A byte holds 256 equally likely values and the pool holds 21, so the mapping has to be done with care, and the care is the whole point of the engine.

The sampler first works out the smallest number of bits that can cover the pool: 5 bits for 21 entries, since 5 bits span the values 0 to 31. It takes one byte, keeps only its lowest 5 bits, and reads the result as a position in the pool. If that position is 21 or more — any of the 11 values from 21 to 31 — the byte is thrown away and a fresh byte is drawn. Nothing wraps around and nothing is scaled, so every position from 0 to 20 is reached by exactly one accepted value, and each consonant keeps probability 1 in 21.

The examples on this page are not typed in. At build time the page runs the same engine the button calls, feeding it a scripted sequence of bytes instead of live randomness, and prints what comes back; live draws use crypto.getRandomValues. Byte 0 lands on position 0 and gives B, the first consonant in alphabet order; byte 20 gives Z, the last. A byte of 255 keeps the value 31 after masking, which is beyond the pool, so the sampler discards it and draws again; the script then supplies byte 200, which masks to 8 and lands on L. The build checks that the letter printed here is the one at position 8 of the pool, so this prose cannot drift from the code.

Rejection costs a little. Of the 32 masked values, 21 are accepted — an acceptance rate of 65.6% — so a letter costs on average 1.52 bytes rather than one, and the chance of several rejections in a row shrinks geometrically. That is the price of exactness. The uniformity claim rests on this construction, not on a statistical test run after the fact.

Why not just take the remainder

The tempting shortcut is to divide the byte by the pool size and keep the remainder. For this pool it is biased, and the bias can be worked out with nothing but division: 256 divided by 21 is 12 with 4 left over, so among the 256 byte values the remainders 0 to 3 each occur 13 times while the remainders 4 to 20 each occur 12 times. Under that shortcut the first 4 consonants — B, C, D, F — would turn up 8.3% more often than the other 17. No one would notice in a handful of rounds, which is exactly why the engine refuses the shortcut in code rather than trusting anyone to notice. Rejection sampling makes the remainder question disappear: a masked value is either a position in the pool or it is discarded.

Streaks are normal

Uniform does not mean evenly spread. Each draw is independent of the ones before it, so the pool has no memory and repeats are not corrected for. Five scripted draws with repeats allowed give X X F P X — one consonant three times in five — and nothing about that output is a fault. The arithmetic says so. The chance that six draws contain at least one repeated consonant is 1 minus the chance that all six differ, which is 21/21 × 20/21 × … down to 16/21; that comes to about 54%, so a repeat in six draws is more likely than not. Some consonant appearing three times running has odds of 1 in 441, because the second and third draws each have a 1 in 21 chance of matching the first, and a named consonant — S three times, say — 1 in 9,261. Draw 21 letters with repeats allowed and the chance that any particular consonant never appears at all is (20/21) to the power 21, about 36%.

Read the other way: a generator whose output never showed a repeat, or always covered the whole pool in 21 draws, would have to be steering the result away from what the bytes said. Tools that never show streaks are not more random — they are less. If a round genuinely cannot tolerate repeats, the right tool is the “no repeats” switch, which changes what is being drawn rather than tampering with the draw.

Drawing without repeats

With “no repeats” on, the engine samples without replacement using a partial Fisher–Yates shuffle driven by the same rejection sampler. It lays the pool out in alphabet order and, for each position in turn, draws a uniformly random choice from the letters not yet placed and swaps it in. Every drawn letter leaves the pool, so a batch of 21 is a uniformly random ordering of the entire consonant pool, every ordering equally likely. A scripted full draw gives Z C W H R F G L X Q T D J M K P Y N V B S: each of the 21 consonants exactly once.

The limit is the pool itself. Asking for 22 consonants without repeats is refused, and the refusal states the real limit rather than quietly repeating or truncating: “Cannot draw 22 letters without repeats from a pool of only 21 — allow repeats, lower the count, or widen the pool.” That message is produced by the engine at build time from a genuine rejected call, so it reads here exactly as the tool shows it. The checkbox label above says the same thing in short form.

Lowercase, and what mixed case really means

The Case control changes the forms, not the odds. Lowercase is the same 21-entry pool written in lowercase: the scripted bytes 0, 10 and 20 give b n z, the first, eleventh and last consonants, each still at 1 in 21.

Mixed case is different, and worth being precise about because it is a common misreading of how letter pools work. It is offered on the main generator and on the Uppercase & Lowercase Letters page, and it is not an uppercase draw followed by a coin flip. The engine builds a doubled pool — the 21 uppercase consonants followed by the 21 lowercase ones, 42 entries — and draws from that. The sampler then needs 6 bits, spanning 0 to 63, and rejects values from 42 upward. Scripted byte 21 lands on position 21, the first lowercase entry, b. Each of the 42 entries has probability 1 in 42, and with “no repeats” on, B and b count as different letters, so the no-repeat limit rises to 42.

Adjusting the pool

This page keeps the whole 21-letter pool. The main generator composes it in a fixed order: alphabet, then the consonant filter, then an include list (kept as an intersection), then an exclude list (subtracted), then case expansion — with the final pool size reported every time. Excluding Q X Z leaves 18 consonants at 1 in 18 each; excluding Y alone leaves 20. Lists are validated against the alphabet, so a character that is not one of its letters is an error, never silently dropped, and a combination that leaves nothing is refused with its own message — the consonant filter intersected with an include list of A E I O U produces: “The selected filters leave no letters to draw from — relax the filters.” The guide How letter pools are built shows every stage with real engine calls and the errors each one can raise; it is the right next page if you want a pool other than this one.

Where the tool stops

Three limits are deliberate. First, the engine is uniform-only. Its source exports one sentence about the distribution, rendered here verbatim:

Every letter in the active pool is exactly equally likely — the engine never weights draws by English text frequency or any other distribution.

There is no option to weight consonants, by English text frequency or anything else, and no page on this site will imply that a draw was anything but uniform over the reported pool. Second, the count runs from 1 to 100; a request for 101 is refused with: “How many: enter a whole number from 1 to 100.” Third, the site claims no certification and no audit. What stands behind the uniformity claim is the construction described above — cryptographic-quality bytes, the minimal bits covering the pool, rejection of anything beyond it — and the automated tests that drive the sampler with scripted bytes to pin the exact byte-to-letter mapping, including the rejection path. The methodology page sets out the whole construction; the guides take each piece in turn.

Read next: How letter pools are built — the filter, include, exclude and case stages shown with real engine calls — or browse all the guides.

Frequently asked questions

Uniform means uniform: every consonant has probability 1/21 per draw — the engine never weights letters by English frequency. Draws are local to your browser and never transmitted. See the methodology page.