How to Convert a Hex Color List into JSON, CSS Variables, and a TypeScript Union

Every palette I've ever shipped started life as a messy list. Someone pastes twelve hex codes from a Figma export into Slack, a designer drops a column of swatches from a style guide, or a scraped stylesheet leaves me with forty #rrggbb values that need to land in a design-token file by end of day. The values are fine. The shape is wrong. A flat list of hex codes is not a JSON array, it is not a TypeScript union, and it certainly is not a row of CSS custom properties — and hand-quoting forty colors is exactly the kind of work that introduces a dropped comma at row 31.

That gap is the whole reason the Hex Color List Converter exists. You paste a list of hex colors, the parser reads each one locally in your browser, and you pick the output shape you actually need. No round trip to a server, no signup, no copy-pasting into a code editor to add quotes by hand.

The output formats this tool actually gives you

This is the part worth being precise about, because a list converter is only useful if it emits the exact artifact your workflow expects. From the same parsed list of hex colors, the Hex Color List Converter produces six output formats:

Plain lines — one normalized hex value per line, the cleaned-up version of what you pasted.
CSV — rows you can drop into a spreadsheet or feed to a script, with the source line number and validation reason preserved.
JSON — a palette array you can paste straight into a design-token file or a config.
Markdown — a table you can drop into a README, a swatch reference, or a review doc.
SQL IN — a parenthesized, comma-separated list ready for a WHERE color IN (...) clause.
TypeScript union — a union of string literals, so your color names are type-checked at compile time.

Alongside the format switch you get three toggles that matter for token work: keep unique rows only (dedupe a palette that picked up repeats across exports), preserve invalid rows for review (so a stray #12345 or a hash-less ff0000 surfaces instead of vanishing), and sort the normalized output. Everything runs client-side, which is why you can throw a copied internal style guide at it without a second thought.

A worked example: a flat list becomes a palette in one step

Here is the kind of list that lands in my inbox — six brand colors, copied out of a design handoff:

#0F172A
#1E293B
#3B82F6
#60A5FA
#F8FAFC
#EF4444

Switch the output to JSON and you get a palette array, ready to drop into a tokens file:

[
  "#0F172A",
  "#1E293B",
  "#3B82F6",
  "#60A5FA",
  "#F8FAFC",
  "#EF4444"
]

Switch the same list to TypeScript union and the exact same six values come out as a literal type:

type Color =
  | "#0F172A"
  | "#1E293B"
  | "#3B82F6"
  | "#60A5FA"
  | "#F8FAFC"
  | "#EF4444";

That second artifact is the one I reach for most. Once your palette is a union of literals, a teammate who writes color="#3B82F5" (one digit off) gets a red squiggle from the type checker instead of shipping a color that almost matches. The list went from prose to a type-safe contract without me touching a single quote.

Wiring the output into design tokens

The JSON array is the natural feed for a token pipeline. If you keep a colors.json and run it through Style Dictionary or your own build step, the array drops in as a values block and you map names over it. If you prefer to stay in plain CSS, the same cleaned list pastes into a :root block as custom properties — you supply the variable names, the converter supplies the canonical, normalized values so #fff and #FFFFFF don't quietly diverge across files.

The Markdown table earns its place in review docs. When I open a pull request that changes the palette, a Markdown swatch table in the description gives reviewers something concrete to react to instead of a diff of raw hex strings. And the SQL IN output is the unglamorous workhorse: when a color audit lives in a database and someone asks "which products still use the three deprecated greens," you paste those three hex codes and get a ready IN (...) clause.

Keep the invalid rows — they are the point

Palettes exported from real design tools are rarely clean. You get a stray #12345 that is one digit short, a seven-character #aabbccd, or a bare ff0000 that lost its hash on the way through a CSV cell. The default instinct of most converters is to silently drop anything that doesn't parse, which means your palette quietly shrinks and nobody notices until a swatch is missing in production.

Turning on "preserve invalid rows for review" keeps those broken entries in the output with a reason attached, so you can fix the palette instead of losing colors. Pair that with the CSV format, which carries the source line number, and you have an audit trail: you can walk back to the exact row in the original file and correct it. That is the difference between a converter and a cleanup tool.

Where it fits in a larger color workflow

The Hex Color List Converter assumes you already have a list of hex values. If you are still digging colors out of a wall of copied CSS or a pasted HTML page, start one step earlier with the Hex Color Extractor, which pulls the hex codes out of arbitrary text, then bring the result here to reshape it into JSON, a TypeScript union, or a Markdown table.

Two habits keep the output trustworthy. First, normalize before you dedupe — copied web text often carries hidden whitespace, and two "identical" colors can fail to merge because one has a trailing space. Second, when you need an audit trail, download the CSV or Markdown with line numbers rather than copying only the final list; the extra column is cheap insurance when a color goes wrong three sprints later.

A list of hex codes is the most common shape a palette arrives in and the least useful shape to work with. Reshaping it into a JSON array, a CSS-ready set of values, a TypeScript union, or a Markdown swatch table takes one click each — and every one of those artifacts is something you can drop straight into a real file instead of retyping by hand.

Made by Toolora · Updated 2026-06-13