Quick answer
Playxoft's free Regex Pattern Library collects 25 regular expressions developers reach for most often, from email and URL validation to UUIDs, IP addresses, dates and postcodes. Every pattern has its own page with a token-by-token explanation, a table of strings it accepts and rejects that is verified by automated tests, the caveats that matter, ready-to-use code for JavaScript, Python, Go, C# and PHP, and a live tester pre-filled with examples.
- 25 tested patterns
- Search and filter
- Explained token by token
- Code in 5 languages
How to use the regex pattern library
- 1Type what you want to validate (email, IPv4, date…) into Search patterns, or pick a category.
- 2Open a pattern to see how it works, which strings it accepts and rejects, and its known limits.
- 3Copy the pattern, or the snippet for your language from the code section of its page.
- 4Edit the sample text in the tester on that page to try your own values before you ship.
Which regex should I use for common validations?
Pick the page for the data you are checking. Each one explains the trade-offs it makes, such as accepting plus-addressed emails or rejecting IPv4 octets with leading zeros.
| Category | Patterns |
|---|---|
| Web and URLs | URL (http and https), Domain name, URL slug, HTML tag, YouTube URL, JSON Web Token |
| Contact details | Email address, Phone number (E.164), Username, Strong password |
| Network | IPv4 address, IPv6 address, MAC address |
| Dates and times | Date (yyyy-mm-dd), Time (24-hour) |
| IDs and codes | UUID, Semantic version, Hex color, Credit card number, US ZIP code, UK postcode, India PIN code |
| Text and input | Leading and trailing whitespace, Numbers only (digits), Alphanumeric |
Every pattern is written for JavaScript's engine and translated for the other languages on its page. Where an engine cannot express a construct (Go has no lookarounds or backreferences, for example), the page says so and shows the workaround.
How were these regex patterns tested?
Each page has a table of inputs with the expected result and the reason, for example jane..doe@example.com → no match, because two dots in a row are not allowed. Those tables are not just documentation: our automated test suite runs every row against its pattern before each release, so a pattern change that breaks a row is caught before it reaches the site.
The examples deliberately include the edge cases that break home-made patterns: leading zeros in IP addresses, the Mastercard 2-series, February 31st, apostrophes in email addresses, and Unicode digits that some engines treat as numbers. Where a pattern accepts something that is still wrong (an impossible date, a card number with a bad checksum), the table shows it as a match and the page explains the extra check you need.
When should you not use a regex for validation?
A regex checks the shape of a string. Some questions need more than shape:
- Does this email address exist? Send a confirmation link. See the email pattern for why RFC 5322 regexes are a trap.
- Is this a real calendar date? Parse it: February 31st has the right shape. See dates.
- Is this phone number valid in its country? Use libphonenumber, then store E.164. See phone numbers.
- Is this URL safe to fetch? Parse it with the URL API and block private addresses. See URLs.
- What is inside this HTML? Use DOMParser, not regex. See HTML tags.
Use the regex for fast, friendly feedback in the form, and the parser or a real-world check for the decision.
Frequently asked questions
Last updated by the Playxoft engineering team.