Validators Tools
Test and validate patterns, schemas, and data formats. Ensure your data meets required specifications.
A validator that only says "invalid" is half a tool. These validators parse the input properly and tell you what is wrong and where, covering regex, JSON schema, cron expressions, email, phone, credit card, URL, and IP formats.
14 tools availableRegex Tester
Test regex with syntax highlighting
XPath Tester
Test XPath with live match highlighting
JSON Schema Validator
Validate JSON against a schema
Cron Expression Validator
Parse and preview cron schedules
Email Validator
Validate email address format
Credit Card Validator
Validate credit card numbers using Luhn algorithm
Phone Number Validator
Validate international phone number formats
URL Validator
Validate URL format and structure
IP Address Validator
Validate IPv4 and IPv6 addresses
IBAN Validator
Validate IBANs with mod-97 checksum, 89 countries
File Hash Checker
Calculate and verify file checksums
Regex Builder
Visual regex builder with match highlighting and pattern library
Password Strength Tester
Entropy, 0–4 score, crack-time estimates, weak-pattern checks
Gherkin Validator
Validate Cucumber feature file syntax and structure
A validator is only as strict as the grammar it was handed
Every validator here answers a narrower question than its name suggests: whether a string matches a published grammar. It cannot say whether the value works, and separating those answers is the difference between a test that finds defects and one that generates noise.
Email: the address grammar is not a delivery rule
RFC 5322 defines a mailbox as a display name plus an address, or a bare address: a mailbox carries "an optional display name that indicates the name of the recipient ... and an addr-spec address enclosed in angle brackets". The grammar also permits quoted local parts and comments, so a validator that rejects a plus sign is stricter than the standard rather than safer. A syntactically perfect address can still be undeliverable, and only a real send proves anything about routing.
URLs, IP addresses and phone numbers each publish their alphabet
A URI scheme is restricted by grammar, not by a fixed allow-list: in RFC 3986 "scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )", and implementations may accept upper case "for the sake of robustness but should only produce lowercase scheme names for consistency". A validator that accepts only http and https is enforcing a policy, not the syntax. IP addresses have their own hard number: in RFC 4291 "IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces". A telephone URI builds the plus sign into the value - "global-number-digits = "+" *phonedigit DIGIT *phonedigit" - so stripping the plus changes the number instead of normalising it.
A pattern, a schema and a feature file test three different things
A regex tester evaluates a pattern against a string, a JSON Schema validator evaluates a document against a schema, and a Gherkin validator parses a feature file's structure. The first two are structural checks, and a structural pass is not a behavioural proof: JSON Schema describes a format for "describing the structure of JSON data", which says nothing about whether the values are right for your system.
Schedules, passwords and hashes: rules that carry numbers
A cron expression has a fixed field count and fixed ranges. POSIX describes an entry as "a text file consisting of lines of six fields each", where "The first five fields shall be integer patterns that specify the following: Minute [0,59] Hour [0,23] Day of the month [1,31] Month of the year [1,12] Day of the week ([0,6] with 0=Sunday)". A validator that accepts a seconds field is validating a different cron dialect, so an expression can be valid on one host and ignored on another. Passwords now have a rule with a direction: NIST SP 800-63B requires that verifiers "SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length", and then removes the old habit - "Other composition requirements for passwords SHALL NOT be imposed." A strength meter that rewards a symbol is scoring a rule the standard tells you to drop. Hashes close the set: a checksum comparison is only meaningful when both sides used the same algorithm.
| Check | Input | The rule the tool should apply | What it still cannot prove | Source |
|---|---|---|---|---|
| Email address | one string | the addr-spec grammar, display name optional | that the mailbox exists or accepts mail | RFC 5322 |
| URL | one string | scheme is ALPHA followed by letters, digits, plus, hyphen or dot | that the host resolves or answers | RFC 3986 |
| IP address | one string | IPv6 is a 128-bit identifier; IPv4 is 32 | that anything listens on that address | RFC 4291 |
| Cron expression | five time fields | minute 0-59, hour 0-23, day 1-31, month 1-12, weekday 0-6 | that the job runs, or runs on your host's dialect | POSIX crontab |
| Password | one string | single-factor minimum of 15 characters; no composition rules | that the account resists credential stuffing | NIST SP 800-63B |
| File hash | two digests | the same algorithm on both sides | that the file is free of malware | algorithm choice |
Pick the check that matches the claim: the Email Validator for addressing, the URL Validator and IP Address Validator for routing inputs, the Phone Number Validator for dialling strings, the Cron Expression Validator for schedules, the Password Strength Tester for credentials, the JSON Schema Validator and Regex Tester for structure, and the File Hash Checker for integrity.
Sources: RFC 5322, Internet Message Format, address specification; RFC 3986, URI Generic Syntax; RFC 4291, IP Version 6 Addressing Architecture; POSIX crontab, The Open Group Base Specifications Issue 8; NIST SP 800-63B, Digital Identity Guidelines, passwords.