There's a well-known joke: you have a problem, you decide to use a regular expression, and now you have two problems.

It's funny because regex looks like a cat walked across the keyboard. ^(?:[a-z0-9]+-)*[a-z0-9]+$ isn't exactly friendly. But here's the secret most tutorials bury: the regex you'll write in everyday work uses about a dozen building blocks. Learn those, plus two or three traps, and regex goes from scary to one of the most useful small tools you own.

Let's build one up from nothing, then look at the traps and the times you shouldn't use regex at all. Examples are in PHP, but almost everything here works the same in JavaScript, Python and your editor's search box.

The dozen building blocks

That's it. Everything else is combining these.

Building one, step by step

Say invoice references look like INV-2025-0042: the letters INV, a dash, a four-digit year, a dash, and a four-digit number. We want to check a reference and pull out the year and number.

1. The literal part: INV-
2. Four digits for the year: INV-\d{4}
3. Another dash and four more digits: INV-\d{4}-\d{4}
4. Anchor it, so XXINV-2025-0042-EXTRA doesn't sneak through: ^INV-\d{4}-\d{4}$
5. Capture the parts we care about, with names so the code reads well:

$pattern = '/^INV-(?<year>\d{4})-(?<number>\d{4})$/';

if (preg_match($pattern, 'INV-2025-0042', $m)) {
    echo $m['year'];   // 2025
    echo $m['number']; // 0042
}

Read it left to right and it's almost a sentence. That's the trick: build regex in small steps and test after each one, instead of writing the whole thing at once and praying.

Forgetting the anchors is the most common bug in validation regex. Without ^ and $, a pattern only asks "does this appear somewhere in the string?", which is rarely what validation means.

Groups: three flavours

• Capturing (\d{4}): remembers what it matched, so you can use it ($m[1]).
• Named (?<year>\d{4}): same, but you get $m['year']. Use these whenever you have more than one group. Future you will be grateful.
• Non-capturing (?:jpg|png): groups things for | or a quantifier without remembering them. Keeps your match array clean.

The trap everyone falls into: greedy vs lazy

Quantifiers like * and + are greedy: they grab as much as they can while still allowing a match. Watch what happens:

$html = '<b>one</b> and <b>two</b>';

preg_match('/<b>(.*)<\/b>/', $html, $m);
// $m[1] is "one</b> and <b>two"  (greedy: ran to the LAST </b>)

preg_match('/<b>(.*?)<\/b>/', $html, $m);
// $m[1] is "one"  (lazy: stopped at the FIRST </b>)

Adding ? after a quantifier makes it lazy: match as little as possible. Often an even better fix is to be specific about what you allow: [^<]* ("anything except a <") can't overshoot at all.

Flags worth knowing

• i: case-insensitive. /^inv-/i matches "INV-" and "inv-".
• u: treat the pattern and string as UTF-8. In PHP, always add this when the input might contain non-English text, or . and character classes work on bytes and split characters in half. With it, \p{L} matches a letter in any language.
• m: makes ^ and $ match at each line, not just the whole string.
• x: ignores whitespace in the pattern so you can space it out and add comments. Great for long patterns.

Patterns you'll actually use

Notice the word shape on the date row. That regex happily accepts 2025-02-31. Regex checks what text looks like, not whether it makes sense. For real dates, use checkdate(), Carbon, or Laravel's date_format:Y-m-d rule.

When not to use regex

• Email validation. The full rules are famously hairy. Use filter_var($email, FILTER_VALIDATE_EMAIL) or Laravel's email rule, and confirm by actually sending an email.
• Parsing HTML or XML. Nesting breaks regex quickly. Use a real parser: DOMDocument, or the new HTML5-aware Dom\HTMLDocument added in PHP 8.4.
• URLs, JSON, CSV. parse_url(), json_decode() and fgetcsv() handle edge cases you haven't thought of.
• Untrusted input with a complex pattern. Nested quantifiers like (a+)+$ can take an enormous amount of time on certain inputs ("catastrophic backtracking"), which attackers can use as a denial of service. In PHP, preg_match then returns false instead of 0, so check for it and look at preg_last_error_msg().

How to test without fear

Two habits make regex safe to work with:

1. Use a visual tester. regex101.com explains every part of your pattern in plain English and highlights matches as you type. Pick the PCRE flavour for PHP, or ECMAScript for JavaScript, because the details differ.
2. Pin it with a test. A few lines with good and bad examples, so the next person who "improves" the pattern finds out immediately if they broke it.

public static function references(): array
{
    return [
        ['INV-2025-0042', true],
        ['inv-2025-0042', false],
        ['INV-2025-42', false],
        ['XINV-2025-0042', false],
    ];
}

The PHP manual's PCRE pattern syntax page is dense but complete when you need the details.

What's the regex you've copied from Stack Overflow so many times you should probably just learn it? For a lot of us, it's the one for trimming whitespace.