Convert a Postal Code List to SQL IN, JSON, CSV, and TypeScript

A column of postal codes is one of those things that lands in your lap already half-broken. Someone pastes it from a spreadsheet, a support ticket, or a copied web table, and now you need to query an address database with it, or drop it into a shipping-zone config. The codes are fine. The shape is wrong. You have a vertical list, and what you actually need is IN ('90210','10001') or a JSON array.

That gap, between "a list of ZIP codes" and "a list of ZIP codes in the exact syntax the next system expects," is the whole reason the Postal Code List Converter exists. It reads a pasted or uploaded list, parses it in your browser, and re-emits it in the format you point at. No quotes to type by hand, no commas to miss on the last row.

The formats this tool actually outputs

Be precise about what you get, because that determines what you can paste it into. From the same local parser, this tool produces:

Plain lines — one postal code per line, cleaned and normalized.
CSV — the list as comma-separated rows, ready for a spreadsheet or an import job.
JSON — a JSON array of strings, for config files and API payloads.
Markdown — a Markdown-formatted list for docs, tickets, and review notes.
SQL IN — a ('code','code',…) clause you drop straight after WHERE zip IN.
TypeScript union — a string-literal union type, e.g. '90210' | '10001', for a typed enum of allowed zones.

That is the full set. If a format you want is not in that list, this is not the tool for it. But for moving postal codes between a database query, a config file, and a typed constant, those six cover the path end to end.

From a column of ZIP codes to a SQL IN clause in one step

Here is the concrete move. You have a column of US ZIP codes pulled from a CRM export:

Paste that in, leave "keep unique rows only" on, and pick the SQL IN output. You get:

('90210','10001','60601')

Notice two things. The duplicate 90210 collapsed to one entry, and 9410 — a four-digit code, one short of a valid US ZIP — did not make it into the clause. That second part matters more than it looks. If a malformed code slips into a WHERE zip IN (...) query against an address table, it silently matches nothing and quietly narrows your result set, and you spend an afternoon wondering why a region looks empty. The converter holds invalid rows back and lists them with a reason instead of folding them into the output, so the clause you paste is the clause you meant.

Now switch the same five-line input to JSON output:

["90210", "10001", "60601"]

Same parse, same dedupe, different wrapper. That array goes straight into a shipping-zone config or an API request body. One paste, two artifacts, zero hand-editing of quotes and brackets.

Where each format earns its place

The reason a single tool offers six outputs is that one postal-code list serves several systems on the same day.

The SQL IN clause is for ad-hoc address-DB work: pull every customer in a set of ZIP codes, count orders by region, or back-fill a region_id column. You write the query once and feed it a clause that is already correctly quoted.

The JSON array is for shipping-zone configs and feature flags — anywhere a service reads a list of eligible postal codes at startup. JSON is also the safest hand-off when you are not sure who consumes the file next.

The TypeScript union is the one people forget exists and then love. If your app has a fixed set of serviceable ZIP codes, a type ServiceZip = '90210' | '10001' | '60601' turns a runtime check into a compile-time one. The converter builds that union from the same list, so the type stays in sync with the data instead of drifting.

CSV and Markdown are for the humans. CSV goes back into a spreadsheet or an import wizard; Markdown goes into a ticket or a review doc where a teammate needs to read the codes, not run them. When you need an audit trail, download the CSV with line numbers rather than copying only the final list, so you can trace any code back to its source row.

How I use it in practice

I keep this tab open during data cleanup the way other people keep a calculator open. Last week I had a list of around 200 postal codes a partner sent in a Slack message — mixed in with stray labels, a few duplicates, and two codes that were obviously a digit short. Old habit: paste into a scratch file, write a tiny script to strip and quote them, debug the script. Instead I pasted the block, turned on dedupe and sort, and grabbed the SQL IN clause for the query and the JSON array for the config in the same minute. The two short codes showed up in the invalid list with their line numbers, so I could ping the partner with exactly which rows to fix instead of "some of these look wrong." The whole detour that used to cost twenty minutes was gone.

Keeping it clean and honest

Two habits keep the output trustworthy. First, normalize before you dedupe. Text copied from a web page or a PDF often carries hidden whitespace, so two codes that look identical can survive as separate rows until you normalize them. Second, do not treat a passing format check as proof the address exists. A code can be perfectly well-formed and still belong to no delivery zone you serve — validation here is about shape, not about whether a parcel can reach it.

Everything runs in the browser. Reshaping a column of codes into a SQL IN list is pure string work, so the address list never leaves your tab to get reformatted on a server. If you only need to pull codes out of messier source text first, the Postal Code Extractor handles the extraction step; then bring the clean list here to convert it into the exact format your database query or shipping-zone config needs.

The point of the converter is narrow on purpose: take a list you already mean to query against, and hand it to the next system in the syntax that system speaks. Paste, pick a format, copy. That is the entire loop.

Made by Toolora · Updated 2026-06-13