Random Color Palette Generator

A single random colour answers the question "what colour should this button be?" A palette answers the harder question: "what set of colours can exist together on the same screen without fighting each other?" Those are genuinely different problems, and a tool built for one rarely helps with the other. This generator is built for the second problem. Each time you hit generate, it produces a group of colour swatches at once, each showing its HEX, RGB, and HSL values side by side so you can read and copy the one your workflow needs. If you want a single colour instead, random color picker is the right starting point.

The lock mechanic is what separates palette exploration from palette frustration. When you generate a group and two of the swatches look promising, you lock those two and hit generate again. Only the unlocked swatches change. The locked ones stay exactly where they are, holding their HEX values, acting as anchors for the next round of random candidates. You keep locking the good ones, discarding the bad ones, and generating again until every swatch is locked and the palette is done. It sounds simple because it is — and that simplicity is the point. Without locking, every generate discards everything and you start over blind. With locking, each round narrows the problem.

Why locking beats regenerating the whole palette at once

The pure-random approach — generate a full palette, discard it if any colour is wrong, generate again — has a hidden cost that compounds quickly. In a five-colour palette, the chance that all five independently random colours look right together is low. Most generations will have at least one swatch you dislike, which means most regenerations also throw away two or three colours you actually liked. You are not making progress; you are just restarting at the same baseline over and over.

Locking breaks that loop. The first generate gives you five random swatches. Even if four of them are wrong, one might be exactly the right shade of warm amber you wanted for an accent. Lock that one. Now generate again. You still have four random slots to fill, but the problem is smaller: find four colours that work with that amber anchor. Lock the next keeper. Repeat. After three or four rounds, you have a palette built by genuine selection rather than pure luck, and you got there faster than regenerating cold every time. The lock mechanic converts random exploration into directed search, which is a meaningful difference in practice.

For contrast, the random color generator is optimised for single-colour use: one result, one value, copy and move on. The palette generator is optimised for the moment when you need colours to coexist — branding, UI themes, chart series, data visualisations, illustration palettes, physical product lines.

HEX, RGB, and HSL — three representations of the same colour

Every swatch shows three values. HEX is a six-digit hexadecimal number like #3A7BD5. It is the format CSS, Tailwind config files, and most design tools understand natively — paste it directly and it works. RGB writes the same colour as three numbers between 0 and 255, one for red, one for green, one for blue: rgb(58, 123, 213). It is the format many chart libraries and canvas APIs expect. HSL writes the colour as a hue angle between 0 and 360, a saturation percentage, and a lightness percentage: hsl(214, 62%, 53%). It is the format that makes the most intuitive sense when you want to reason about a colour rather than just use it.

HSL is worth understanding because it is the one that lets you make deliberate decisions. If you have a palette anchor at hsl(214, 62%, 53%) and you want a lighter tint of the same hue for a background, you raise the lightness: hsl(214, 62%, 90%). If you want a muted version for secondary text, you lower the saturation: hsl(214, 30%, 53%). If you want a complementary contrast colour, you rotate the hue by 180 degrees: hsl(34, 62%, 53%). None of those adjustments require guessing in RGB or HEX — HSL exposes the three axes that matter (hue, saturation, lightness) as three independent controls.

RGB uniform sampling, on the other hand, produces colours with wildly varying perceptual brightness because the three channels are not perceptually equal — the human eye responds to green roughly twice as strongly as it responds to red, and to red more strongly than blue. A fully random RGB triple often lands on very dark or very washed-out colours because so many of the 16,777,216 possible values cluster in perceptually dim or near-white regions. HSL sampling at a constrained lightness range produces palettes that feel more balanced by default, which is why tools built for designers tend to generate in HSL space even when they display HEX output.

Practical palette-building: a method that actually works

Start with one primary colour. Generate until you find something in the right general territory — a blue you could imagine as a brand colour, a warm terracotta for a packaging project, a neutral grey for a UI system. Lock it. Everything else follows from this anchor.

