What the Recipe Library Contains
This tool returns ready-made regular expressions for six common kinds of data: email addresses, URLs, IPv4 addresses, phone numbers, hexadecimal colours and ISO dates. You search by name, copy the pattern, and adapt it.
The recipes are worth understanding as a set, because they share a design philosophy and therefore share a failure mode. Each one is written to find matches inside a larger body of text rather than to accept or reject a single field. None is anchored, several use deliberately permissive character classes, and none performs range or calendar validation. That makes them excellent for extraction and unreliable as validators, and this page documents exactly where each one needs hardening before it can guard anything.
When to Use These Recipes
Scanning unstructured documents. Pulling email addresses, URLs or IP addresses out of prose, log output or pasted email bodies is exactly what permissive, unanchored patterns are good at. You want recall at this stage and you will filter the candidates afterwards.
Redacting before you share. Finding candidate phone numbers or addresses so they can be replaced with placeholders is a place where over-matching is harmless and under-matching is a disclosure risk.
Getting a testable baseline fast. A pattern that over-matches is easier to tighten than an empty field is to fill, particularly for formats whose edge cases are well understood.
Comparing an implementation against a reference shape. When a specification says ISO date or hex colour, a conventional pattern gives reviewers something concrete to measure the code against.
Not for enforcement. If a match will decide whether a user may proceed — a sign-up form, an API boundary, a migration gate — a permissive recipe is the wrong basis. Tighten it first, and where the rule involves ranges or arithmetic, move the check into ordinary code.
How the Recipe Lookup Works
The lookup is a case-insensitive substring filter over a fixed library of six recipes. Typing em returns the email recipe; typing date returns the ISO date recipe; submitting nothing returns all six. Matching happens against the recipe name, not the pattern text, so searching for \d returns no results even though digits appear in several patterns — search by what the pattern is for, not by what it contains.
The six recipes and their exact bodies are: email [^@]+@[^@]+\.[^@]+, url https?://[^\s]+, ipv4 \b(?:\d{1,3}\.){3}\d{1,3}\b, phone \+?\d[\d\s\-()]{7,}, hex color #[0-9a-fA-F]{3,8}, and date iso \d{4}-\d{2}-\d{2}. Each is a pragmatic starting point rather than a validator, and the next section explains what that means for each one.
A note on scope, since it affects which of our tools you should reach for. This tool and
Regex Cheatsheet Search currently expose the same six recipes through the same lookup, so they will return identical results for identical queries. Treat this page as the reference for adapting a recipe to your own constraints, and if you only need to retrieve a pattern either page will do.
Tips and Common Mistakes: Hardening Each Recipe
Email. The recipe requires at least one character before and after the @, and at least one dot in the domain. It does not restrict which characters those may be, so it happily matches constructions with spaces, and it will report matches inside longer text because nothing is anchored. It also rejects quoted local parts, which are legal in the specification.
URL. The pattern requires a scheme and then consumes everything up to the next whitespace, greedily. On a line of prose that means it swallows trailing punctuation — a closing parenthesis or a full stop at the end of a sentence becomes part of the match. Strip trailing punctuation in code after matching, or tighten the class. It also will not match protocol-relative or bare-host forms, which is usually the right call but should be deliberate.
IPv4. This is the classic gap. \d{1,3} accepts one to three digits without constraining their value, so the recipe matches 999.999.999.999, which is not a valid address. If you need range-accurate validation, each octet must be expressed as an alternation covering 0-199, 200-249 and 250-255, which makes the pattern markedly longer — and is often better handled by parsing and testing each octet numerically.
Phone. The recipe is intentionally permissive: an optional leading plus, then a digit, then at least seven more characters drawn from digits, spaces, hyphens and parentheses. It will therefore match any long run of digits in unstructured text, including an order number or a timestamp. It carries no country semantics. Use it to find candidate phone numbers in a document, then normalise and validate separately — never as a sign-up gate.
Hex colour. The quantifier {3,8} accepts every length from three to eight, but the CSS syntax only defines four valid lengths: three, four, six and eight digits. The recipe therefore matches five- and seven-digit strings that no browser would honour. Pin the alternation to the legal lengths if correctness matters.
ISO date. The shape is enforced, the calendar is not. 2024-13-45 matches. Pair it with numeric range checks on the month and day, and decide explicitly whether you are willing to accept edge cases like 2024-02-30.
Using a Recipe
- Step 1 — Search by purpose. Type the kind of data you are looking for —
email, url, ipv4, phone, hex, date — into the input area. Submitting an empty query lists all six recipes so you can see the full set first. - Step 2 — Copy the pattern. The result is returned as a name and pattern pair. Copy the pattern body without the name prefix; the lookup output pairs them with a separator for readability.
- Step 3 — Test it against your own data. Paste the pattern into the Regex Tester along with real samples. This step is not optional — a recipe tested only against the examples on this page has not been tested against your data at all.
- Step 4 — Add anchors if you are validating. Every recipe here is written to find matches, so none is anchored. For field validation, wrap the pattern in
^ and $ so that extra characters around a valid value cause a rejection rather than a partial match. - Step 5 — Harden deliberately. Tighten the specific weakness documented above for the recipe you chose, rather than trusting the permissive default in a validation path.
Worked Example: Hardening the IPv4 Recipe
Suppose you are parsing server logs and need to pull out addresses. Search for ipv4 and you get \b(?:\d{1,3}\.){3}\d{1,3}\b. Read it as a sentence: a word boundary, then a non-capturing group matching one to three digits followed by a dot, repeated exactly three times, then one to three more digits, then a word boundary. The group is non-capturing because the repetition is the point and you do not want three redundant groups in the result.
Run it in the Regex Tester against 10.0.0.7 and 999.999.999.999. Both match. The recipe is behaving exactly as written — \d{1,3} limits how many digits an octet may contain, not which numbers it may represent — and for log parsing that is usually fine, because a four-part dotted string with octet-like widths is overwhelmingly likely to be an address.
Now suppose the same pattern is about to validate a form field. The identical behaviour is now a defect: 999.999.999.999 is not a valid address and must be rejected. Constraining each octet to 0–255 requires an alternation covering 0-199, 200-249 and 250-255, which turns a readable pattern into a dense one that reviewers will struggle to check.
The better answer is to change the tool rather than the pattern. Use the recipe to find candidate strings, then split on dots and test each octet numerically with a bounds check. A handful of lines of ordinary code is easier to review, impossible to get subtly wrong, and immune to the range-encoding bugs that plague hand-written octet alternations. That is the general lesson these six recipes illustrate: regex is excellent at finding structured text and a poor substitute for arithmetic or calendar logic.
Frequently Asked Questions
Why does searching for a pattern fragment return nothing?
Because the lookup filters recipe names rather than pattern contents. Search for hex or url, not for #[0-9a-f]. Only six named recipes exist, so a query that does not appear in any name returns no results.Is the IPv4 pattern safe for validating addresses?
No. It constrains the number of digits per octet but not their value, so it accepts addresses such as 999.999.999.999. It is a useful pattern for finding address-shaped strings; for validation, check each octet numerically between 0 and 255.Will the email pattern reject invalid addresses?
It rejects only the most obviously malformed shapes. Because the character classes are negations of @, it permits spaces and consecutive dots, and it is unanchored, so it will match an address embedded in a larger string. Treat a match as a lead, not as validation.How does this differ from Regex Cheatsheet Search?
Operationally it does not — both filter the same six recipes with the same lookup, so identical queries return identical results. This page documents what each recipe guarantees and where it needs hardening; that one is the quick retrieval route. If you need a wider set of patterns, neither tool has it.Related Tools
Whatever recipe you take from here should be confirmed in the
Regex Tester against your own data before it governs anything. To rewrite matched values rather than find them, the
Regex Replace Tester applies a substitution with a replacement template and reports the length change. For the individual tokens used inside these patterns, the
Regex Cheatsheet covers quantifiers, groups and character classes.
Privacy & Security
This tool runs entirely in your browser — no data ever leaves your device. There is no server round-trip, no upload, no logging, and no account required. Your input is processed locally using client-side JavaScript and is never stored, transmitted, or accessible to anyone else. When you close the tab, everything disappears.