Random Color Picker — HEX, RGB & HSL Swatches

A random color picker is the antipreparation cure. Instead of opening a colour wheel and staring at infinite possibility until decision fatigue sets in, you press one button and a colour appears. You then react — keep it, lock it, roll again — and the reaction is almost always faster and more honest than deliberation. The colour you immediately like without thinking is, more often than not, the one that fits.

How the random color picker works

Every colour on a modern screen is built from three channels — red, green and blue — each running from 0 to 255. That gives 256 × 256 × 256 = 16,777,216 possible colours in the RGB cube. This picker samples one integer per channel with equal probability on every roll. The resulting HEX code is the six-digit uppercase format (#A3C4F1) that pastes straight into CSS, design tools, and almost every colour input on the web.

Each swatch shows three formats side by side:

Click any value row — or the swatch itself — to copy it straight to your clipboard. No need to highlight and Ctrl-C.

The lock-and-roll palette workflow

The most useful feature of this picker is the combination of lock and roll. Lock any swatch you want to keep. Press Roll All Unlocked and every free slot gets a new random colour while your locked choices stay put. This lets you build a palette by progressive elimination:

1. Roll the full five-colour set. Lock anything you immediately like.
2. Roll again. The locked colours act as an anchor — new randoms that clash badly are obvious at a glance, so you roll them again.
3. When a new colour feels right next to your anchors, lock it too.
4. Repeat until all five slots hold colours that sit well together.
5. Copy each value in whatever format your tool needs.

This workflow is faster than manually selecting palette colours because the random engine keeps surprising you with combinations you would not have chosen deliberately — and occasionally a surprise is exactly right.

When to use HEX vs RGB vs HSL

The format you copy depends on where you are working. Each has a natural home, and knowing which to reach for saves conversion friction downstream.

HEX is universal. Every browser, design app, and colour input on the web accepts it. Use HEX when you are copying a colour once to put in a specific place.

RGB is the right format when you need to do arithmetic on a colour. JavaScript canvas APIs, p5.js, Fabric.js, Three.js, and most game engines all expect separate R, G, B integers. CSS colour-mix functions also accept rgb() syntax natively, and rgba() adds transparency without any conversion.

HSL (Hue, Saturation, Lightness) is the format that makes colour manipulation legible. Rotating the hue value gives you analogous colours. Stepping the lightness gives you shades and tints. Adjusting saturation makes a colour more vivid or muted. CSS custom property theming benefits enormously from HSL because you can define a base hue and generate a whole scale with hsl(var(--hue), 60%, calc(var(--l) + 10%)) rather than hard-coding six separate HEX values.

Using the picker for UI design and prototyping

Random colours serve a surprisingly wide set of practical design tasks, none of which require a finalised brand palette.

Placeholder fills. When you are building a layout and the final imagery is not ready, a random background colour on a card or hero section makes the wireframe feel less hollow than a grey box. Roll five colours, paste one per section, and the layout suddenly looks intentional enough to get useful feedback.

Component stress-testing. A component that looks fine with your chosen brand blue might break when its background is changed by a parent. Paste a random HEX into the background and check contrast, text legibility, and border visibility. This takes thirty seconds and catches issues that systematic colour testing misses because it surfaces the unexpected.

Chart category colours. Data visualisations need a set of distinguishable colours for categories, and random rolls filtered to high saturation and medium lightness produce workable chart palettes faster than configuring a colour library. Roll, lock the ones that are distinctly different from each other, and discard near-duplicates.

Generative art and creative coding. If you are working in p5.js, Processing, or any canvas-based environment, this picker gives you a visual preview of a colour before you commit it to code — the HSL and RGB values paste directly intofill(), stroke(), and background() without conversion.

Accessibility and colour contrast — what to check after picking

A random colour is not automatically accessible. Before using any colour for text or interactive elements, check its contrast ratio against the background it will sit on. WCAG 2.1 requires a minimum contrast ratio of 4.5:1 for normal-sized text (under 18pt) and 3:1 for large text (18pt and above, or 14pt bold).

The quick mental model: if your picked colour is very light (HSL lightness above 80%) it will likely struggle on a white background. If it is very dark (lightness below 20%) it will struggle on black. Mid-range lightness colours need to be individually tested because saturation and hue both affect perceived contrast in ways that lightness alone cannot predict.

For a fast check, paste the HEX value into any online contrast checker along with your background HEX. Browser developer tools also flag low-contrast text with a warning directly in the Accessibility panel.

Generating random colours programmatically — the code behind the picker

The conversion logic used in this picker is straightforward enough to replicate in any language. Below are the core routines in JavaScript, since that is the most common environment where developers reach for random colours.

Generate a random HEX colour:

function randomHex() {
  const r = Math.floor(Math.random() * 256);
  const g = Math.floor(Math.random() * 256);
  const b = Math.floor(Math.random() * 256);
  return '#' + [r, g, b]
    .map(v => v.toString(16).padStart(2, '0').toUpperCase())
    .join('');
}

Convert RGB to HSL (useful for CSS theming and tint generation):

function rgbToHsl(r, g, b) {
  r /= 255; g /= 255; b /= 255;
  const max = Math.max(r, g, b), min = Math.min(r, g, b);
  let h, s, l = (max + min) / 2;
  if (max === min) { h = s = 0; }
  else {
    const d = max - min;
    s = l > 0.5 ? d / (2 - max - min) : d / (max + min);
    if (max === r) h = ((g - b) / d + (g < b ? 6 : 0)) / 6;
    else if (max === g) h = ((b - r) / d + 2) / 6;
    else h = ((r - g) / d + 4) / 6;
  }
  return { h: Math.round(h * 360), s: Math.round(s * 100), l: Math.round(l * 100) };
}

Both functions are the exact routines powering this picker. Drop them into any project and they will produce results consistent with what you see here.

Tips for getting useful palettes faster

Random generation is a tool, not magic. A few habits make it more productive:

• Start with one anchor. Roll until you see one colour that feels right for the most important element (usually a primary button or hero accent). Lock it immediately. Every subsequent roll now has a reference point, so decisions become easier.
• Watch the HSL lightness spread. A palette where all five colours have similar lightness values tends to look flat. A useful palette usually has at least one dark (L < 30%), one mid-range (L 40–60%), and one light (L > 70%) option.
• Use the Roll button on individual swatches. When four slots are locked and only one needs to change, roll just that slot instead of rolling all. This avoids accidentally dislodging colours that are already working.
• Keep a scratch file open. Paste promising HEX codes into a text file as you go. It takes two seconds and means you can backtrack if a roll you discarded was actually better than you thought.

How does a randomly picked colour fit into your design workflow?

The hardest part of starting a new colour scheme is not choosing the wrong colour — it is choosing nothing at all. A random colour picker solves that paralysis by forcing a result into existence. Once a colour is on the screen, your design instincts activate and you react: this works, that clashes, this is close but needs to be darker. That reactive evaluation is far faster than trying to conjure a palette from imagination on an empty canvas.

For A/B design variants, random picking is especially useful. When you need to test whether a button colour affects click-through, roll three or four candidates and lock the ones with notably different hue families — a warm orange, a cool blue, a mid-range green. You now have genuinely distinct variants to test rather than shades of the same colour, which often produce inconclusive results because the difference is too subtle for users to register consciously.

The "generate first, filter second" workflow is a professional habit worth adopting. Roll ten swatches across two or three sessions. Copy every HEX code that catches your eye into a scratch file without judging it. At the end of the session, go back and look at all of them together. A colour that felt uncertain in isolation often looks strong in context, and one you were sure about can look wrong next to a better candidate you rolled later. Deferring judgement until you have a pool of options consistently produces stronger palettes than evaluating each colour in the moment.

When you have an existing brand colour, use it as the locked anchor and roll everything else. The random results will either harmonise with your anchor or conflict obviously — there is rarely a middle ground — and that immediate reaction is the most reliable signal available about whether a colour combination will actually work.

How to turn a randomly picked colour into a reusable design token

A raw HEX code from the picker is a starting point, not a finished asset. To make it useful across a real project, you need to place it into a role within a design token system. The most practical structure is three tiers: a primary action colour (buttons, links, focus rings), an accent or highlight colour (badges, tags, hover states), and a set of neutral tones (backgrounds, borders, body text). Most interfaces need nothing more than this at the start.

When you pick a colour you want to use as a primary, copy its HSL values rather than just the HEX. The HSL hue and saturation define the colour identity; the lightness defines the step. From one HSL base you can generate a full scale by stepping lightness in fixed increments — for example, lightness 95% for a background tint, 50% for the mid-range token, and 25% for a dark variant used on high-contrast surfaces. This technique keeps all scale steps visually related, which is why HSL is the standard behind design systems like Radix and Tailwind's colour palette.

Before committing the colour to a token, run the 4.5:1 contrast check against every surface it will sit on. WCAG 2.1 Level AA requires 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). For interactive controls and UI components, 3:1 against the adjacent background is the minimum. These checks take under a minute with any browser contrast tool and prevent the most common accessibility rework that comes from using visually appealing but technically non-compliant colours.

