What Regex Cheatsheet Search Does
Regex Cheatsheet Search is a lookup for ready-made patterns. Instead of building an expression from syntax tokens, you name the kind of data you are looking for and get back a working pattern you can copy into your code.
This is the right tool at the moment when you know what you need to match but not how to express it, and when the shape in question is common enough that someone has already worked out the trade-offs. The library holds six recipes covering the data types that dominate real validation code: email addresses, URLs, IPv4 addresses, phone numbers, hexadecimal colours and ISO dates.
Be clear about the level of the tool. This is not a syntax reference — that is the
Regex Cheatsheet, which lists quantifiers, groups and character classes. This is a catalogue of finished patterns, and its most valuable property is also its most dangerous one: every recipe is deliberately permissive, because it is built to
find matches in text rather than to accept or reject a form field.
How the Search Works
The mechanism is deliberately simple and worth knowing precisely, because it explains nearly every surprising result.
Your query is lowercased and trimmed, then compared against each recipe's name as a case-insensitive substring test. A query is a match if the recipe name contains it anywhere — so em returns the email recipe, date returns the ISO date recipe, and url returns the URL recipe. Submitting an empty query returns all six recipes, which is the intended way to browse the catalogue.
Two consequences follow directly. First, matching is against names, not pattern contents. Searching for \d or # returns nothing, even though digits and hashes appear inside several of the patterns, because those characters are not part of any recipe name. Search by purpose. Second, because the filter is a plain substring test with no fuzzy matching, approximate queries fail rather than degrade — emails matches only if a recipe name contains that exact sequence, so the singular forms are what you want.
Results are returned as a name-and-pattern pair. When nothing matches, the output says so explicitly rather than returning an empty panel, which makes a zero-result search easy to distinguish from a failed one. Because the catalogue is fixed at six entries, a no-match result is a reliable signal that the pattern you need is outside this library rather than a hint to reword your query.
One practical note:
Regex Library currently exposes the same six recipes through the same lookup, so the two tools return identical results for identical queries. Treat them as one catalogue reached by two routes.
Using the Search
- Step 1 — Enter a query in the input area. Type the kind of data you are looking for —
email, url, ipv4, phone, hex or date. Partial words work, since the test is a substring match. - Step 2 — Or submit empty to browse. Leaving the input blank returns the complete six-recipe catalogue, which is the fastest way to see whether the library covers what you need before you start typing.
- Step 3 — Read the result as a name and pattern pair. The output pairs the recipe name with its pattern, separated for readability. Copy the pattern body only; the name is a label, not part of the expression.
- Step 4 — Test against real samples before trusting it. Paste the pattern into the Regex Tester with input that includes both values that should match and values that should not. Every recipe here is intended for finding, so a pattern can look perfect and still be far too permissive for your use case.
- Step 5 — Anchor it if you are validating a field. None of the recipes is anchored. Wrapping the pattern in
^ and $ converts a finder into something that rejects input with extra characters around a valid value.
Common Use Cases
Adding a quick validation check. When you need an email or URL check today and want a reasonable starting point rather than a blank field, a recipe gets you something testable in seconds — provided you harden it before it gates anything.
Scraping and log mining. Pulling email addresses, URLs or IP addresses out of unstructured text is precisely what these loose patterns are good at, because you want recall rather than precision and you will filter the results afterwards.
Sanitising data before sharing. Finding candidate phone numbers or email addresses so they can be replaced with placeholders is a common and appropriate use of a permissive finder.
Starting a pattern you will then tighten. A working baseline that over-matches is easier to restrict than an empty field is to fill, particularly for address and date formats where the failure modes are well known.
Checking a requirement against a reference implementation. When a ticket specifies ISO dates or hex colours, the recipe shows the conventional shape and gives the reviewer something concrete to compare against.
Worked Example
Suppose you need to find IPv4 addresses in a log excerpt. Enter ipv4 and the search returns the recipe \b(?:\d{1,3}\.){3}\d{1,3}\b. Reading it: a word boundary, then a non-capturing group repeated exactly three times that matches one to three digits followed by a literal dot, then one to three digits, then a word boundary. The non-capturing group is the right choice here, since the repetition is what matters and you do not want three separate capture groups cluttering the result.
Now test it in the Regex Tester against 10.0.0.7 and 999.999.999.999. Both are reported as matches. That is the recipe behaving exactly as written — \d{1,3} constrains how many digits an octet has, not what number it represents — but it is almost certainly not what you want if you are validating addresses rather than finding them.
The fix is to constrain each octet to 0–255. A range-accurate octet is normally written as an alternation over 0-199, 200-249 and 250-255, which makes the pattern noticeably longer and harder to read. For most codebases the better answer is to use the recipe for discovery and then split on dots and validate each part numerically — a few lines of ordinary code, easier to review, and impossible to get subtly wrong. That trade-off is the general lesson: regex is excellent at finding structured text and a poor substitute for arithmetic.
Tips and Common Mistakes
- Search by purpose, not by symbol. The filter matches recipe names, so
email works and @ does not. - Assume over-matching. These patterns are finders. The email recipe permits spaces, the phone recipe matches any long digit run, and every one of them matches inside larger strings because none is anchored.
- Anchor before validating. Add
^ and $ when a pattern is going to decide whether a field is acceptable. - Do not use the IPv4 recipe as a validator. It accepts octets above 255. Use it to find addresses, then check the octets numerically.
- Prefer numeric checks to clever regex. Ranges, calendar validity and check digits are all easier and clearer in ordinary code than in a pattern.
- Do not read the recipes as specifications. They are pragmatic approximations of formats that are broader and messier than any single pattern captures — which is why strict email validation by regex is a well-known dead end.
- Remember the catalogue is small. Six recipes is a starting point, not a library. For anything else, build the pattern and verify it in the tester.
Frequently Asked Questions
Why did my search return no results when I searched for a pattern fragment?
Because matching is against recipe names, not pattern contents. Search for the kind of data — email, url, phone — rather than symbols or fragments that appear inside the patterns.How many patterns are in the library?
Six: email, URL, IPv4 address, phone number, hexadecimal colour and ISO date. Submitting an empty query lists all of them, which is the quickest way to confirm whether the library covers your case.Can I trust a recipe for form validation?
Not as-is. Every recipe is written to find matches rather than to reject invalid input, so all of them over-match. Anchor the pattern and tighten it for your specific constraints — and for anything involving ranges or arithmetic, validate in code instead of in the pattern.Does the email recipe match every valid address?
No. It rejects quoted local parts, which the specification permits, and it accepts some shapes that are not deliverable, including consecutive dots and embedded spaces. Treat it as a rough filter that catches obvious mistakes, and confirm actual addresses by sending mail to them.How is this different from the Regex Cheatsheet?
The Regex Cheatsheet lists syntax — quantifiers, groups, character classes and their meanings. This tool returns complete patterns for specific kinds of data. One teaches the vocabulary, the other hands you a finished sentence.Is Regex Library a different set of patterns?
No. It exposes the same six recipes through the same lookup, so identical queries return identical results. The pages differ in what they document about the recipes, not in what the tools return.Related Tools
Run any recipe you take from here through the
Regex Tester against real samples before it decides anything, and if you need to rewrite matched values rather than find them, the
Regex Replace Tester applies a substitution and reports the size change. To understand the tokens inside a recipe — the non-capturing groups and bounded quantifiers in the IPv4 pattern, for instance — the
Regex Cheatsheet is the reference, and the
Regex Explainer will inventory any pattern you paste.
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.