Common Regex Patterns Library

What This Regex Pattern Library Covers and How to Use It

Almost every application validates the same handful of things: email addresses, phone numbers, URLs, IP addresses, dates, postcodes and password strength. Almost every developer writes those patterns again from memory, gets one character wrong, and finds out in production. This library collects tested patterns for those cases with a description, a sample string each one accepts, and a copy button. You can search by name, by description or by the pattern text itself, and filter by category such as web, network, phone or date. It is a reference rather than a tester, which is a different job from building a pattern from scratch and debugging it character by character. Each entry is written with a specific intent, and understanding the anchoring is the key to using them correctly. A pattern that begins with a caret and ends with a dollar sign must match the entire string, which is exactly what you want when validating one field: an email input either is a valid address or it is not. Remove those two anchors and the same pattern becomes a search expression that will happily find a match buried inside a longer document, which is what you want when extracting values from a log file. Choosing wrongly here is the single most common misuse, because an unanchored validation pattern will accept a string that merely contains something valid, letting an entire malicious payload through around it. Take the email case concretely. A pragmatic pattern anchors at both ends, allows one or more characters from a set of letters, digits, dots, plus signs and hyphens for the local part, requires a single at sign, then allows a domain of letters, digits and hyphens followed by at least one dot and a suffix. Test it against asha.nair+news at example.co.in and it matches, because the plus sign and the multi-part suffix are both permitted. Test it against a string with two at signs and it fails. Test it against the sentence please email me at asha@example.com today and an anchored pattern correctly refuses, because the whole string is not an address, while an unanchored one would match the middle. That third case is the one worth trying yourself. Where a library beats memory. A developer building a signup form takes the email and password patterns rather than inventing them, saving an hour of edge-case testing. Someone parsing an nginx access log grabs the IPv4 pattern to pull out client addresses. A team validating Indian mobile numbers starts from the phone pattern and adjusts it to require a leading digit between 6 and 9, which is a local rule no generic pattern knows about. A data analyst cleaning a spreadsheet uses the date pattern to find rows that do not follow the expected year-month-day format before importing. A reviewer checks a colleague pattern against the library version and spots a missing anchor. Two caveats worth stating. These are pragmatic patterns, not standards implementations: the email specification permits addresses so unusual that a fully compliant pattern is hundreds of characters long and rejects nothing useful in practice, so the sensible approach is a simple format check plus a confirmation email. Do not treat a regex pass as proof an address exists. The other point is escaping when you embed a pattern in code: inside a quoted string literal each backslash must itself be escaped, so a digit class written with one backslash in the pattern needs two in the string, and forgetting that produces a pattern that silently matches the wrong thing. Prefer a regex literal where your language offers one. Searching and copying happen entirely in your browser and nothing is sent anywhere.

🔥 Trending Tools