For the second colour, decide whether you want harmony or contrast. A neighbouring hue (within about 30 to 40 degrees on the hue wheel) creates an analogous palette — warm and cohesive, good for brand identities and editorial layouts. A hue rotated 180 degrees creates a complementary pair — high contrast, good for calls to action and data visualisations where two series need to look unambiguously different. Keep generating the unlocked slots until one of them matches the relationship you need.

For backgrounds and neutrals, aim for high lightness (above 90%) and low saturation. Purely white or grey backgrounds work, but a very slightly tinted background — hsl(214, 8%, 97%) rather than hsl(0, 0%, 97%) — ties the whole palette together without being visible enough to distract. Generate until something in the unlocked slots drifts into that region and lock it.

Five colours is usually the right ceiling for a working palette. Below that you can name every colour by its role (primary, secondary, accent, background, text). Above five, colours start competing for roles and the palette becomes harder to apply consistently. If you find yourself wanting more, consider whether some of your colours are actually the same role at different lightness levels — in which case they are really one colour with variants, not two separate palette entries.

Accessibility: what random palettes cannot guarantee

A randomly generated palette does not promise that any particular pair of colours meets accessibility contrast requirements. WCAG 2.1 sets a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text or UI components. Random colour generation has no awareness of these thresholds — a beautiful-looking amber on a white background might pass easily, while a slightly different shade of the same hue fails by a small margin.

Before using any generated palette in a UI, check the contrast ratio of every text/background pair you plan to use. The hex color generator gives you a value to test in any contrast checker. Large decorative elements — hero backgrounds, illustration fills, chart series bars — do not carry the same text contrast requirements, so a random palette is more directly usable for those contexts. The safest approach is to use the palette generator for decoration and accent colours, then choose your text and background colours deliberately to meet contrast targets rather than randomly.

Colour blindness is a separate consideration. Red-green deficiency (deuteranopia or protanopia) affects a meaningful share of the population. A palette that relies entirely on the distinction between red and green to communicate meaning — different data series, status indicators, categorical labels — will not work for those users. If your palette includes both red and green as semantically distinct categories, verify that they are also distinct in lightness or saturation, not only in hue, so the difference survives colour-vision simulation.

Copying values and moving them into your workflow

Each swatch has copy buttons for all three formats. The HEX value pastes directly into any CSS file, Tailwind config, Figma colour style, Sketch swatch, or Adobe XD asset. The RGB value is what most canvas drawing APIs and many chart libraries expect. The HSL value is what you want when you are going to continue adjusting the colour by hand — in CSS custom properties or in a preprocessor variable — because the three numbers map directly to the three things you might want to change: which colour family (hue), how intense (saturation), how light or dark (lightness).

For Figma, the most efficient path is to copy the HEX value and paste it directly into a fill or stroke colour field. For Tailwind, copy the HEX and add it to your tailwind.config.js colour extension under a named key. For CSS variables, HSL is usually the better choice because it lets you write variants in pure CSS: if your primary colour is defined as HSL, a hover state or a tint can be written as the same hue and saturation with only the lightness changed, entirely within CSS without needing a preprocessor.

If you are working with a physical design tool rather than a digital one — screen printing, product colour matching, interior paint — the RGB and HEX values are not directly actionable. They describe colours in the sRGB colour space for emissive screens. Translating to a physical colour system (Pantone, CMYK, RAL) requires a separate conversion step, and the result will vary depending on the print medium and lighting conditions. The palette generator is a starting point for digital work; treat physical conversions as approximations that need verification against physical samples.

Using random palettes in game design and interactive media

Game developers lean on random palette generation at two distinct stages: prototyping and procedural generation. During prototyping, placeholder art needs distinct colours fast — not beautiful colours, just colours that don't collide. A five-swatch palette gives every entity type a visual identity in under thirty seconds, letting development move forward before an art director is involved. That speed matters more than aesthetics at the prototype stage because the entire point is to test mechanics, not visuals.

