Validators
Validators check whether a value, a file or a configuration is valid, and show exactly what is wrong and where. All 8 run in your browser and report the position of a fault rather than only its existence.
8 tools
- Color Contrast CheckerThe color contrast checker measures the WCAG ratio between two colours and shows live sample text at the exact size being tested, with each threshold marked.
- Credit Card ValidatorThe credit card validator checks a number against the Luhn algorithm and its brand prefix, entirely in your browser, so the digits are never sent anywhere.
- Email ValidatorThe email validator checks an address against the real syntax rules, and flags the typos that cost signups, such as gmial.com, before the address is accepted.
- IP Address ValidatorThe IP validator checks an IPv4 or IPv6 address, expands it to its full form, and names the reserved range it falls in, whether private, loopback or public.
- JSON ValidatorValidate JSON and see exactly where it breaks: line, column, the offending text and the likely cause.
- Regex TesterThe regex tester runs a regular expression against sample text with matches highlighted, every captured group listed, and a live preview of any replacement.
- URL ValidatorThe URL validator parses an address into its parts using the browser's own implementation, checks it against the real rules, and shows how it normalises.
- YAML LinterThe YAML linter catches the structural mistakes that break a file: tab characters, a missing space after a colon, and unquoted colons inside a plain value.
What the validators check
The 8 validators cover three kinds of check. Structure: whether JSON, YAML or a URL parses at all, and where it breaks if it does not. Format: whether a card number, an email address or an IP address is well formed according to the rules that define it. Rendering: whether a colour pair meets the WCAG contrast thresholds at a given text size.
Validating structure is not the same as validating meaning. A JSON document can parse cleanly and still be wrong for the API receiving it, and this page group checks the first thing rather than the second. Each tool states that limit on its own page.
Format checks say what they can and cannot prove. Passing the Luhn algorithm shows a card number is internally consistent, not that an account exists. A syntactically valid email address may still bounce. The validators report the check they performed rather than implying more.
What each validator can prove
Each of these answers a narrow question. Knowing which question keeps the result from being over-read.
| What you are checking | What the result proves |
|---|---|
| A JSON document | That it parses, with the line and column of any fault. Not that the keys suit your API |
| A YAML file | That the structure holds, catching tabs and missing spaces after a colon |
| A card number | That the Luhn checksum and length are consistent. Not that the account exists |
| An email address | That the syntax is valid, and flags typos such as a domain one letter from gmail.com |
| An IP address | That it is a valid IPv4 or IPv6 address, and which reserved range it falls in |
| A colour pair | The exact WCAG contrast ratio and which thresholds it clears at that text size |
Frequently asked questions
Does a valid JSON document mean my API will accept it?
No. Validating JSON proves the syntax parses. It says nothing about whether the keys, types or values match what the receiving service expects. A document can be perfectly valid JSON and still be rejected for missing a required field, or for giving a number where a string was wanted. Schema validation is the separate check that answers that.
Is it safe to type a real card number into the validator?
The arithmetic runs entirely in the page and makes no network request, so the number is not transmitted. Even so, prefer a published test number when you only want to see how the check behaves, since there is no reason to put a live credential into any web page.
Why does the email validator accept an address that bounces?
Because syntax and delivery are separate questions. The validator checks the address against the rules that define a valid address, and flags likely typos. Whether a mailbox exists can only be settled by sending to it, which no page can do on your behalf.
What contrast ratio do I actually need to pass?
WCAG AA needs 4.5 to 1 for body text and 3 to 1 for large text, which means 18.66px bold or 24px regular and above. AAA needs 7 to 1 and 4.5 to 1 respectively. The contrast checker marks each threshold against the exact ratio rather than giving a single pass or fail.