Regex Cheat Sheet with Examples

This cheat sheet is meant to help you move from “I know roughly what I want” to “I have a pattern I can test.” The examples are practical, readable starting points for common developer tasks. They are not magic. Real-world validation still needs sample data, edge-case testing, and a little judgment about whether regex is the right tool for the job.

A useful cheat sheet does two things at once. It gives you a pattern you can copy quickly, and it reminds you what the pattern is really doing. That is why each example below includes context about where it works well, where it can be too broad, and when you should reach for the Regex Tester or the Regex Generator instead of starting from scratch.

Think of the list as a working reference rather than a final spec. If you are validating a login form, a CSV import, or a settings field, the pattern is only the first pass. After that, test the result against real inputs, confirm the failure cases, and trim the regex until it is just strict enough for the job.

Common examples at a glance

Email, URL, and password patterns

Email and URL patterns tend to look more complicated than they first appear because both formats allow optional parts and punctuation. A practical approach is to begin with a pattern that covers the majority of normal inputs, then tighten it if your application needs more control. The email example above is deliberately readable, which makes it useful for forms, demo apps, and small utilities. The URL example is similarly lightweight and works well for common HTTP and HTTPS links.

Password rules are different because they are not about one format. They are about policy. That means the regex usually checks for at least one required character class and a minimum length, while the final policy also lives in product decisions, UX text, and backend checks. A cheat sheet can give you the skeleton, but the actual rule should still reflect the user experience you want.

Username, phone, and date patterns

Username rules are often tighter than people expect. Once you limit the allowed characters and length range, the pattern becomes simple. Phone numbers are trickier because formatting varies between countries and systems, so the example is intentionally broad. It is good for intake forms and scratch work, but production systems may need a country-aware parser or more specific normalization rules.

Dates are deceptively simple. The pattern above only checks shape, not calendar correctness. It will accept values like `2026-13-99`, which are not real dates. That is a reminder that regex is good at structure, not always at full semantic validation. If you need real date logic, use a parser or a date library after the basic shape check passes.

IPv4, IPv6, hex color, and HTML tag patterns

IP address patterns are useful because they show how regex can enforce numeric ranges and repeated separators. The IPv4 example includes range checks that stop obvious invalid octets from passing. The IPv6 example is intentionally simpler because full IPv6 validation quickly becomes complex, especially once compressed shorthand like `::` is allowed. For full coverage, use a dedicated parser or library rather than inflating the regex until it becomes unreadable.

The HTML tag example deserves extra caution. Regex can match a controlled snippet, but it should not be used as a general HTML parser. That pattern is only appropriate when you are dealing with highly constrained input and understand the risk. If the content is untrusted or complex, use a parser instead of forcing regex into a job it is not designed for.

Time and credit-card shape examples

Two more patterns come up often in practical work. Time values usually need a shape check before you parse them into scheduling logic. A common 24-hour example is /^(?:[01]\d|2[0-3]):[0-5]\d$/, which accepts values such as 09:45 and 23:59. Credit-card examples are different because they should only be treated as lightweight validation examples, not as payment security. A simple card-shape regex like /^\d{4}(?:[ -]?\d{4}){3}$/ can check formatting, but real payment handling still belongs to PCI-aware tooling and a payment provider.

These examples are useful because they reinforce a core cheat-sheet lesson: regex can confirm the visible shape of a value, but it usually should not be the final authority on meaning or trust. Use the time pattern before parser-based date logic. Use the card-shape example only to clean up obvious entry mistakes before the actual payment flow takes over.

JavaScript example

In JavaScript, you can keep the cheat sheet in a small object and test each pattern against sample strings. That makes it easy to compare a few different formats without rewriting the code every time. It also makes your learning loop faster because you can swap values in and out while preserving the pattern itself.

const patterns = {
  email: /^[^\s@]+@[^\s@]+\.[^\s@]+$/,
  ipv4: /^(?:25[0-5]|2[0-4]\d|1?\d?\d)(?:\.(?:25[0-5]|2[0-4]\d|1?\d?\d)){3}$/
};

console.log(patterns.email.test("student@example.com")); // true
console.log(patterns.ipv4.test("192.168.1.25")); // true

That approach is useful when you are learning because it keeps the focus on behavior rather than on syntax trivia. If the pattern fails, you can use the Regex Tester to inspect the mismatch and then compare the result with the cheat sheet version.

Python example

Python’s `re` module makes the same workflow easy. The main difference is usually whether you use `match`, `search`, or `fullmatch`. For validation examples, `fullmatch` is often the most useful because it checks the whole string instead of only part of it. That keeps the cheat sheet examples honest when you are applying them to forms or scripts.

import re

email = r"^[^\s@]+@[^\s@]+\.[^\s@]+$"
phone = r"^\+?[0-9()\-\s]{7,20}$"

print(bool(re.fullmatch(email, "student@example.com")))  # True
print(bool(re.fullmatch(phone, "+1 (555) 123-4567")))  # True

Python is also a good place to remember that a regex is still only a piece of the solution. If the format is critical, use regex as a first filter and then apply the domain logic that actually knows what a valid value looks like.

How to adapt a cheat-sheet pattern safely

The safest way to customize a copied pattern is to change one constraint at a time. If the username template should allow hyphens, add the hyphen and retest. If the password policy needs a symbol, add the symbol rule and retest. If the URL rule should only allow HTTPS, tighten the protocol branch and retest. Small, deliberate changes are easier to verify than a large rewrite that mixes several requirements at once.

It also helps to keep a short list of negative samples next to the positive ones. For example, an email regex should reject spaces and missing domains. A phone regex should reject obviously too-short values. An IPv4 regex should reject octets above 255. This is where the Regex Tester and Regex Generator complement the cheat sheet well: one gives you the starting pattern and the other proves whether your edits still do the right thing.

How flags change common cheat-sheet patterns

Flags are easy to forget when you copy a pattern from a reference page into code. A hex-color regex may need the ignore-case flag if you only wrote lowercase letters in the class. A multiline log-search pattern may suddenly start matching more than expected if you add m. A replacement workflow may need the global flag in JavaScript to catch every instance, not just the first one. The regex itself does not tell the whole story unless you also know how it is being executed.

That is why the best cheat-sheet workflow is copy, test, then integrate. Use the Regex Tester to try the expression with and without the relevant flags before you commit it to a frontend form, a Python script, or an automation rule. That takes a minute and saves much longer debugging later.

Best practices

Keep cheat-sheet patterns as readable as possible. If a pattern becomes hard to explain out loud, it is usually too clever. Favor explicit character classes, clear anchors, and short comments in your codebase when the intent is not obvious. The goal is for a teammate, future you, or a code reviewer to understand what the regex is trying to protect.

It is also smart to treat cheat-sheet examples as version zero, not version final. Start broad enough to be useful, then narrow the pattern only where the product requires it. That balance helps you avoid both false positives and overfitting. The easiest way to maintain that balance is to keep the Regex Generator and Regex Tester close at hand while you refine the rule.

Performance and security notes

Performance problems usually come from patterns that are more complicated than the input deserves. A cheat-sheet pattern should not become a mini parser unless the task truly needs it. If you notice a pattern getting harder to read as you add more exceptions, step back and ask whether a parser, library, or separate validation step would be safer and easier to maintain.

Security matters because regex often runs on data that comes from users or external systems. A permissive pattern can accept malformed values, and a very expensive pattern can make a service slower than expected on large inputs. Use regex for pattern checking, not as the only trust boundary. That is especially true for HTML, URLs, and passwords, where the surrounding application rules matter just as much as the expression itself.

FAQ

Related articles

Related tools

Next learning resources