What Validators Catch, and What They Miss

A green tick from a validator feels like approval, and that feeling is where the trouble starts. A validator answers one narrow question: does this text follow the rules of its format? Plenty of expensive mistakes sit outside that question: an email address that looks perfect and bounces, a link that is well formed and leads to a deleted page, a price field that parses as a number and is wrong. This guide explains what format checkers do find, how to read what they report, and which checks need a different tool or a human.

Three different questions

When someone says data is valid, they can mean three different things.

1. Is it well formed? Are the braces matched, the quotes closed and the tags nested? This is syntax.
2. Does it follow the rules of the format? Are required fields present, are the types right, does the number pass its checksum? This is validity.
3. Is it true and useful? Does the mailbox exist, is the page online, is the discount sensible? No checker can answer this from the text alone.

The validators on this site cover the first two, and each page says where it stops.

• The JSON Validator checks strict JSON syntax. The JSON Schema Validator then checks the same data against a schema, including types, required properties and allowed values.
• The XML Validator checks that a document is well-formed: matching tags, quoted attributes, one root element and valid entities. It does not check the document against a DTD or XSD schema.
• The HTML Validator is a fast syntax checker for nesting, closing tags, duplicate ids, unclosed quotes and comments, missing alt text, doctype, title and lang. It is not a full W3C conformance validator, and it does not flag end tags that the HTML specification lets you leave out.
• The CSS Validator parses braces, strings, comments and at-rules itself, then asks your own browser's CSS engine to judge properties, values and selectors.

How to read validator errors

Validators are more useful when you read them in the right order.

• Start with the first error. One unclosed tag or missing brace can cause a string of later messages. Fix the first, run the check again, and most of the rest often disappear. The JSON Validator reports only the first error, so a file with three mistakes needs three passes.
• The position is where the parser noticed. A missing closing quote is often reported at the end of the line or a few lines later. Look above the reported spot.
• Separate errors from warnings. The HTML and CSS reports list line and column, a type and a message. An error means the code is wrong. A warning, such as a missing alt attribute or an obsolete element, asks you to decide.
• Unsupported is not always wrong. The CSS Validator relies on your browser, so a very new or vendor-specific feature your browser lacks is reported as unsupported. Try a current browser before rewriting correct code.
• Schema errors name a path and a rule. A message such as Missing required property or Must be of type number points at the exact field and tells you which rule it broke.

What a format check cannot know

Email addresses

The Email Validator checks length limits (254 characters in total, 64 before the @), dots, domain labels and the shape of the ending. It also suggests a fix for a likely typo: sam@gmial.com is well formed, and the tool asks whether you meant gmail.com. It cannot confirm the mailbox exists, and its result says so. The only reliable proof that a person can receive mail at an address is to send a confirmation link and have them click it.

URLs

The URL Validator uses the browser's own URL parser to check the scheme, host and spacing, and it breaks the address into scheme, host, path, query and fragment. It never requests the page. It accepts https://example.invalid/nope as well formed, although the .invalid ending is reserved so that it never resolves. To learn whether a page is alive, the Server Status Checker requests the URL from our server and reports the status code and response time, and the Redirect Checker lists each hop. The guide to reading DNS, status codes and redirects explains the results.

Numbers and dates

A card number that passes the Luhn checksum in the Credit Card Validator has the right format, but the tool never contacts a bank, so it cannot say the card exists. The Date Validator knows leap years and month lengths, and it reports 02/29/2025 as not a real date. It marks 03/04/2026 as ambiguous because March 4 and April 3 are both real. A real date can still be the wrong one.

Business rules

A quantity of minus five is a perfectly valid JSON number. A schema can add a minimum or an allowed list, but rules that compare one field with another, such as an end date that must follow a start date, generally need code in your application. Nor does a clean HTML check prove a page is accessible or fast. It only shows that the markup is structurally sound.

Why a regex is not an email validator

Developers often reach for a regular expression. A short pattern, such as some characters, an @, some characters, a dot and some characters, is easy to write and wrong in both directions. It accepts john..doe@example.com and a@b.c, and a stricter pattern written from memory tends to reject real addresses that contain a plus sign, a long ending or several subdomains.

The full email grammar allows quoted local parts and comments, so a regex that matches all of it is enormous and hard to maintain. The HTML specification itself uses a deliberately simplified pattern for email inputs that differs from the full standard. Even a perfect pattern would only prove the text is shaped like an address.

A better approach is a light sanity check (one @, no spaces, a dot in the domain), followed by a confirmation email. If you keep your own pattern, test it on a list of valid and invalid addresses in the Regex Tester before it reaches production.

A workflow before you deploy

1. Validate syntax first, starting with data files, then markup, then styles.
2. Check structure with a schema for JSON payloads, so wrong types and missing fields surface early.
3. Validate identifiers that go into configuration, such as IP addresses for an allow-list in the IP Address Validator.
4. Check reality by requesting the URLs and sending a real test email to an inbox you own.
5. Minify last, then validate and test the minified copy. The minifying guide explains how.