How to Validate Domain Names in a Pasted List Without Guesswork

A domain list looks tidy until you try to use it. You paste a column from a CRM export, a blocklist someone copied out of a wiki, or a set of vendor URLs from a support ticket, and somewhere in those rows is a label with an underscore, a hostname with no dot, or a stray entry that is 70 characters long. Import it as-is and your script throws, your allowlist silently drops a vendor, or your outreach bounces. The Domain Name List Validator exists to catch those rows before they reach a real workflow, and to tell you exactly why each one failed.

This guide walks through what counts as a valid domain name, what this specific tool checks, and the one trap that no syntax checker can save you from: a perfectly well-formed domain that nobody has ever registered.

What makes a domain name syntactically valid

A domain name is a series of labels separated by dots. The rules are narrow and worth stating plainly, because most "broken" rows break one of them:

• Each label may contain only letters, digits, and hyphens.
• A label may not start or end with a hyphen.
• Each label is 1 to 63 characters long.
• The name must end in a top-level domain (TLD), so it needs at least one dot with a label after it.

Run a few examples through those rules and the failures jump out. -bad.com is invalid because its first label starts with a hyphen. justaword is invalid because it has no dot and therefore no TLD — it is a single label, not a domain. A label padded out to 70 characters is invalid because it blows past the 63-character ceiling. Meanwhile mail-server.example.com passes cleanly: three labels, each made of letters, digits, and an interior hyphen, all within length, ending in a real TLD.

That last example matters. A hyphen in the middle of a label is fine; it is only the leading or trailing position that is illegal. People delete legitimate rows by over-correcting on this, so it pays to know the exact rule rather than the vibe of one.

What this tool actually checks

The Domain Name List Validator runs entirely in your browser. It reads your input — pasted text, logs, a CSV export, copied HTML, a Markdown note, a support ticket, or a local text file loaded through the File API — and checks each candidate domain one row at a time against the rules above. Nothing is sent to a server.

For every row it emits a pass or fail with a short reason beside it. The FAQ on the tool page names the failure cases it calls out directly: a label over 63 characters, an illegal character such as the underscore in dom_ain.com, and a missing TLD such as localhost. Valid and invalid rows stay side by side in the output, which is the whole point — you fix the source list instead of guessing what broke.

You also get cleanup controls on top of validation. You can keep unique rows only, preserve invalid rows for review, and sort the normalized output. And you can switch the output format between plain lines, CSV, JSON, Markdown, a SQL IN clause, and a TypeScript union, then download the exact artifact you need. Sensitive profiles such as cards and JWTs mask their values in the output while still returning useful validation signals.

What it does not do is check the world. It validates shape, not existence — more on that below.

A worked example

Suppose you paste this list, pulled from a vendor spreadsheet that several people had edited:

mail-server.example.com
-bad.com
dom_ain.com
justaword
shop.acme.co.uk
thisisanabsurdlylongsinglelabelthatkeepsgoingwellpastsixtythreecharacters.com

A CSV report comes back with a reason on every row:

domain,valid,reason
mail-server.example.com,true,OK
-bad.com,false,label starts with a hyphen
dom_ain.com,false,illegal character in label
justaword,false,no TLD (needs a dot)
shop.acme.co.uk,true,OK
thisisanabsurdlylongsinglelabel...com,false,label exceeds 63 characters

Two rows pass: mail-server.example.com and shop.acme.co.uk (multi-part TLDs like .co.uk are fine — they are just more labels). Four rows fail, each for a different and specific reason. You can keep the invalid rows for review, or filter to unique valid rows and export straight to a SQL IN clause for an import script. Either way, you are working from a list whose every entry has been explained rather than a flat file you have to eyeball.

Why a valid domain may still be useless

Here is the line that trips up the most people: passing this validator means a domain is spelled like a domain, not that it exists. The check is purely about syntax. totally-made-up-domain-12345.com satisfies every label rule — letters, digits, interior hyphen, length, a real TLD — and the tool will mark it valid. Nobody has registered it. Nobody ever will, probably. Syntax-valid and registered are two different questions, and only the first one can be answered locally in your browser.

The tool's own guidance says this directly: do not treat domain validation as proof that the account, domain, or resource really exists. Registration, DNS resolution, MX records, and whether mail actually delivers are all separate checks that require querying live infrastructure. This validator is the cheap first pass — it strips out the rows that could never resolve no matter what, so your slower, network-bound checks only run against entries that are at least shaped correctly.

How I use it in a cleanup pass

When I inherit a domain list from someone else, I have learned not to trust how clean it looks. The last allowlist I touched had three rows that displayed identically but carried trailing whitespace copied out of a rendered web page, plus one entry with a smart-quote glued to the front that I never would have caught by reading. I pasted the whole thing in, turned on "keep unique rows only" and sort, and the failure column did the reading for me: two illegal-character rows, one missing-TLD row that turned out to be an internal hostname someone had pasted by mistake. I fixed the source, re-ran it, downloaded the CSV with reasons as an audit trail, and handed off a list I could actually defend. The habit I picked up: download the report, not just the final list, so there is a record of what was rejected and why.

Putting it together

Domain validation is a small, well-defined problem with rules that are easy to get slightly wrong by hand. Labels are letters, digits, and hyphens; no leading or trailing hyphen; 1 to 63 characters each; ending in a TLD. The Domain Name List Validator applies exactly those rules to every row of a pasted or uploaded list, locally, and hands back a pass/fail report with a reason on each line, in whatever format your next step needs.

Once the list is clean, the same browser-local toolkit can take it further. The Domain Name Normalizer settles casing and whitespace so two rows that should match actually do, and the URL Extractor pulls candidate hostnames out of messier source text before you ever validate. Run the cheap syntax pass first, then spend your network budget only on the rows that earned it.

---

Made by Toolora · Updated 2026-06-13