Procedural generation is a different use case. Roguelikes, open-world generators, and generative-art tools need to construct palettes at runtime for environments, characters, or factions that the player has never encountered before. The standard approach is to generate a base hue randomly, then derive the remaining swatches from it using fixed relationships: a complementary colour at 180 degrees on the hue wheel, two analogous neighbours at plus and minus 30 degrees, and a desaturated neutral. Starting from one random anchor and applying geometry to the hue wheel produces results that are coherent enough to feel intentional while still being unique each time. The palette generator on this page covers the manual version of that workflow — generate a base, lock it, then explore what complements it.

Three common mistakes in game palette work: using more than six colours for a faction or biome (players cannot map seven distinct colours to seven distinct meanings reliably); choosing colours that differ only in hue without lightness variation (they become indistinguishable in greyscale screenshots and on televisions with low contrast settings); and picking saturations above 90% for background fills (high-saturation backgrounds compete with foreground elements and cause visual fatigue after extended play). A typical game environment palette has one highly saturated accent (the colour players associate with the biome), two mid-saturation supporting colours, and two low-saturation fills for surfaces and sky. That ratio keeps the accent reading as the dominant identity without making the environment tiring to look at.

Contrast ratios, WCAG thresholds, and when random palettes need adjustment

The Web Content Accessibility Guidelines define two contrast thresholds for text: 4.5:1 for normal text (below 18pt or 14pt bold) and 3:1 for large text (18pt and above, or 14pt bold). A third threshold — 3:1 — applies to UI components like button borders, input outlines, and focus indicators. These ratios measure the relative luminance of two colours, not their perceptual difference in hue. Two colours that look very different — a deep purple and a dark navy — can fail the 4.5:1 threshold because their luminance values are close, even though the hue difference is obvious to most viewers.

Random generation has no awareness of these thresholds. A generated palette that looks balanced on screen can place medium-blue text on a medium-grey background and fail at a ratio of 2.8:1. The practical fix is a three-step check after generating a palette for UI use: first, identify every text-on-background pair you plan to use; second, compute the WCAG contrast ratio for each pair (any browser devtools colour picker will show this, or paste both HEX values into a dedicated contrast checker); third, adjust lightness on the failing colour — HSL makes this mechanical, because changing only the L value in an HSL triple moves lightness without shifting hue or saturation. A 10-point lightness increase is usually enough to push a borderline pair from 3.9:1 to 5.1:1.

Decorative colour use carries different requirements. A background gradient, an illustration fill, a chart series that encodes magnitude rather than a label — none of these are text, and none require the 4.5:1 text-contrast threshold. The 3:1 non-text threshold still applies when colour alone communicates a meaningful boundary (the edge of a button, the outline of a form field). But a hero image background, a data-visualisation fill, or a palette swatch preview on a marketing page are purely decorative; WCAG exempts them entirely. This means randomly generated palettes are more directly usable for illustration and data visualisation than for body text — adjust for text use, use freely for decoration.

One commonly ignored failure mode is sufficient contrast on white but insufficient contrast on dark-mode backgrounds. A colour that passes 4.5:1 against white (#FFFFFF, luminance 1.0) can fail against near-black (#1A1A1A, luminance 0.012) if its own luminance is high. The formula is not symmetric. When building a palette for an interface that supports both light and dark themes, check every text-on-background pair in both colour-scheme contexts, not just one. Locking a colour in the palette generator and then testing it against both your light and dark surface colours before committing to it saves rework later.

This tool compared to the other colour tools on this site

The color dice roller picks one of six fixed colours — red, blue, green, yellow, orange, purple — for games and decisions. It is the right tool when you need a single named colour from a small predetermined set. The palette generator picks from the full 16,777,216 RGB values and gives you several at once, so it serves a completely different need.

The pick a random colour tool draws from hundreds of named web colours — names like coral, slate, teal, indigo — which is useful when you want a colour that has a real name and sits inside a recognisable taxonomy. The palette generator draws from the full numerical space without names, which gives it wider coverage but no named anchors. Use named colour generation when the name matters; use the palette generator when the exact value matters and you will be copying the number directly into code.

The color spinner wheel is built for a single random pick with visual drama — a spinning wheel that decelerates before landing on a result. That format works well for group decisions where the moment of reveal matters. The palette generator has no drama; it just gives you numbers efficiently. Different tools for different moments.