Convert a Date List into SQL, JSON, CSV, and TypeScript

Most date wrangling does not start with a database. It starts with a list someone pasted into a Slack message, a column copied out of a spreadsheet, or a stretch of log lines from a support ticket. The dates are real, the format is ISO 8601, but the shape is wrong for wherever they need to go next. A query wants IN ('2024-01-01', '2024-02-01'). A test fixture wants a JSON array. A spreadsheet wants CSV. Doing that by hand means typing quotes and commas around every value and hoping you did not miss one.

The ISO Date List Converter takes the boring part off your plate. You paste the dates, it parses them in the browser, and it re-emits the same set in whichever format you actually need. Nothing leaves the tab.

The formats this tool produces

Per the tool itself, one pasted list can be converted into six outputs from the same local parser:

Plain lines — one normalized date per line
CSV — for spreadsheets, CRMs, and ticket imports
JSON — a clean array of strings, ready for a fixture or an API payload
Markdown — for review docs and pull requests
SQL IN — a quoted, comma-separated IN (...) body for a WHERE clause
TypeScript union — a string-literal union type for typed seed data

You can keep unique rows only, preserve invalid rows for review, and sort the normalized output before you export. So a list that arrived noisy and out of order comes out deduped, sorted, and quoted exactly the way the destination expects.

From a pasted column to a SQL IN clause in one step

Here is the case I hit most often. A teammate sends me a column of dates and asks for the rows that fall on those days. Say the input is just this, pasted as-is:

Switch the output to SQL IN and you get the body of a WHERE clause, deduplicated and quoted, with no hand-editing:

IN ('2024-01-01', '2024-02-01', '2024-03-15')

Drop that straight into a query:

SELECT * FROM invoices WHERE issued_on IN ('2024-01-01', '2024-02-01', '2024-03-15');

Switch the same input to JSON instead and you have a fixture array:

["2024-01-01", "2024-02-01", "2024-03-15"]

Same four pasted lines, two ready-to-use artifacts, zero manual quoting. The duplicate 2024-01-01 collapsed because unique-rows-only was on, and both outputs came from one parse of one input box.

Why this beats hand-quoting for date-range work

When you build a date filter by hand, three small mistakes show up again and again: a dropped comma between two values, a value left unquoted so the database reads it as arithmetic, and a duplicate that quietly skews a count. None of them throw a loud error. They just give you a slightly wrong result that you trust because the query "ran fine."

Converting the list mechanically removes all three. Every value is quoted, every separator is placed, and duplicates are gone before the clause is built. The tool also lets you keep invalid rows on purpose, so a typo'd 2026-06-32, a US-style 06/12/2026 that is not ISO, or a blank cell shows up in the output instead of silently disappearing. That is exactly the set of rows a date column would reject on import, surfaced before you run anything.

Seed data and typed fixtures

The same flow covers seed data. If you are populating a test database or a TypeScript fixture, paste the dates and pick the format that fits the file:

CSV to feed a loader script or a spreadsheet-driven import.
JSON for a seed.json array or an API mock.
TypeScript union when you want a literal type like type Holiday = '2024-01-01' | '2024-02-01' | '2024-03-15' so a typo in a later reference fails at compile time instead of at runtime.

Because the converter normalizes first, the values you seed match the values you will later query. A list cleaned once stays consistent across the fixture, the migration, and the assertion.

How I actually use it

I keep this tab open during data cleanup days. My pattern is always the same: paste whatever messy column landed in my inbox, turn on unique rows and sort, eyeball the invalid rows the tool kept, then flip the output between SQL IN and JSON depending on whether I am writing a query or a fixture. The first time I used it I had been hand-building an IN (...) clause from about forty dates copied out of a planning doc, and I had already missed a comma twice. Pasting the column and switching to SQL IN gave me the whole clause, deduplicated, in the time it took to read this sentence. I have not hand-quoted a date list since.

Pair it with the rest of the date toolkit

This converter is the "reshape it" step. The other date tools handle the steps around it. If your source text is buried inside logs or pasted HTML, pull the dates out first with the ISO Date Extractor. If you only need to check whether a list is clean rather than reshape it, the ISO Date List Validator reports which rows would fail. To collapse a list down to unique values on its own, reach for the ISO Date Deduplicator. And when the values are stored in inconsistent forms, the ISO Date Normalizer brings them to one shape before you convert.

A practical chain looks like this: extract the dates from the raw source, normalize them, dedupe, then convert the cleaned list straight into the SQL IN clause or JSON array your query or fixture needs. Each tool runs locally, so the data never leaves your browser at any step.

The short version

A column of ISO dates is rarely in the shape your code wants. Instead of typing quotes and commas around every value, paste the list and let the tool emit it as plain lines, CSV, JSON, Markdown, a SQL IN clause, or a TypeScript union. Keep unique rows, sort, and review the invalid ones before you export. It is a small step that removes a whole category of quiet, hard-to-spot bugs in date-range queries and seed data.

Made by Toolora · Updated 2026-06-13