Regex Recipes: Email, URL and Date Patterns

A dependable everyday email pattern is [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}. Read it in three parts: one or more characters allowed in the local part, then an @, then a domain of letters, digits, dots and hyphens ending in a dot and a two-plus-letter suffix. This accepts the addresses you actually encounter — including plus-tags like name+tag@example.com — without pretending to cover every exotic case the formal specification allows.

Resist the urge to be exhaustive. The official grammar for email is famously complex, and a pattern that tries to be perfect becomes unreadable and still rejects valid addresses. For validation, a reasonable pattern plus an actual confirmation email is far more reliable than any regex alone.

A practical URL pattern is https?://[\w.-]+(?:\.[\w.-]+)+[\w\-._~:/?#[\]@!$&'()*+,;=%]*. The https? makes the s optional; [\w.-]+ matches the host; the group requires at least one dot for a real domain; and the trailing class allows the path, query and fragment characters that appear in modern links. Anchor it with ^...$ if the whole string must be a URL, or leave it unanchored to find links inside a body of text.

As with email, exact URL grammar is vast. If you control the input — say, you only ever see http and https links — trim the pattern to match. The narrower the pattern, the fewer false positives, and the easier it is to read six months later.

For ISO dates, \d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01]) matches YYYY-MM-DD while restricting the month to 01–12 and the day to 01–31. It does not know that February has fewer days — regex counts characters, not calendars — so genuinely validating a date still needs a date library once the shape is confirmed. Capture the parts with groups if you want to reorder them, for example to turn 2026-08-22 into 22/08/2026 with a replacement of $3/$2/$1.

The broader lesson across all three recipes is the same: a regex confirms shape, not truth. It can tell you a string looks like an email, a URL or a date, but not that the mailbox exists, the link resolves or the date is real. Use regex as a fast first filter and reserve deeper checks for the values that pass it.

The address grammar in RFC 5322 permits quoted local parts, comments in parentheses, folding whitespace and nested structures; the well-known regex that implements it faithfully runs to several thousand characters and still does not check whether the domain exists. Meanwhile a strict-looking pattern rejects perfectly real addresses — new top-level domains longer than four letters, plus-addressing, and the apostrophes and hyphens common in Irish and Slavic surnames.

The honest design is therefore a loose shape check plus a real verification step. The HTML `type="email"` control uses a deliberately simple pattern — something before an `@`, something after it, no spaces — and every serious system confirms the address by sending mail to it. Treat the regex as a typo catcher that runs instantly in the browser, not as the authority on whether an address is valid.

Some of these recipes have a better tool sitting in the standard library. `new URL(string)` parses a URL properly, throws on malformed input and then hands you the protocol, host, port, path, query and hash as separate fields — no regex will ever match its accuracy on internationalised domains, IPv6 hosts or percent-encoded paths. Wrapping it in a `try/catch` is both shorter and more correct than any URL pattern you could write.

Dates are the clearest case of a pattern that cannot know enough. `^\d{4}-\d{2}-\d{2}$` happily accepts `2026-02-31` and `2026-13-01`, because month lengths and leap years are calendar facts rather than textual ones. Use the regex to extract the three numbers, then hand them to a date constructor and check that the result reads back the same values. Regex is excellent at finding and shaping text; correctness beyond shape belongs to a parser.