How to Validate Hex Color Codes in a Palette or Token File

A design palette grows by copy-paste. Someone pulls a swatch from Figma, someone else lifts a value out of a CSS file, a third person types one from memory off a printed brand sheet. By the time the colors land in a shared token file or a spreadsheet, a few of them are quietly broken: a five-digit code that should have been six, a stray letter that is not a hex digit, a value that lost its leading hash on the way through a CSV export. None of those throw an error until a build step or a downstream tool chokes on them.

The fix is to validate the whole list at once, before it gets imported anywhere. That is exactly what the Hex Color List Validator does: you paste a column of values or drop a local text file, and it checks every entry against real hex syntax, then hands back a pass/fail report with a reason on each row.

What makes a hex color valid

A hex color is a # followed by hexadecimal digits, and only specific lengths count. After the hash you may use 0–9 and a–f (uppercase A–F is fine too) and nothing else. The accepted lengths are:

• 3 digits — shorthand RGB, like #f00 (red).
• 6 digits — full RGB, like #ff0000.
• 4 digits — shorthand RGBA with an alpha nibble, like #f00c.
• 8 digits — full RGBA with two alpha digits, like #ff0000cc.

That is the complete set. So three things break the rule, each for a different reason:

• #ggg is invalid because g is not a hexadecimal digit — the alphabet stops at f.
• #ff is invalid because two digits is not one of the allowed lengths.
• #12345 is invalid because five digits sits between the legal 4 and 6 and matches neither.

A value like #1A2B3C passes: hash, six digits, all of them in 0-9a-f. The validator does not care about case, but it does care about length and alphabet, and those two checks catch almost every real mistake you will see in a palette.

A worked example

Here is a small, realistic list — the kind you might paste straight out of a tokens spreadsheet:

#1A2B3C
#f00
#ff0000cc
#ggg
#ff
#12345
ff8800

Run it through the validator and the report comes back row by row, each with a verdict and a reason:

value,normalized,line,valid,reason
#1A2B3C,#1a2b3c,1,true,OK
#f00,#f00,2,true,OK
#ff0000cc,#ff0000cc,3,true,OK
#ggg,,4,false,non-hex character
#ff,,5,false,wrong length
#12345,,6,false,wrong length
ff8800,,7,false,missing #

Three valid colors, four flagged. The shorthand #f00 and the 8-digit #ff0000cc both pass because they hit the allowed lengths. The last row, ff8800, is the sneaky one — those are all valid hex digits and a valid length, but with no leading hash it is not a color literal, so it is flagged rather than silently accepted. Listing the failures with their reasons turns the check into a punch list: you fix exactly seven characters and re-run.

Cleaning a palette or token file

Validation is the first pass, but the same screen does the cleanup you actually need before handing the list off. The tool keeps unique rows only when you want a deduplicated palette, and it can keep the invalid rows in the output so you have a record of what needs fixing instead of a silently shortened list. You can sort the normalized output so a 200-color export comes back in a predictable order, which makes diffs against the previous version readable.

When the list is clean, you choose the shape you need. The output switches between plain lines, CSV, JSON, Markdown, a SQL IN clause, and a TypeScript union — so a designer can grab a Markdown table while a developer copies a typed union straight into a theme file, from the same validated source. Then you download the exact artifact, or copy it.

One practical caution from the tool's own notes: text copied off a web page or out of a chat often carries hidden whitespace, so normalize before you deduplicate or import — otherwise #f00 and #f00 look like two different colors to a naive dedupe.

Where this fits in a color workflow

I keep this open as a checkpoint between "someone gave me colors" and "these colors go into the repo." The order I run things rarely changes. If the colors are buried in CSS, a stylesheet, or a pasted page, I pull them out first with the Hex Color Extractor, then paste the result here to validate. If I am only checking a clean column, I start here. The win is that I find the broken value while it is still a line in a text box, not after a CI job has failed and I am bisecting a token file to find which of 180 colors is malformed.

Two neighboring tools cover the steps on either side of validation. Once everything is valid, the Hex Color Normalizer lets you settle on one consistent form — for example expanding every shorthand #f00 to its full #ff0000 so the file has no mixed lengths. And when a list has obvious duplicates piling up from multiple sources, the Hex Color Deduplicator collapses them so the palette you ship has each color exactly once.

If your colors live inside CSS custom properties rather than a flat list, the CSS Variable Extractor pulls the --token: value pairs out so you can feed the values here for the same checks.

What validation does not tell you

It is worth being clear about the limit. A color passing the syntax check means it is a well-formed hex literal — nothing more. It does not mean the value is the right color, that it matches the brand spec, or that it meets a contrast requirement against its background. The validator catches structural mistakes (#ggg, #ff, #12345, a missing hash); it cannot catch a perfectly valid #fffffe that was supposed to be #ffffff. Treat the green rows as "safe to parse," not "correct by design," and keep a human eye on the palette for the judgment calls.

Everything runs in your browser. Parsing, validation, normalization, deduplication, copy, and download all happen locally — uploaded text files are read with the File API in the tab and never sent to a server — so checking a confidential brand palette or an internal token sheet does not leak it anywhere. Paste the list, read the reasons, fix the flagged rows, and export the form you need.

---

Made by Toolora · Updated 2026-06-13