Convert an IPv4 Address List into SQL IN, JSON, CSV, and TypeScript Union

A column of IP addresses shows up everywhere a network leaves a trace: an access-log export, a firewall ruleset, a CMDB dump, a Slack thread where someone pasted the hosts that hit a rate limit. The list itself is easy to get. The annoying part is the shape. You have one IP per line, and you need it wrapped in quotes and commas as a SQL IN (...) clause, or as a JSON array for a config file, or as a TypeScript union for a typed allowlist. Doing that by hand for thirty addresses means thirty chances to drop a quote or a comma, and the database tells you about it only when the query fails.

The IPv4 Address List Converter does that reshaping in one step. You paste a list, pick an output format, and copy the result. Everything runs in the browser, so the IPs from your internal access log never leave the tab.

The exact formats this tool produces

This is not a generic text utility that promises every format under the sun. The converter parses dotted-quad IPv4 addresses out of whatever you paste, then re-emits the same set in one of six concrete shapes:

• Plain lines — one address per line, cleaned and normalized.
• CSV — for a spreadsheet, a CRM import, or a script that reads a column.
• JSON — a JSON array, ready to drop into a config file or an API payload.
• Markdown — for a runbook, a review doc, or a ticket.
• SQL IN — a parenthesized, quoted list you paste straight after WHERE ip IN.
• TypeScript union — a string-literal union type for a typed allowlist.

You also choose whether to keep only unique rows, whether to preserve invalid rows for review, and whether to sort the normalized output. Then you copy or download the exact artifact you need.

A worked example: from a pasted column to a SQL clause

Say a teammate sends you the IPs that triggered a spike in your access log:

10.0.0.1
10.0.0.2
10.0.0.2
192.168.1.50
203.0.113.7

Paste that in, switch the output to SQL IN, and turn on unique rows. You get:

('10.0.0.1', '10.0.0.2', '192.168.1.50', '203.0.113.7')

The duplicate 10.0.0.2 collapsed, every value is quoted, and the parentheses are already there. Drop it into a query and you are filtering an access-log table in seconds:

SELECT path, status, count(*)
FROM access_logs
WHERE client_ip IN ('10.0.0.1', '10.0.0.2', '192.168.1.50', '203.0.113.7')
GROUP BY path, status;

Switch the same input to JSON and you get a config-ready array instead:

["10.0.0.1", "10.0.0.2", "192.168.1.50", "203.0.113.7"]

That array goes straight into an allowlist field, a firewall automation script, or a fixture for a test. Same five lines of input, two different downstream destinations, zero hand-quoting.

Where this actually saves time

The format you reach for depends on the job in front of you.

For log analysis, SQL IN is the workhorse. You collect a handful of suspicious source IPs from a dashboard, paste them, and get a clause you can use across every log table in your warehouse without retyping the quotes for each query.

For allowlists and firewall configs, JSON and TypeScript union earn their keep. A JSON array slots into a load balancer or a security group definition. A TypeScript union — type AllowedIp = "10.0.0.1" | "10.0.0.2" | ... — gives you a compile-time list that your IDE will autocomplete and that fails the build if a caller passes an IP that is not on it.

For handoff and review, CSV and Markdown are the quiet wins. CSV with line numbers gives an auditor a trail back to the source. A Markdown list pastes cleanly into a runbook or a pull request description.

Keep the invalid rows when you need a checklist

Hand-maintained IP lists drift. Someone fat-fingers an extra octet, a CIDR range like 10.0.0.0/8 ends up in a plain-IP column, or a cell is just blank. The converter lets you keep invalid rows in the output instead of silently dropping them, and it tells you why each one failed. That matters most right before a database import: keeping the invalid rows shows you precisely what a SQL load would choke on, so you fix the source rather than discover the problem mid-migration. When you only want the clean set, flip unique rows on and the invalid noise drops out.

How I use it on a Friday afternoon

I keep this tool open in a pinned tab during incident cleanup. The pattern that comes up most for me: I pull thirty or forty offending source IPs out of a Grafana panel, paste them in, dedupe, sort, and export as SQL IN. I run the query against the access-log table to confirm the blast radius, then re-export the same input as a JSON array and hand it to the firewall automation repo as the new block list. Two formats, one paste, and I never count a single closing quote. The part I appreciate most is that the IPs from an internal log never touch a server — the parser runs locally, so I am not pasting infrastructure detail into someone else's backend.

Pair it with the focused IPv4 tools

The converter covers the full clean-and-reshape loop, but sometimes you want a single narrow step. If you only need to pull addresses out of a messy log dump, reach for the IPv4 Address Extractor. To check a list against the dotted-quad rules without converting it, use the IPv4 Address List Validator. When duplicates are the whole problem, the IPv4 Address Deduplicator does exactly that. They share the same local parser, so you can move a list between them without ever sending it to a server.

A list of IP addresses is rarely the deliverable. The SQL clause, the JSON array, the typed allowlist — those are. This tool gets you from one to the other without the manual quoting, and without trusting your network data to anything but your own browser tab.

---

Made by Toolora · Updated 2026-06-13