Pick the options, get the pattern
Choose email, phone or URL, set the options, and a matching validation pattern is built straight away. The pattern is compiled on the page and run against a list of sample values, so a table shows what passes and what fails before you copy anything. You can also drop in a value of your own, and a ready-to-paste JavaScript line is generated alongside the raw pattern.
There is no perfect email regular expression
Email syntax is defined by IETF RFC 5322, and a pattern covering comments and quoted local parts grows far too long to use in practice while still saying nothing about whether mail would arrive. So this tool builds a practical pattern for common shapes and spells out on the page where it misses or over-rejects: internationalised domains, new top-level domains and the plus alias. Checked October 2026.
Phone rules differ by country
Phone numbering depends on the country and the carrier, so there is no single right answer and the format is yours to pick: Korean mobile and landline, US NANP, E.164 international notation, or a digit count you set yourself, each with its own separator rule. Whatever you build, it checks notation only. It never tells you whether a number is in service, whether mail reaches an address, or whether a URL responds.
Frequently Asked Questions
Covering all of IETF RFC 5322 in a regular expression produces something too long to use in practice, and it still cannot say whether mail would arrive. This tool builds a practical pattern for common shapes and states its limits alongside.
Internationalised domain names have to be converted to Punycode, the form that starts with xn--, before the check. Converted names pass.
It checks notation only. It does not verify that mail reaches an address, that a number is in service, or that a URL responds.