Color Theory for Procedural Palettes

Most procedurally generated color palettes look bad. Pick five random colors from the HSL wheel and you usually get a muddy, low-contrast mess that looks like a paint store exploded. The reason is not that the colors are individually wrong — it is that good palettes are not about individual colors. They are about relationships between colors. A palette that works has a structure: a dominant color, a supporting color, one or two accents, and a neutral. Random sampling does not produce structure.

This is why palette generators that work tend to be built on a small number of template configurations. Instead of sampling colors independently, they sample a small set of parameters and then derive the palette from those parameters using rules. The rules are the color theory, compressed.

HSL is the wrong starting point

The default color space for most generators is HSL (hue, saturation, lightness), and HSL is the wrong starting point. The problem is that HSL's "lightness" is not perceptual lightness. A pure yellow at HSL lightness 50% looks much brighter to the eye than a pure blue at the same lightness. A palette balanced in HSL will look unbalanced when you actually look at it.

The better starting points are perceptual color spaces: OKLCH, CIELAB (Lab*), or HSLuv. In these spaces, equal numerical differences correspond more closely to equal perceived differences. A palette that is balanced in OKLCH will look balanced. Most modern design tools (Figma, Tailwind 4, the Web Content Accessibility Guidelines) have moved to perceptual spaces for this reason. If you are building a palette generator, pick OKLCH or HSLuv as your working space and convert to sRGB or P3 at the end.

The handful of configurations that work

There are a small number of palette structures that consistently produce usable results. Almost every good procedural palette is a variation of one of these:

• Monochromatic. One hue, varied in lightness and saturation. Safe, easy to generate, always looks like a coherent palette. The downside is that it has no contrast and no accent.
• Analogous. Two or three adjacent hues on the wheel (e.g., blue, blue-violet, violet). Slightly more visual interest than monochromatic, still very low risk.
• Complementary. One hue plus its opposite on the wheel (e.g., blue and orange). High contrast, high visual energy, easy to get wrong by using both at full saturation. The standard fix is to use one as the dominant (desaturated) and the other as the accent (full saturation).
• Split-complementary. One hue plus the two neighbors of its opposite (e.g., blue, yellow-orange, red-orange). Less aggressive than complementary, more visual interest than analogous.
• Triadic. Three hues evenly spaced around the wheel (red, yellow, blue; or orange, green, violet). High contrast, hard to balance, tends to look "primary color" unless the saturation is dialed back.
• Tetradic (double complementary). Two complementary pairs. The most complex structure; works only if you pick one pair as dominant and the other as accent, otherwise it looks like four random colors.

These six structures cover almost every palette that works. A procedural generator that picks one of these structures, then samples the hue offsets and saturation/lightness ratios within that structure, will produce usable palettes far more often than one that samples five colors independently.

The role of neutrals

A common mistake in procedural palettes is generating five "colors" and stopping. Real palettes almost always include neutrals — off-whites, grays, near-blacks — that carry 70% of the actual surface area in a design. The colors do the work of drawing the eye; the neutrals do the work of letting the eye rest.

A useful pattern is to generate three chromatic colors (one dominant, one supporting, one accent) plus two neutrals (a light and a dark). The neutrals can be slightly tinted with the dominant hue (a blue palette gets a cool gray; an orange palette gets a warm off-white) to keep the palette cohesive. This is how most design-system palettes are structured: a small set of brand colors plus a ramp of neutrals.

Procedural generation that works

The practical recipe for a palette generator that produces usable output:

1. Pick a structure from the six above (weighted toward monochromatic and analogous, which are harder to mess up).
2. Sample a base hue uniformly from 0–360.
3. Derive the other hues from the structure (e.g., for analogous, base ± 30°).
4. Sample saturation and lightness from a constrained range, not 0–100%. Most usable colors live in saturation 30–80% and lightness 30–70%.
5. Add one or two neutrals, slightly tinted toward the base hue.
6. Lock the structure and let the user shuffle within it — re-roll the base hue, the saturation, and the lightness, but keep the hue offsets and the neutral count constant.

This is roughly what the Palette Studio tool in Fluxcade does. The flat swatch builder lets you pick colors manually, save them to a library, and pair two saved palettes by index to generate a gradient palette where the first palette anchors the gradient stops and the second modulates them.

A color is not a color until it is next to another color.

— Josef Albers, Interaction of Color

Color theory is not a set of rules. It is a set of observations about how humans perceive relationships between colors. The rules that come out of it — the six structures, the role of neutrals, the dominance of one hue — are heuristics that work most of the time, not laws. The generator's job is to encode the heuristics and then let the user break them on purpose.