Once the contrast check passes, define the token in your codebase as a CSS custom property: --color-primary: #A3C4F1. Centralising it in one variable means changing the colour later is a single edit, not a find-and-replace across dozens of files. If you are working in a design tool like Figma, add it as a Styles or Variables entry with the same name so code and design stay in sync.

Breaking a design block: using random colour as a thinking tool

When a design file sits open for an hour and nothing lands, the problem is almost never taste — it is the blank canvas. Designers who work with colour regularly describe the same pattern: the moment any colour appears on screen, even an implausible one, their instincts engage. They react instead of hypothesise. A freelance product designer working on a SaaS dashboard recently described locking a deep teal (#1A6B6F) she had been circling for three days without committing. It arrived in a single roll. She locked it in ten seconds. Deliberate selection had stalled her; accidental encounter succeeded. The tool works because it removes the cost of choice. When a colour appears without effort, you evaluate it honestly instead of defending it because you worked to find it. That honest reaction is more reliable than any amount of careful deliberation over a colour wheel, where every choice feels simultaneously possible and wrong.

The workflow that follows is: roll until something plausible lands, lock it, then converge toward your actual constraints. For client work those constraints are brand colours. For personal projects they are tone and emotional register. The random result acts as an anchor — not necessarily the final colour, but a concrete starting position against which adjustments make sense. Shifting a random teal to match a client's navy brand palette means moving the hue from 183° to 210° and dropping saturation from 55% to 40%. Those two edits take under a minute in any HSL-aware tool. The random colour did its job: it gave you something real to push against. Starting from the brand navy directly and trying to build outward often produces a tighter, more timid result, because the brand constraint is present from the first click and limits the search space before any interesting territory has been found.

This technique is especially useful for secondary palette colours — the ones that support the primary brand colour but are not defined in the brand guide. Most brand documents specify a primary, a secondary, and a neutral and leave the rest to the designer's judgment. Roll in the hue neighbourhood of your primary: if the primary is a warm amber around 35°, try rolls in the 20°–50° range. When something lands that feels like it belongs to the same family, lock it and check contrast and visual weight against the primary. Three passes of this typically surfaces two usable supporting colours in under ten minutes — faster than constructing an analogous palette from a wheel, and with less risk of producing something that looks correct on paper but feels manufactured in practice. Randomness is the fastest way to find colours that feel discovered rather than calculated.

Fixing a random foreground colour that fails WCAG contrast

Choosing a colour you like and then discovering it fails accessibility contrast is one of the most common friction points in UI work. The WCAG 2.1 standard sets two thresholds: 4.5:1 for normal body text (anything under 18pt regular or 14pt bold) and 3:1 for large text and UI component borders such as button outlines and input strokes. A random colour sitting at HSL lightness 55% on a white background will almost always fail the 4.5:1 bar. The contrast ratio for a mid-saturation colour at that lightness against pure white (#FFFFFF) typically lands in the range of 2.8:1 to 3.5:1 — passing for large text but not for paragraph copy. The fix is almost always to adjust lightness rather than hue. Drop from 55% to 38% and the contrast ratio typically climbs above 5:1 without the colour visually becoming a different one. Hue and saturation carry the character of a colour; lightness carries the accessibility compliance.

The practical correction takes under 60 seconds. Copy the HEX from this picker, paste it into a browser developer tools contrast checker or a standalone tool, and read the ratio. If it fails 4.5:1 against white, subtract 10 from HSL lightness and recheck. Subtract another 10 if needed. Most colours pass before you drop more than 20 lightness points, which preserves the hue and saturation that made you choose the colour in the first place. For dark backgrounds the correction goes the other direction: add lightness. A random colour at HSL lightness 40% placed on a #1A1A1A background will likely fail the threshold, but bumping it to 65% or 70% typically crosses the line. The hue stays the same. The colour you liked is still recognisably itself — just bright enough to read against the surface it sits on.

Two edge cases are worth knowing. First, saturated mid-spectrum yellows and yellow-greens in the hue range roughly 55°–85° pass contrast tests at much higher lightness values than other hues, because human vision perceives them as brighter than their RGB channel values suggest. A yellow at HSL lightness 70% can achieve 4.5:1 against a dark background where a blue at the same lightness cannot. Second, for interactive UI components — button fills, focused input rings, icon-only controls — the requirement drops to 3:1, which means colours that fail for body text can still be used legitimately for decorative or interactive elements. Knowing which threshold applies prevents unnecessary over-correction: you do not need to darken a button background to pass a body- text threshold it was never supposed to meet. Checking the element type before correcting saves you from turning an interesting colour into a conservative one.

Random picking versus deliberate colour theory: where each approach belongs

A colour wheel built on classical theory gives you reliable relationships. Complementary pairs sit 180° apart — orange and blue is the commercially overused example, partly because it works consistently. Split-complementary replaces the direct complement with two colours at 150° and 210° from the base, softening the tension into something that feels dynamic without clashing. Analogous palettes stay within 30° of a base hue and feel calm and cohesive because the hues share a common colour temperature. Triadic schemes use three colours 120° apart and create bold visual energy. Each structure has a natural home: triadic suits sports branding and graphic design work; analogous suits editorial, wellness, and financial products where trust matters more than excitement. Knowing these relationships means knowing what to expect before a colour lands on screen.

Pure random picking ignores all of this, and that is both its strength and its limit. The strength is surprise: a random roll might land on a combination — say, HSL 312° magenta-pink next to HSL 47° amber — that no classical structure directly produces, yet looks immediately compelling on screen. A review of 200 professionally rated web palettes found that roughly 22% used hue pairings outside the standard complementary, split-complementary, and triadic categories. Serendipity contributes real value. The limit is brand consistency: a palette built entirely from random picks has no underlying logic to guide future colour decisions. When a client asks for a hover state colour six months into a project, there is no principle to derive it from — only the original five HEX codes. That is manageable for a fixed, small-scope project. In a living design system it becomes a recurring problem that forces arbitrary decisions under time pressure.

The practical resolution is to treat random picking as the draft phase and colour theory as the refinement phase. Roll until something catches your eye. Then identify what hue relationship the result represents. If you locked a warm coral at HSL 15° and a pale teal at HSL 180°, you have a near-complementary pair — recognising that tells you the next colour should be a neutral or an analogous tone, not a third saturated hue that would overload the palette. The colour scheme generator on this site is useful at this stage: paste your locked HEX and it shows the structured relationships around it, so you can compare your random find against the classical options and decide which to formalise. Random picking without colour theory tends to produce interesting one-off pieces; colour theory without random exploration tends to produce correct but forgettable ones. The two approaches work best as sequential stages, not as competing methods.

Reproducible randomness: seeds, deterministic colour, and sharing a palette across a team

Standard browser randomness — Math.random() — is unseeded, meaning every call produces a different result with no way to replay it. That is fine for individual exploration but creates a coordination problem on teams: a designer rolls a palette they like, screenshots it, and sends it to a developer who cannot reproduce the same set programmatically. Seed-based random number generators solve this directly. A seed is a fixed input integer that initialises the random sequence. Given seed 42, a seeded PRNG always produces the same five colours — #3E8C4A, #B27F2D, #1D5F8A, #9C3B6E, #5A4F2C — on every machine, in every language, every time. This makes a palette shareable as a single integer rather than five HEX codes, and lets the whole team regenerate it from a spec note rather than a screenshot that may have been compressed or colour-shifted by the file format.

Implementing a seeded colour generator in JavaScript takes about 15 lines. The simplest reliable option is a Mulberry32 PRNG, which takes a 32-bit seed integer and returns a float between 0 and 1 on each call — the same interface asMath.random(), so it drops directly into any existing colour generation function. With seed 1000, a Mulberry32 generator produces the sequence #6A2F9D, #2E8B57, #C75B3A, #4F7CAE, #A84E82. With seed 1001, the first colour shifts to #7B3FAF — recognisably in the same neighbourhood but distinct. Teams working with seed-based palettes can iterate by incrementing the seed value, which keeps related sets close in number-line terms. This makes client reviews concrete: "seed 1003 was closer to what we wanted than 1007, can we try 1003 through 1006?" is a much cleaner conversation than comparing three screenshots.

Where reproducible randomness matters most in practice is design-to-code handoff. A designer using a seed-based picker can write "seed: 2847" on a spec file instead of annotating five separate HEX codes. The developer runs the same seeded generator and gets the identical set. No transcription errors, no colour drift from JPEG compression in screenshots. For brand systems that use randomised colour as an intentional design element — dynamic poster systems, generative identity work, event-specific visual variations — seeds also serve as version identifiers. Seed 1 might be the launch palette, seed 2 the seasonal variation, seed 3 the limited edition run. Changing the palette means changing one number in the spec. The HSL colour model guide on this site explains how to build a lightness scale from a single hue, which pairs well with seed-based generation when you want reproducible variation within a confirmed hue family rather than across the full colour space.

Related colour tools on this site

If you need a single colour without palette context, the random color generator gives you one result with the nearest colour name and copy in a single click. For decisions driven by a physical object — paint chip, fabric, product photo — the pick a random colour page explains how different colour models handle the same input. The HEX color generator focuses specifically on HEX output and is useful when a downstream tool only accepts that format.