Domain Name Validator (RFC Compliance Check)

Check whether a domain name complies with the RFC 1035/1123 syntax rules. Validates label length, total length, allowed characters, and hyphen placement individually, showing the specific reason for any violation.

Last updated: 2026-09-20

What Is the Domain Name Validator?

The domain name validator breaks down whether an input string complies with the domain name syntax rules defined in RFC 1035 (published in 1987) and RFC 1123 (published in 1989), checking each rule individually rather than returning a single "valid or invalid" verdict. Because it shows exactly which rule was violated and, where relevant, which label (the parts of a domain separated by dots) caused the failure, it is especially useful when you already know a domain string is being rejected somewhere but do not know why.

It is important to understand what this tool does not do: it only checks syntax, meaning the shape of the string as text. It does not query DNS to confirm the domain is actually registered, does not check whether a website is running at that address, and does not tell you whether the name is available to register. That makes it well suited for confirming that a candidate name for a new domain, or a hostname you are building into a configuration file, is syntactically well-formed before you take the extra step of registering it or deploying it.

How to Use the Domain Name Validator

Enter a domain name Type the domain name you want to check into the input field (for example, example.com). Remove any leading protocol such as `https://` or trailing path such as `/path` first, so that only the domain portion remains.
Review the validation result As soon as you type, six rules are evaluated in real time and each one is labeled Pass, Fail, or Note.
Read the reason for any failure Every row marked Fail includes a specific reason, such as the offending label or its character count, so you can see exactly which part of the string needs to change.
Try the sample buttons to see edge cases The Valid example and Invalid example buttons fill the field with sample strings that sit right at the rule boundaries, letting you quickly see how each rule behaves.

Tips for getting more out of it

This tool validates against the syntax rules defined in RFC 1035/1123; it does not check whether the domain is actually registered or resolvable via DNS.
Before writing your own validation regex for a form, try this tool on the edge cases (exactly 63 characters, hyphen placement, etc.) to make sure your implementation covers them.
Input containing non-ASCII characters, such as Japanese domain names, only skips the character-set check. Convert it to `xn--` notation with the Punycode converter first for a fully accurate check.
An all-numeric TLD almost never happens in practice, but it is included intentionally to catch inputs that could be confused with an IP address during form validation.
The same rule set can be applied to the part of an email address after the `@` sign, so it also doubles as a lightweight email domain check.

When to Use This Tool

Sanity-check a form validation regex before shipping it

Before you write your own regular expression to validate a domain input field, run edge cases through this tool first — a label that is exactly 63 characters, a hyphen at the very start or end — so you can catch gaps in your implementation early.

Pre-check a candidate name for a new domain

When you are deciding on a name for a new service or a subdomain, you can confirm it is syntactically sound before you even search for it at a registrar.

Spot-check the domain portion of an email address

Because the part of an email address after the @ sign generally follows the same hostname rules, this tool doubles as a lightweight secondary check for email validation logic.

Investigate why a string was rejected

If a system flags a string as "not a valid domain name" and it is not obvious why, paste it in here to pinpoint exactly which rule it fails.

Glossary

Label: One of the segments of a domain name that is separated by dots. In www.example.com there are three labels: "www", "example", and "com". RFC 1035 sets its length and character restrictions at the label level, not the domain as a whole.
TLD (Top-Level Domain): The rightmost label of a domain name, such as .com or .jp. It sits at the top of the DNS hierarchy, directly under the invisible root.
FQDN (Fully Qualified Domain Name): A domain name written out completely from the hostname down to the TLD, with no part omitted. Strictly speaking, an FQDN ends with a trailing dot representing the DNS root (e.g. example.com.), though that trailing dot is usually dropped in everyday use.
IDN (Internationalized Domain Name): A domain name that contains non-ASCII characters, such as Japanese, Chinese, or Arabic script. Because DNS itself can only handle ASCII characters, an IDN is converted to Punycode before it is actually registered or resolved.
Punycode: An encoding scheme that converts the non-ASCII portion of an IDN into an ASCII string that DNS can handle, prefixed with xn--. Browsers typically convert it back to the original characters for display in the address bar.
Wire format: The binary format in which DNS queries and responses are actually exchanged over the network. Each label is preceded by a single byte indicating its length, and that byte can only represent values from 0 to 63 — the technical origin of the 63-character label limit.
Hostname: A name used to identify a device on a network. It is a specific kind of domain name, and RFC 1123 restricts the characters a hostname may use to letters, digits, and hyphens only — the exact rule set this tool checks against.

FAQ

Per RFC 1035, each label (the part between dots) can be 1-63 characters, and the total domain can be up to 253 characters (derived from the 255-octet limit in the wire format). Note that registries may impose additional restrictions on top of these limits.

Under RFC 1035/1123, only letters, digits, and hyphens are allowed in a hostname; underscores are not permitted. However, underscores do appear in non-hostname DNS labels, such as TXT or SRV records (e.g. `_dmarc.example.com`).

RFC 1123 requires each label to start and end with an alphanumeric character. Allowing a hyphen at the start or end would make parsing ambiguous and risks compatibility issues with older DNS implementations.

Internationalized domain names (IDNs) containing characters like Japanese must be converted to Punycode (ASCII notation starting with `xn--`) before being registered in DNS. Because this tool is designed to validate the Punycode-converted string, convert a non-ASCII domain with the Punycode converter first, then run the syntax check here.

Side Note — Why domain name validation keeps getting reinvented

Domain name syntax checking looks like it should be a single simple regular expression, yet it is an area where many developers have stumbled with their own implementations. From email validation in forms, to hostname parsing in config files, to URL validation in APIs, "domain-like strings" show up everywhere, but implementations that accurately reflect the official rules in RFC 1035 (1987) and RFC 1123 (1989) are surprisingly rare.

The two-tier length limit — 63 characters per label, 253 characters total — comes directly from the design of the DNS wire format (the binary format actually exchanged over the network). Each label is prefixed with a single length byte, and that byte is restricted to 0-63 (the maximum value representable in 6 bits), which is the direct reason for the label-length limit.

The convention that a TLD should not be all-numeric has an interesting history of its own. It is not a rule mandated by any RFC, but rather implementation wisdom widely adopted to distinguish domain names from IPv4 addresses (sequences of digits and dots). Many DNS resolvers and browsers use this convention to decide that a string like 192.168.1.1 should be treated as an IP address rather than a domain name.

Browse all trivia