How to Convert a MAC Address List Into JSON, CSV, and SQL IN

A list of MAC addresses almost never arrives in the shape you need it. Someone pastes a column out of a spreadsheet, a switch dumps a learned-address table, or a support ticket lists six devices a customer wants on the guest network. You have the addresses. What you do not have is the format the next system expects: a JSON array for a config file, a comma-and-quote-wrapped SQL IN clause for a device-table query, or a CSV ready to import into a DHCP reservation tool.

Hand-quoting each address is where the mistakes creep in. Miss one comma in a SQL IN list and the query throws a syntax error. Forget a closing quote in a JSON array and the whole config refuses to load. The MAC Address List Converter exists to take that fiddly reformatting off your plate. Paste a flat list once, pick the output format, and copy or download the exact artifact you need.

The output formats this tool actually produces

It is worth being precise about what comes out, because the format you pick determines whether the result drops cleanly into your workflow. From the same local parser, this tool gives you six outputs:

• Plain lines — one normalized address per line, the cleanest starting point for a script or a paste-into-text-field.
• CSV — one address per row, ready for a spreadsheet import or a DHCP reservation upload.
• JSON — a JSON array of strings, for config files and fixtures.
• Markdown — a list you can drop into a runbook, a review doc, or a ticket comment.
• SQL IN — a parenthesized, quoted list for WHERE mac IN (...) device-table queries.
• TypeScript union — a string-literal union type for allowlists you type-check at build time.

You switch between all six without re-pasting the source. Pick JSON for the config, then flip to SQL IN to write the query that checks those same devices against your inventory table.

A flat list to JSON and SQL IN in one step

Here is the move that saves the most time. Say a network admin hands you this list of devices to add to an allowlist:

00:1A:2B:3C:4D:5E
A0:B1:C2:D3:E4:F5
3C:5A:B4:1F:9D:0E

Switch the output to JSON and you get an array you can paste straight into a config:

["00:1A:2B:3C:4D:5E", "A0:B1:C2:D3:E4:F5", "3C:5A:B4:1F:9D:0E"]

Now switch the same list to SQL IN to query your device table for those three machines:

('00:1A:2B:3C:4D:5E', 'A0:B1:C2:D3:E4:F5', '3C:5A:B4:1F:9D:0E')

Drop that into SELECT hostname, last_seen FROM devices WHERE mac IN (...) and you have a one-line answer to "which of these are already on the network and when did we last see them." No manual quoting, no chasing a missing comma down a forty-line list.

Real jobs this format-switching unlocks

The reason these formats matter is that device data lives in a lot of systems that each speak their own dialect.

Device inventories. You inherit a CSV export of every laptop in the building, but your asset database wants a JSON array. Paste the addresses, keep unique rows only so duplicates from overlapping exports collapse, sort the normalized output, and export JSON. The inventory import takes it without complaint.

DHCP reservations. You are pinning a batch of printers and access points to fixed addresses. Paste the list from the procurement spreadsheet, export CSV, and feed it to your reservation tool. Because the parser holds back malformed rows — a wrong-length address like 00:1A:2B:3C:4D gets listed with its reason instead of being wrapped into the output — a bad paste does not silently break the import.

Allowlists. A port-security policy or a captive-portal config wants exactly the addresses you trust. Export a TypeScript union if your config is typed code, or a SQL IN clause if it is a database-backed allowlist. Either way the addresses are quoted and bracketed for you.

Why the converter holds back invalid rows

This is the detail I appreciate most. The first time I ran a switch table through it, I expected a wrong-length entry to either crash the output or get silently dropped. Instead it pulled 00:1A:2B:3C:4D out of the converted result, flagged it with a reason, and let the eleven good addresses convert normally. That is exactly the behavior you want when the output is headed for an automated import: one malformed address should not poison a SQL IN clause or a JSON array and take down the whole load. You get a clean artifact plus a short list of what to fix, rather than a syntax error three systems downstream with no clue which address caused it.

Keep the workflow honest

A few habits keep the results trustworthy. Normalize before you deduplicate — copied web text often carries hidden whitespace, so two addresses that look identical can survive a naive dedupe. Treat format validation as exactly that: a correctly shaped MAC is not proof that the device is real, registered, or yours to allow. And when you need an audit trail for who got added to an allowlist and when, download the CSV or Markdown with the rows preserved rather than copying only the final blob.

Everything runs in the browser tab. Turning a column of addresses into a SQL IN list is pure string work, so the device list never leaves your machine — which matters when the addresses belong to a customer's network. If you only need to pull addresses out of messy source text first, the MAC address extractor handles that step, and the converter takes it from the clean list onward.

The whole point is to spend zero time on quotes and commas. Paste once, pick the format the next system speaks, copy the result, and move on.

---

Made by Toolora · Updated 2026-06-13