Sort colors by luminance

This tool validates every value, normalizes short and full hex notation, converts sRGB channels to linear light, and sorts by WCAG relative luminance. Each result includes the normalized color and its luminance, so you can inspect close calls instead of trusting a visual guess. Equal-luminance colors keep their original order, duplicates remain present, and identical inputs always produce identical output. It is useful for design tokens, charts, themes, palette documentation, and any workflow that needs a reproducible brightness sequence rather than a subjective arrangement.

Build a brightness scale from an unordered palette

Color collections often arrive in an order that reflects when tokens were created, how a designer selected swatches, or how a source file serialized an object. None of those orders reliably communicates brightness. Provide the colors array as hex values and this capability returns sorted records from the lowest relative luminance to the highest. Three-digit forms such as #abc are expanded, six-digit forms are accepted with or without the leading hash, and every returned value uses lowercase #rrggbb notation. That normalization makes the result convenient for snapshots, token files, CSS generation, and comparisons between separate runs. Duplicates are not removed because repeated values can have meaning in an existing scale or parallel data structure. Colors with exactly equal computed luminance keep their input order, so ties never jump around between engines or executions. The response also reports the number of colors, the direction of the ordering, and the named method. Use the sorted array directly when constructing a sequential palette, or retain the luminance numbers as review evidence when neighboring swatches look unexpectedly close. The operation changes ordering only; it does not invent intermediate shades, rename tokens, or claim that the resulting steps are perceptually uniform.

Understand how relative luminance determines the order

Relative luminance is not a simple average of the red, green, and blue byte values. Hex colors encode sRGB channels with a nonlinear transfer curve, so each channel is first scaled to zero through one and converted to linear light. Values at or below the sRGB breakpoint are divided by 12.92; higher values use the standard power function. The linear red, green, and blue components are then combined with coefficients 0.2126, 0.7152, and 0.0722. Green contributes most, blue contributes least, and the final value runs from zero for black to one for white. Sorting uses the full unrounded result. The six-decimal luminance in each returned record is for readable output and stable serialization, not the comparison key, so two values that display the same rounded number can still appear in their mathematically correct order. This is the relative-luminance model commonly used in WCAG contrast calculations, but sorting a palette does not by itself establish accessibility. Contrast depends on a pair of colors, context, and applicable thresholds. Use this result to organize colors, then perform a dedicated contrast check for foreground and background combinations that must satisfy accessibility requirements.

Validate inputs and integrate deterministic results

The colors field must be a non-empty array with no more than one thousand entries. Every entry must be a string containing exactly three or six hexadecimal digits after an optional leading hash. Whitespace around the complete value is ignored, while alpha forms, CSS color names, rgb() functions, malformed lengths, and non-string entries are rejected. The error identifies the failing array index, which makes a bad token easy to locate in a generated palette. Validation is fail-fast: the capability never silently drops an invalid value or guesses how it should be interpreted. That behavior matters in automated design-system builds because a partial scale can look plausible while hiding a missing brand color. The implementation performs only local arithmetic and an in-memory sort. It does not call a network service, read the clock, use random values, or retain input, so the same array produces the same JSON in browser tools, CI jobs, and API calls. The browser runner is free, while an API request costs $0.002. When integrating, store the normalized returned colors if canonical formatting is desirable, or map the ordered records back to your own token metadata by occurrence. Because duplicates are preserved and ties are stable, positional mapping remains deterministic even when multiple source tokens share the same hex value or luminance.