Convert a CSS Variable List into JSON, a TypeScript Union, CSV, or SQL IN

A design system tends to accumulate a long roster of CSS custom properties: --brand-blue, --brand-red, --space-2, --radius-pill, and on and on. The names live in a theme file, but the moment you want to use them somewhere else — a typed helper, a documentation table, a database lookup — you face the same chore. You copy the names out, then hand-add quotes, commas, brackets, and pipes until the shape matches whatever consumer you are feeding. It is tedious, and it is exactly the kind of work that invites a missing comma at 5pm.

The CSS Variable List Converter exists to delete that step. You paste the raw list of --token names, pick a target format, and copy or download the result. Every format below comes straight from the same local parser, so the names you put in are the names you get back — just reshaped.

The output formats this tool actually offers

Per the tool itself, the converter emits six formats from one pasted list:

Plain lines — one property name per row, cleaned and normalized.
JSON array — a quoted array you can drop into a config file or a docs build step.
CSV column — a single column with a header, ready for a spreadsheet, a CRM, or a ticket system.
Markdown — a list or table fragment for a README or a design-system doc page.
SQL IN list — a parenthesized, comma-separated set for a WHERE column IN (...) query.
TypeScript union — a string-literal union type for type-safe token references.

That is the whole menu, and it covers most places a token name needs to travel. You can also keep unique rows only, sort the normalized output, and preserve invalid rows beside their reason so you can fix the theme source before exporting.

A worked example: from a plain list to a TypeScript union and JSON

Say you copy this block out of your theme file:

--brand-blue
--brand-red
--brand-blue
--space-2

Switch the output to TypeScript union, turn on unique rows, and you get a type-safe set of token names with the duplicate collapsed:

type CssToken = '--brand-blue' | '--brand-red' | '--space-2'

Now a helper like getToken(name: CssToken) will reject '--brnad-blue' at compile time instead of failing silently in the browser. Flip the same input to JSON array, and the converter hands you:

["--brand-blue", "--brand-red", "--space-2"]

That JSON drops straight into a documentation generator or a build step that renders a token reference page. Same input, two consumers, one step each — no manual quoting, no forgotten comma between the second and third entry.

Typed token references without the busywork

The TypeScript union is the format I reach for most. A union of literal strings is the cheapest way to make token access type-safe: the compiler knows the full set, autocomplete suggests the real names, and a typo turns into a red squiggle. The catch has always been building the union by hand, because a real design system has dozens of properties and the syntax is finicky. Producing '--a' | '--b' | '--c' | ... across 40 tokens by hand is how you end up with a stray | at the end of the list.

Feeding the converter the raw --name list and copying the union out removes that failure mode entirely. When a new token lands in the theme, you re-run the convert step and paste the refreshed union over the old one. The type stays honest with the stylesheet, and the diff in your pull request is clean enough to review in seconds. If you only need to pull the property names out of a messy stylesheet before converting, the CSS Variable Extractor does the extraction half and pairs naturally with this tool.

CSV, Markdown, and SQL IN for everything else

Not every destination wants TypeScript. A documentation page often wants Markdown, so the writer can drop a token table into a README without escaping anything. A spreadsheet or a ticket import wants CSV with a header row. And if your tokens are tracked in a database — a theming service, a feature-flag table, an audit log of which properties shipped in which release — the SQL IN list saves you from assembling ('--brand-blue', '--brand-red', ...) by hand for a SELECT ... WHERE name IN (...) query.

The point of having all six in one place is that the source list never changes. You normalize and dedupe once, then re-emit the same clean names into whichever shape the next system expects. That is also why keeping invalid rows around matters: a property with an empty value or a broken name is flagged with its reason, so you can correct the theme file before it leaks into your JSON, your union, or your database.

A few things to watch

Text copied from a web page or a chat tends to carry hidden whitespace, so normalize before you deduplicate — otherwise --brand-blue and --brand-blue count as two distinct tokens. If you want an audit trail of what shipped, download CSV or Markdown with line numbers rather than copying only the final list; a flat copy loses the provenance. And remember that the converter validates shape, not existence: a name being well-formed says nothing about whether that custom property is actually defined somewhere in your CSS.

Everything runs in the browser. The list you paste is parsed, validated, deduped, and re-emitted in the same tab, and uploaded text files are read locally with the File API rather than sent to a server — which matters when your theme file sits inside a private repository. When the basic shape of a token list needs an actual pass/fail check before conversion, the CSS Variable List Validator reports each row's status without changing it.

Why this beats reformatting by hand

The honest answer is consistency. Doing this conversion manually is not hard for three tokens; it is error-prone for forty and miserable for four hundred. A converter that takes one list and produces JSON, a TypeScript union, CSV, Markdown, SQL IN, or plain lines means the names are the only thing you ever curate. The punctuation — the quotes, the pipes, the parentheses — is generated the same way every time, so a review never stalls on a missing bracket. Paste the list, pick the format, ship the artifact.

Made by Toolora · Updated 2026-06-13