Random color generator

What is a random color generator?

It picks colours for you. The obvious way is to choose three numbers between 0 and 255 and call the result a colour, which is what almost every generator does. That gives a uniform draw from the 16,777,216 colours of the sRGB cube, and if all you want is one arbitrary colour it is perfectly fine.

It stops being fine the moment you want a *set* of them — a chart legend, tag colours, a set of avatars — because two things go wrong that a single colour never shows you. The spread is not even to the eye, and the colours collide with each other.

This generator does the naive version too, and labels it honestly, but defaults to sampling evenly across perceived lightness and to rejecting any colour that lands too close to one already drawn.

How to use the random color generator

1. Choose how many you want. Anywhere from one to twenty-four. The batch redraws instantly, and the first one is the same every time you load the page so nothing shifts under you while reading.
2. Pick the sampling and the separation. Perceptually even spreads the batch across lightness; uniform sRGB is the naive draw, kept so you can see the difference. The separation setting rejects any colour closer than the chosen distance to one already picked.
3. Copy one, or all of them. Click a swatch to copy its hex code, or take the whole batch as a newline-separated list. Press “New colours” for another draw.

Uniform RGB is not evenly spread, and not in the direction you would guess

The usual complaint about random RGB is that it produces muddy, dark colours. Counted exhaustively over a 64×64×64 grid of the cube — 262,144 colours, sorted into tenths of perceived lightness — it is the opposite. The darkest tenth contains **20 colours**. Not 20%, twenty. The next tenth holds 950. Together the darkest fifth of the perceptual range accounts for 0.37% of the cube, and the most crowded band is 0.6–0.7, with 21.66%.

So a uniformly random RGB colour is almost never dark. The reason is that perceived lightness is not linear in the channel values: the cube only reaches low lightness in a very small corner near black, and everything else piles into the upper middle. Sampling 200,000 colours the naive way puts 0.00% in the darkest band; sampling evenly across lightness puts 10.06% there, and every one of the ten bands lands between 9.88% and 10.13%.

Getting that even spread is slightly more work than it sounds, and the obvious shortcut does not do it. Drawing uniformly from a box in a perceptual colour space and throwing away anything outside sRGB rejects 21.8% of the draws — but not evenly, because the gamut is narrow near black and near white. That pushes the survivors back toward the middle, which is the exact bias the perceptual sampling was for. It measured only 1.36 times flatter than the raw cube. The fix is to pick a lightness and a hue first, then work out how much colour that particular combination can actually hold, and draw the chroma from within it.

Random palettes collide

Ask for eight random colours and there is a 78.0% chance two of them are closer together than 0.1 in Oklab. With five colours it is 41.2%; with twelve, 97.5%.

For a sense of what that distance means: black to white is 1.000, red to green is 0.520, and two hex codes one step apart — #808080 and #818181 — are 0.0034 apart. A gap of 0.1 is small enough that a pair of chart lines drawn in those two colours are easy to mix up, which is exactly the situation a legend has to survive.

The separation setting fixes this by rejection: draw a candidate, and if it is closer than the threshold to anything already chosen, throw it away and draw again. The panel under the swatches reports the closest pair in the batch you actually got, so the guarantee is visible rather than asserted.

Honest limitations

A large separation and a large count are not always compatible. There is only so much room in the sRGB gamut, and asking for twenty colours all 0.15 apart eventually cannot be satisfied. When the rejection budget runs out, the tool completes the batch anyway and says so — returning fewer colours than requested, or looping forever, would both be worse than admitting the constraint was dropped.

The distance is a straight line in Oklab, which is a good perceptual measure but not a claim about your eyes. Oklab was designed so that equal distances look roughly equally different, and it is what CSS now uses, but a threshold of 0.1 is a setting on this page rather than a standard — that is why the article gives you the anchors above rather than asserting a just-noticeable difference this page has not measured.

The randomness is a small seeded generator, not a cryptographic one. That is deliberate: it makes a batch reproducible and lets the test suite assert distributions. If you need unpredictable values for anything that matters, the password generator on this site uses the browser's cryptographic source instead.

Nothing here accounts for colour vision deficiency. Two colours can be well separated in Oklab and still be confusable for a red-green deficient viewer, since the distance is computed for typical trichromatic vision. A palette that must work for everyone needs checking against that specifically.

Forty assertions cover the distribution counted exhaustively, the collision rates, the gamut boundary search, the separation guarantee and the seeded generator's uniformity.

Why is it free?

It is arithmetic and a random number, running in your browser. Nothing is uploaded, there is no account, and there is no limit on how many batches you draw.

If you want a specific colour rather than a random one, the colour picker and the hex converters on this site are equally free and equally local.