Skip to main content

Convert an IPv6 List to SQL IN, JSON, CSV, and TypeScript in One Step

Turn a column of IPv6 addresses into a SQL IN clause, JSON array, CSV, or TypeScript union for log queries, configs, and allowlists without hand-quoting.

Published By Li Lei
#ipv6 #sql #json #networking #developer-tools

Convert an IPv6 List to SQL IN, JSON, CSV, and TypeScript in One Step

IPv6 addresses are full of colons, and colons are exactly the character that makes copy-paste into a database query or a config file annoying. Every address you want to drop into a SQL IN (...) clause needs its own pair of quotes and a trailing comma, and a single missed comma turns a five-minute log query into a syntax error you have to hunt down. When the list is twenty addresses pulled from a subnet plan or a firewall export, hand-formatting it is the kind of busywork that should not exist.

The IPv6 Address List Converter takes a plain column of IPv6 addresses and re-emits the same set in the format your next tool actually wants. Per the tool itself, those formats are: plain line output, CSV, JSON, Markdown, SQL IN, and a TypeScript union. You paste the raw list once, pick a format, and the quoting, commas, and brackets are handled for you. Everything runs in the browser, so a list of internal addresses never leaves the tab.

The one-step example

Say you have this column of addresses, copied straight out of a routing table or a ticket:

2001:db8::1
2001:db8::2
2001:db8::3

Choose SQL IN and you get a clause you can paste directly after WHERE ip IN:

('2001:db8::1', '2001:db8::2', '2001:db8::3')

Switch the same input to JSON and you get an array ready for a config file, a fixture, or an API payload:

["2001:db8::1", "2001:db8::2", "2001:db8::3"]

No manual quoting of each colon-heavy address, no counting commas. The CSV output gives you a column you can drop into a spreadsheet, and the TypeScript union gives you a literal type like "2001:db8::1" | "2001:db8::2" | "2001:db8::3" for an allowlist constant. The Markdown output is the one I reach for when the list is going into a review doc or a pull request description rather than into code.

Filtering a log table by a set of addresses

The format I use most is SQL IN, and the reason is log queries. When an incident touches a handful of hosts, you usually start with a list of their IPv6 addresses in a chat thread or an alert, not in a query-ready form. Pasting that list into the converter and exporting SQL IN means the WHERE clause is built before I have even switched back to the database console.

It also keeps the query honest. If one of the pasted addresses is malformed (a group with five hex digits, or a stray /64 that someone left attached), you can turn on the option to keep invalid rows so the bad entry shows up instead of silently corrupting the clause. You see exactly what a strict importer would reject, which is far better than a query that runs but quietly skips a row.

Allowlists, configs, and fixtures

Beyond log queries, the same conversion fixes a recurring chore in config and code work:

  • Firewall and proxy allowlists. Many config formats want a plain newline-delimited list, which is the line output. Others want a JSON array, which the JSON format gives you directly.
  • Application allowlist constants. The TypeScript union output turns a set of addresses into a type you can use to constrain a variable, so an address outside the approved set fails at compile time rather than at runtime.
  • Test fixtures. A JSON array of addresses drops straight into a fixture file, and because the parser deduplicates, you do not seed a test with the same address twice.

Before you convert, it is worth normalizing and deduplicating the input. The converter can keep unique rows only and sort the normalized output, so a list with 2001:DB8::1 and 2001:db8::0:1 collapses into one canonical form. If your raw data is messier, the IPv6 Address Normalizer is the companion tool for getting every address into the same shortened, lowercase shape first.

A note on what the tool does not do

Format conversion is not validation of reality. A correctly formatted IPv6 address tells you the string is syntactically valid, not that a host answers there. I have watched a clean-looking allowlist sail through every format check and still be wrong, because two of the addresses were typos that happened to be valid IPv6. The converter helps you catch structural problems (wrong group count, missing ::, leftover CIDR notation) when you keep invalid rows visible, but it cannot tell you that an address points at the machine you meant. Treat the output as a well-formed list, then confirm the addresses against your actual inventory.

Copied web text is another quiet source of trouble. Pasting from an HTML table or a rendered page often drags in hidden whitespace, so normalize before you deduplicate or the same address can appear twice under two different invisible suffixes. When you need an audit trail, download the CSV or Markdown output with line numbers rather than copying only the final compacted list.

Why local conversion matters here

The input to this tool is frequently sensitive: internal address ranges, the layout of a private network, or the hosts caught up in an incident. Sending that to a remote formatter to add some quotes is a poor trade. Every step here (parsing, validating, deduplicating, and producing CSV, JSON, Markdown, SQL IN, or TypeScript union) runs in your browser, and uploaded text files are read locally through the File API. The artifact you copy or download is the only thing that leaves, and it leaves on your terms.

If you also need to pull addresses out of mixed text rather than convert a clean column, the IPv6 Address Extractor scans logs and pasted pages for addresses first, and you can feed its result straight into this converter for the final formatting pass. Together they turn a messy paste into a query-ready, config-ready list in a couple of clicks.


Made by Toolora · Updated 2026-06-13