How to Validate IPv6 Addresses and Clean an IPv6 List

An IPv6 address looks simple until you have forty of them pasted out of a network design doc, a firewall config, and three support tickets. Some are written in full, some use the :: shorthand, and one has a typo nobody noticed because the line still "looks like" an address. Before that list reaches an allowlist, a redirect table, or a compliance export, every row needs a yes-or-no answer with a reason attached.

That is exactly the job of the IPv6 Address List Validator. You paste text or load a local file, and it checks each entry against real IPv6 rules in your browser, then hands back a pass/fail report with a reason next to every line. Nothing is uploaded. This guide walks through the rules it enforces and shows a worked example.

What a valid IPv6 address actually is

A valid IPv6 address is eight groups (called hextets) of up to four hexadecimal digits, separated by colons. So 2001:0db8:0000:0000:0000:ff00:0042:8329 is the fully written form: eight groups, four hex digits each, seven colons between them. Each group is a 16-bit chunk, which is why the digits only run 0-9 and a-f (case does not matter), and why a single group can never exceed ffff.

Writing every zero out is tedious, so IPv6 allows one shortcut: a double colon :: stands in for one or more consecutive groups of all zeros. The address above compresses to 2001:db8::ff00:42:8329. The leading zeros inside each group drop too, so 0db8 becomes db8 and 0042 becomes 42.

The catch is the word one. You may use :: at most once in an address. If it appeared twice, the parser could not tell how many zero groups belong to each gap, so the address becomes ambiguous and therefore invalid. Hold on to three numbers and you can eyeball most problems yourself: eight groups, four hex digits per group, exactly one ::.

The failures this tool flags

The validator runs a browser-side parser that checks each entry against those rules and marks the bad ones with a reason. From the manifest, the specific failures it catches include:

Too many groups. Nine or more hextets means the address overflows IPv6's 128 bits, so it is rejected.
A double :: appearing twice. Two :: shorthands in one address are ambiguous, so the line fails.
A hextet over ffff. A group with five hex characters cannot fit in 16 bits and is flagged.
Non-hex characters. Letters past f — like the g in 2001:dbg::1 — are not valid hexadecimal, so the row is marked invalid with that reason.

Each failing line keeps its reason in the report, so you are not left guessing which rule it broke. As the FAQ puts it, a double :: appearing twice, a hextet over ffff, or too many groups shows up as invalid instead of quietly reaching your config.

A worked example

Say you paste this messy list pulled from a config review:

2001:db8::1
fe80::1ff:fe23:4567:890a
2001:db8::ff00:42:8329
2001:0db8:0000:0000:0000:0000:0000:0001
2001:dbg::1
2001:db8::1::2
2001:db8:1:2:3:4:5:6:7

Run it through the validator and you get a per-row report. Here is the gist of what comes back:

| Input | Valid | Reason | |---|---|---| | 2001:db8::1 | yes | OK | | fe80::1ff:fe23:4567:890a | yes | OK | | 2001:db8::ff00:42:8329 | yes | OK | | 2001:0db8:0000:0000:0000:0000:0000:0001 | yes | OK | | 2001:dbg::1 | no | non-hex character g | | 2001:db8::1::2 | no | more than one :: | | 2001:db8:1:2:3:4:5:6:7 | no | too many groups (9) |

Four rows pass, three fail, and each failure tells you precisely why. The first four are all legal — note that the fully expanded 2001:0db8:...:0001 and its compressed twin both validate, which is the whole point of zero compression. The bottom three break a different rule each: a bad hex letter, a second ::, and a ninth group.

Cleaning the list, not just judging it

Validation is the first step; the report is meant to be handed off. From the output you can keep unique rows only, preserve the invalid rows for review, and sort the normalized result. Then switch the format between plain lines, CSV, JSON, Markdown, SQL IN, and a TypeScript union, and download the exact artifact your next step needs — a CSV for a ticket system, a SQL IN clause for a query, or a JSON array for a script.

One habit worth keeping: text copied from a web page or PDF often carries hidden whitespace, so normalize before you deduplicate or import. And when you need an audit trail, download the CSV or Markdown with line numbers rather than copying only the final list.

The first time I used this on a real allowlist, the surprise was not the obvious typo — it was a row that looked perfect but carried a trailing zero-width space from a copied wiki table. The "valid" addresses deduped down by one because two visually identical entries were actually different strings. That single quiet diff would have left a stale rule behind in production.

Where it fits with the rest of the toolkit

This validator pairs well with the focused single-job tools. If you just need to pull addresses out of a wall of log text, start with the IPv6 Address Extractor and feed its output here. To collapse everything to one canonical written form, the IPv6 Address Normalizer handles the zero-compression and lowercasing. For trimming a list down to unique entries, reach for the IPv6 Address Deduplicator, and for reshaping the clean list into a snippet, the IPv6 Address List Converter covers the export formats.

A few practical guardrails. The tool is built for short working lists — a design doc or allocation sheet, rarely past a few thousand lines, validated instantly in the tab. A massive harvested address set should be split locally first. And remember that passing validation only means the string is well formed: it is not proof that the host, route, or resource on the other end actually exists.

Three rules carry almost all of IPv6 validation: eight groups, four hex digits each, one ::. The IPv6 Address List Validator enforces them on every row so a typo never slips into a config you trust.

Made by Toolora · Updated 2026-06-13