Convert a Phone List to CSV, JSON, and SQL IN for Bulk Sends

Every team that runs SMS campaigns or keeps a CRM tidy hits the same small, annoying wall. Someone sends you a column of phone numbers pasted out of a spreadsheet, a support ticket, or a copied web page, and the system you need to feed it into wants something else entirely. The SMS API wants a JSON array. The CRM query wants a SQL IN (...) list. The fixture in your test suite wants a TypeScript union of string literals. Hand-quoting forty numbers and chasing a missing comma is the kind of work that eats ten minutes and introduces one typo you find in production.

The Phone Number List Converter does that reshaping in one step. You paste the list, pick the output format, and copy or download the artifact. Nothing leaves the browser tab. This post walks through exactly which formats it produces and how I use them for bulk sends and CRM uploads.

The formats this tool actually produces

The converter reads phone numbers from pasted text, logs, CSV exports, copied HTML, Markdown notes, support tickets, or an uploaded local text file. From that same local parser it gives you six output shapes:

Plain lines — one normalized number per line, the simplest hand-off.
CSV — a column you can drop into a spreadsheet, a ticket system, or a CRM importer.
JSON — an array of strings, ready to paste into an API request body.
Markdown — a table you can put straight into a review doc or a wiki page.
SQL IN — a quoted, comma-separated list wrapped for an IN (...) clause.
TypeScript union — string literals joined with | for a typed allow-list or fixture.

That is the full set. There is no XML, no YAML, no protobuf here. The point is the handful of shapes that real SMS and CRM workflows ask for, done without you touching a single quote mark.

A worked example: one list, two payloads

Say a teammate drops this into Slack and asks you to "get these into the campaign":

415-555-0182
+1 (628) 555 0row 144
628-555-0144
415-555-0182
4155550182

Paste it in, turn on "keep unique rows only," and the parser normalizes and dedupes. For the JSON output you get a clean array you can drop straight into an SMS API payload:

["+14155550182", "+16285550144"]

Switch the format selector to SQL IN and the same list becomes a query fragment for pulling those contacts out of your CRM:

IN ('+14155550182', '+16285550144')

So a full CRM query reads naturally:

SELECT id, name FROM contacts WHERE phone IN ('+14155550182', '+16285550144');

Two formats, one paste, zero hand-quoting. The duplicate 415-555-0182 collapsed into a single entry, and the variant 4155550182 matched the same normalized number instead of becoming a second row that would have double-texted the contact.

Why invalid rows are held back, not silently dropped

A bulk SMS batch is unforgiving. One malformed number can bounce the whole job or burn credits on a delivery that never lands. The converter does not quietly fold a short or broken number into the output. A one-short number like 415-555-013 is held out of the converted result and listed separately with its reason, so you can fix it before the batch goes out rather than discover the failure in a carrier report afterward.

If you want a paper trail, keep the invalid rows visible and download the CSV or Markdown with the validation notes attached. That gives you something to show when a stakeholder asks why fourteen of two hundred numbers did not make it into the send.

How I actually use it on a campaign day

When I prep a Tuesday SMS blast, the raw list almost never arrives clean. I get one column from the events team and another from a CSV export, both with stray whitespace and a few duplicates across the two. I paste both into the converter, switch on dedupe and sort, and read the count. If the count is lower than I expected, that is usually duplicates I would have texted twice. I copy the JSON array straight into the API request to schedule the send, then flip the format to SQL IN and paste that into a CRM query to tag exactly those contacts as "messaged this week." The whole reshape takes under a minute, and because the parsing runs locally I am not pasting a column of customer phone numbers into some random web form to get it reformatted.

The one habit I would push: normalize before you dedupe. Copied web text carries hidden whitespace and non-breaking spaces, so two numbers that look identical can survive as separate rows unless you normalize first. The tool handles the normalize step, but it is worth understanding why the dedupe count sometimes drops further than you expected.

Where it fits with the rest of the phone toolkit

The converter shares a parser with a small family of single-purpose tools, so you can stop at whatever step you need. If all you want is to pull numbers out of a messy page, the phone number extractor does only that. To check a list for format problems without converting anything, use the phone number list validator. To standardize formatting across mixed inputs, reach for the phone number normalizer, and to collapse duplicates in place, the phone number deduplicator is the focused option.

When your hand-off is a spreadsheet rather than code, the CSV to Markdown table tool turns the CSV output into something a review doc can render, and the text file cleaner is handy upstream when the source dump has junk lines wrapped around the numbers you actually want.

Quick reference

Input: pasted text, logs, CSV, HTML, Markdown, support tickets, or a local file (read in-browser).
Output: plain lines, CSV, JSON array, Markdown table, SQL IN, TypeScript union.
Controls: keep unique rows, preserve invalid rows for review, sort the normalized output.
Privacy: every step runs in the tab; nothing is uploaded to Toolora servers.

Phone numbers are customer data, and reshaping them should never mean handing the list to a server you do not control. Paste the list you actually mean to send, pick the format the next system wants, and move on.

Made by Toolora · Updated 2026-06-13