Convert an Email List into CSV, JSON, SQL IN, and TypeScript Union Output

A pasted column of email addresses is one of the most common things I end up holding in a scratch buffer, and one of the least useful in that raw shape. A newline-separated list looks tidy, but the moment you want to drop it into a WHERE email IN (...) query or a JavaScript array, it is dead weight. SQL needs each address wrapped in single quotes and joined with commas. A JS or JSON array needs double quotes and commas. A TypeScript union needs quotes, the | separator, and no trailing junk. Doing that by hand for forty addresses is exactly the kind of fiddly, error-prone busywork that produces a missing quote three lines from the bottom and a syntax error you spend ten minutes hunting.

The Email Address List Converter exists to skip all of that. You paste the list, it reads the addresses with a dedicated parser, and it re-emits the same set in whichever format you ask for. The values never change between formats — only the punctuation and shape around them.

The formats this tool actually outputs

Per the tool's real behavior, you get six output shapes from the same parse:

Line — one address per line, normalized and optionally deduped or sorted.
CSV — a comma-separated form you can hand to a CRM import, a ticket system, or a spreadsheet.
JSON — a JSON array of strings, ready for a config file, a test fixture, or a fetch body.
Markdown — a list you can drop into a review doc, a runbook, or a PR description.
SQL IN — a parenthesized, single-quoted, comma-joined clause that pastes straight after WHERE email IN.
TypeScript union — a quoted, |-joined string-literal union for typing an allow-list or a fixture.

Switching the format never changes the underlying values. You parse once, then toggle between line, CSV, JSON, Markdown, SQL IN, and TypeScript union as the destination demands.

Why a raw list is useless until it is quoted and joined

Here is the concrete problem. Suppose you have three addresses sitting in a text file:

ana@acme.com
ben@acme.com
cara@globex.io

That is perfectly readable, and perfectly broken for a database. Paste it after IN and the engine sees three bare identifiers, not three string literals, and rejects the whole statement. The same list pasted into a .ts file is three undeclared symbols. The data is fine; the packaging is wrong. Until each address is quoted and the set is comma-joined, the list cannot cross into a query or a typed array.

The converter does that packaging in one step. Pick SQL IN and the three lines become:

('ana@acme.com','ben@acme.com','cara@globex.io')

Pick JSON and the same three lines become:

["ana@acme.com", "ben@acme.com", "cara@globex.io"]

You paste the first directly after WHERE email IN, and the second straight into a fixture or a request body. No hand-typed quotes, no counting commas, no trailing-comma syntax error.

A worked example, start to finish

Say a teammate dumps a distribution list into a chat message and you need to both query those users and seed a test fixture. The input you paste:

ana@acme.com
ben@acme.com
cara@globex.io
ana@acme.com

Note the duplicate ana@acme.com — copied lists almost always carry one. Turn on unique so the converter keeps a single row per address, then read the SQL IN output:

('ana@acme.com','ben@acme.com','cara@globex.io')

Flip the format selector to JSON and, with no other change, the same deduped set renders as:

["ana@acme.com", "ben@acme.com", "cara@globex.io"]

One paste in, two ready-to-use artifacts out. The SQL goes into your query; the JSON array goes into the fixture.

Invalid rows stay visible instead of poisoning the output

A list scraped from logs or copied HTML is rarely clean. You get a bob@ with no domain, a local part with an illegal character, or a stray comma fused into an address. The converter treats those as invalid rows: it flags them with a reason rather than silently quoting garbage into your SQL clause. You decide whether to keep invalid rows in the output for review or drop them so your target table stays clean. That choice is the difference between a query that runs and one that throws halfway through a migration.

If the upstream cleanup is the bigger job, pull the addresses out of messy source text first with the Email Address Extractor, then bring the cleaned list back here to reshape it into the format your destination wants.

How I use it on a normal day

I keep this tab open whenever I am doing anything with a list of people. Last week I had a churned-cohort export — a couple of hundred addresses with a few obvious duplicates and one row that was clearly a pasted display name, not an email. I pasted the whole thing in, switched on unique and sort, and watched the bad row drop into the invalid list with a reason next to it. Then I flipped to SQL IN to pull those users' last-login timestamps, flipped to JSON to feed the same set into a one-off script, and flipped to Markdown to paste a clean roster into the ticket so the next person had the list spelled out. Same parse, three destinations, zero hand-editing. The part I appreciate most is that it runs entirely in the browser — customer email addresses never leave the tab, which matters when the source is a real subscriber export.

When to reach for it

Reach for the converter any time the gap between "I have a list of addresses" and "I need them in a query, a script, or a doc" is just punctuation. If the destination is a database, take the SQL IN output. If it is code, take JSON or the TypeScript union. If it is a human-readable handoff, take Markdown or CSV. It is sized for the everyday case — a subscriber export, a pasted distribution list, a roster column of a few megabytes — rather than multi-million-row dumps, which you should chunk locally first.

For the next step in a doc workflow, once you have a CSV you can hand it to the CSV to Markdown Table converter to drop a formatted table straight into a runbook or a report. Between the two, a raw column of addresses goes from clipboard scratch to a finished, paste-ready artifact without a single hand-typed quote.

Made by Toolora · Updated 2026-06-13