About Common Regex Patterns
Common Regex Patterns is a reference sheet for the regular expressions you reach for again and again when validating input. It lists ready-made patterns for nine everyday checks: email addresses, URLs, IPv4 addresses, phone numbers, ISO dates, hex colours, US zip codes, usernames and strong passwords. Each one is shown as a single line you can copy straight into your code.
The value of the list is that these patterns have already been through the usual trial and error. A hand-written email check is almost always too loose or too strict; the version here covers the ordinary cases — a local part, an @, a domain and a two-or-more-letter top level — without pretending to parse every address the specification allows. The same is true of the other eight: they are practical filters, not exhaustive validators.
Regular expressions are dense, and that is their cost as well as their power. The page is organised so each pattern sits next to a plain-English label telling you what it is for, which is the part that usually gets lost when a regex is copied out of a codebase with no context. If a pattern is not exactly what a field needs, it is far easier to adjust a working example than to build one from a blank line.
How to use Common Regex Patterns
- 1 Scan the list for the kind of input you are validating — email, URL, IP address and the rest.
- 2 Copy the pattern that matches your need.
- 3 Paste it into your validation logic and test it against a few real values.
Frequently asked questions
Can I use these patterns directly in my code?
Yes, they are ordinary regular expressions that work in JavaScript and most other engines. Test them against a few real and invalid values first, because a pattern that is right for one product may be too strict or too loose for another.
Are these patterns exhaustive validators?
No, they are practical filters. The email pattern, for instance, catches the ordinary address shape without implementing every rule in the specification. They are meant to reject obviously wrong input, not to certify that every accepted value is fully compliant.
Why does the email pattern look so unreadable?
Because regular expressions compress a lot of logic into few characters. The pattern is saying, in order: some word characters, an @, a domain made of word characters and dots, then a top-level domain of two or more letters. Reading it piece by piece rather than as a whole makes it clearer.
Can I modify a pattern for my own needs?
That is the usual next step. Change the length limits, the character class, or the anchors to suit the field you are building, and test against the values your users actually enter. A working example is a starting point, not a contract.
Free, online, and private
Free to use
Common Regex Patterns is completely free. There is no account to create, no login, and no hidden charge or usage limit.
Runs online in your browser
It is a free online tool that runs entirely in your browser. Nothing to download or install — open the page and start using it right away.
Your data stays private
All processing happens locally on your device. Your input is never uploaded, stored, or tracked, so it never leaves your browser.
How Common Regex Patterns behaves in detail
These are the specifics of this implementation — the exact ranges, defaults and fixed settings you are working with.
| Parameter | Value |
|---|---|
| Output | a fixed list of 9 named patterns returned as plain text, one line per entry, each written `Name: pattern` |
| Patterns included | Email, URL, IPv4, Phone, Date (YYYY-MM-DD), Hex color, Zip code (US), Username, Password (strong) |
| Order | the nine lines are emitted in the same sequence every run because they come from a hard-coded array literal |
| Input | none — the run function ignores its argument entirely, so the output is byte-identical no matter what, if anything, is typed into the box |
| Anchor style | each expression is written with ^ and $ so it matches a whole line rather than a substring |
| Password rule | the strong-password entry uses four lookaheads (lowercase, uppercase, digit, non-word) followed by .{8,} for a minimum length of 8 |
| Sample | none — live is false and the sample string is empty, so the page renders without a worked example |
Compiled from the implementation of this tool and checked against it by itoolnet.
What Common Regex Patterns does not do
Knowing the edges of a tool saves more time than another list of its features. These are the cases where it will not do what you might expect.
- This is a cheat sheet, not a tester. The text box on the page is not wired to the patterns and there is no engine behind them, so nothing on the page will tell you whether a given address or date actually matches one of the nine expressions — pressing the convert button only reprints the same nine lines.
- The list is fixed at nine entries and cannot be searched, filtered, extended or reordered. A pattern you need that is not among Email, URL, IPv4, Phone, Date, Hex color, Zip code, Username or Password is simply not here, and no custom expression can be added.
- The patterns are returned as raw source text with no explanation of the syntax. There is no breakdown of what each character class or quantifier does, no note on which flavour of regular expression they target, and no flags such as case-insensitivity or multiline are applied.
- Some of the entries are deliberately loose and nothing says so. The phone pattern accepts seven to twenty digits with optional spaces, dashes, dots and parentheses, so it will happily pass strings that are not valid phone numbers; the URL pattern is a generic scheme-and-host shape rather than a validator for any particular scheme.
Tested and documented by itoolnet, the team that builds and maintains this site.