Convert a UUID List to SQL IN, JSON, and TypeScript in One Step

A list of UUIDs shows up in the most awkward shape possible: one per line, copied out of a spreadsheet column, a log grep, or a support ticket. You almost never want it that way. You want it as a WHERE id IN (...) clause to run a batch lookup, as a JSON array to drop into a fixture, or as a TypeScript union of literals to lock down a set of allowed IDs. Doing that conversion by hand means adding a quote and a comma around every single value, and one missing quote breaks the whole query.

The UUID List Converter does that reshaping for you. Paste a column of UUIDs, pick an output format, and it re-emits the same IDs in the shape your next step actually expects. The parser runs entirely in the browser, so customer IDs and internal identifiers never leave the tab.

What this tool actually outputs

Per the tool, you get six output formats from one local parser:

Plain lines — one UUID per line, normalized.
CSV — a column you can paste back into a sheet or feed a script.
JSON — a real array of strings.
Markdown — a list or table for review docs and tickets.
SQL IN — a quoted, comma-joined list ready to slot into WHERE id IN (...).
TypeScript union — the IDs as a union of string literals.

On top of the format switch, you can keep unique rows only, preserve invalid rows for review so the output stays one-to-one with the input, and sort the normalized output. That covers the three things you usually need at once: clean the list, dedupe it, and hand it off in the right format.

From a column of UUIDs to a WHERE id IN clause

This is the case that saves the most typing. Say a teammate dumps you a handful of order IDs to investigate:

3f2504e0-4f89-41d3-9a0c-0305e82c3301
a1b2c3d4-e5f6-7890-abcd-ef1234567890
3f2504e0-4f89-41d3-9a0c-0305e82c3301
6ba7b810-9dad-11d1-80b4-00c04fd430c8

Paste that in, turn on unique, and switch the output to SQL IN. The deduped, quoted result comes out ready to paste:

SELECT * FROM orders
WHERE id IN (
  '3f2504e0-4f89-41d3-9a0c-0305e82c3301',
  '6ba7b810-9dad-11d1-80b4-00c04fd430c8',
  'a1b2c3d4-e5f6-7890-abcd-ef1234567890'
);

The duplicate 3f2504e0... collapsed to one row, and every value is single-quoted and comma-separated for you. No hand-quoting, no trailing-comma syntax error to chase. Flip the same input to JSON and you get:

[
  "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
  "6ba7b810-9dad-11d1-80b4-00c04fd430c8",
  "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
]

Same IDs, same dedupe, different wrapper. That JSON array drops straight into a test fixture, a request body, or a config file.

Typed ID sets with the TypeScript union output

The SQL angle is about batch lookups; the TypeScript angle is about type safety. When you have a fixed set of IDs that a function should accept — feature-flagged accounts, a seed of demo records, a whitelist — a union of string literals turns runtime checks into compile-time ones. The same four UUIDs above become:

type AllowedId =
  | "3f2504e0-4f89-41d3-9a0c-0305e82c3301"
  | "6ba7b810-9dad-11d1-80b4-00c04fd430c8"
  | "a1b2c3d4-e5f6-7890-abcd-ef1234567890"

Now AllowedId only accepts those exact strings, and a typo gets caught by the compiler instead of at runtime. Building that union by hand from a list of forty IDs is exactly the kind of tedious, error-prone job that should be a single format toggle, and here it is.

Why I keep invalid rows on

I review a lot of pasted lists, and the first time I deduped a column of UUIDs I lost a row without noticing — it had a stray trailing character, got flagged as invalid, and silently dropped. After that I started leaving "include invalid rows" on by default. With it enabled, a malformed or short value still comes through with its reason attached, so the output stays the same length as the input and I can see exactly which row a query would reject before I run it. If I'm assembling a SQL IN list to feed a production lookup, I would much rather see the bad value sitting there than discover later that my "complete" list quietly had 39 of 40 IDs.

A small habit that pairs with this: copied web text often carries hidden whitespace, so normalize before you dedupe. Two UUIDs that look identical can differ by an invisible trailing space and survive a naive dedupe as two rows. The converter normalizes first, which is why the duplicate in the example actually collapsed.

Where it fits in a cleanup workflow

The converter is one stop in a longer chain. If your raw text is messier than a clean column — UUIDs buried in log lines, HTML, or Markdown — start with the UUID Extractor to pull just the IDs out, then bring the result here to reshape it into SQL, JSON, or a union. The two tools share the same local parser, so nothing you paste touches a server in either step.

A typical flow looks like this: extract the IDs from a log, paste them into the converter, turn on unique and sort, preview the SQL IN output, and download the artifact. Because every action runs in the browser with the File API for uploads, you can do all of this on a list of real customer identifiers without worrying about where the data goes. Just be deliberate when you copy or download output that contains those identifiers, and treat a valid UUID as well-formed, not as proof the record exists.

The point of the tool is narrow on purpose. It does not query your database or guess your schema. It takes a list of UUIDs and gives you the exact text shape your next step wants — a quoted IN list, a JSON array, a typed union, a CSV column, or a Markdown table — so you spend your attention on the query, not on quoting.

Made by Toolora · Updated 2026-06-13