Regex you will actually use

Regular expressions have a reputation problem: people learn them from a wall of syntax, then meet a 400-character pattern and conclude that regex is unreadable. In practice a handful of constructs covers almost every real task — validating a slug, pulling fields out of a log line, splitting key=value pairs, collapsing whitespace.

The constructs that cover most real work

• Anchors. ^ and $ match the start and end of the string, or of a line when the multiline flag is set. \b is a word boundary. Validation without anchors is not validation: [0-9]{3} happily matches inside abc123def.
• Character classes. [abc], ranges like [a-z0-9], the shorthands \d \w \s, and negations such as [^abc]. Inside a class most metacharacters lose their meaning, so [.] is a literal dot while a bare . matches anything.
• Quantifiers. ? zero or one, * zero or more, + one or more, {2,5} a bounded count.
• Groups. (...) captures, (?:...) groups without capturing.
• Alternation. |, which has the lowest precedence, so cat|dog food means cat or dog food. Write (?:cat|dog) food when you mean that.

Greedy versus lazy quantifiers

Quantifiers are greedy by default: they take as much as possible, then give back only what the rest of the pattern forces them to. Adding ? makes them lazy: take as little as possible and expand only as needed.

Input:  <a href="one">x</a> <a href="two">y</a>

/<a href="(.*)">/     captures  one">x</a> <a href="two
/<a href="(.*?)">/    captures  one

Lazy is not automatically correct either: <a href="(.*?)"> still fails on an attribute value containing a quote. When the delimiter is one character and cannot appear inside the value, the safest form is a negated class: "([^"]*)". That pattern has no ambiguity to backtrack through.

Rule of thumb: prefer a negated character class over a lazy dot whenever the stopping character is known.

Groups, named groups, and a one-minute lookaround

Switch to named groups as soon as a pattern has more than two captures. They document the pattern and remove the index-shuffling bugs you get when someone inserts a group in the middle.

PCRE / PHP:        (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})
Python:            (?P<year>\d{4})
JavaScript ES2018: (?<year>\d{4})

Non-capturing groups (?:...) exist for structure only. Use them for alternation and for applying a quantifier, as in (?:ab)+, so your capture indices stay meaningful.

Lookarounds assert context without consuming it:

• (?=...) looks ahead: \d+(?= USD) matches a number only when USD follows it.
• (?!...) is the negative form: ^(?!admin)\w+$ matches any word that is not admin.
• (?<=...) and (?<!...) look behind, which is useful for prefixes: (?<=\$)\d+ matches digits that follow a dollar sign. JavaScript requires fixed-length lookbehind; PCRE allows alternatives of different fixed lengths.

Patterns worth keeping in a snippet file

Email sanity check. Not RFC validation, just a typo filter:

/^[^\s@]+@[^\s@]+\.[^\s@]{2,}$/

It rejects spaces and missing dots, and nothing else — deliberately.

Parsing a combined log line. Named groups turn a log line into a record you can index:

/^(?<ip>\S+) \S+ \S+ \[(?<time>[^\]]+)\] "(?<method>[A-Z]+) (?<path>[^"]*?) HTTP\/[^"]+" (?<status>\d{3}) (?<bytes>\d+|-)/

URL slugs. Validate with an anchored pattern that cannot match a trailing hyphen:

/^[a-z0-9]+(?:-[a-z0-9]+)*$/

Generate one by lowercasing, replacing every run of disallowed characters with a single hyphen, and trimming the edges:

preg_replace('/-+$/', '', preg_replace('/[^a-z0-9]+/', '-', strtolower('Hello, World!')));
// "hello-world"

Extracting key=value pairs, quoted values included:

/(?<key>[A-Za-z_][A-Za-z0-9_]*)=(?<value>"[^"]*"|\S+)/

Normalising whitespace. Collapse tabs, newlines, and runs of spaces into one space, then trim the ends:

trim(preg_replace('/\s+/u', ' ', "  hello \t world  "));
// "hello world"

Watch the non-breaking space. In JavaScript \s does not match U+00A0, and in PCRE it only does with Unicode character properties enabled, so text pasted from a browser can survive normalisation. Use [\s\u00A0]+ when that matters.

Catastrophic backtracking

Nested quantifiers where the same characters can be divided in many different ways are the classic blow-up. (a+)+$ tested against a run of a's followed by a b forces the engine to try every partition before it can fail — 2^30 paths for a 30-character input. That is a request thread hanging for minutes on a short string.

Warning signs: a quantifier applied to a group that itself contains a quantifier ((a*)*, (.*)*, (a|aa)+), and overlapping alternatives where two branches can match the same text.

Fixes, in order of preference:

• Remove the ambiguity. (a+)+$ becomes a+$, and a lazy dot becomes a negated class.
• Use an atomic group (?>...) or a possessive quantifier such as *+, which tell the engine never to give characters back.
• Bound the input length before matching. A 500-character cap on user-supplied strings removes most of the exposure.
• Use a linear-time engine such as RE2 or Go's regexp package for untrusted input; you give up lookarounds and backreferences and gain a guarantee.

In PHP, keep an eye on pcre.backtrack_limit and always read preg_last_error(). A match that fails with PREG_BACKTRACK_LIMIT_ERROR is a pattern to fix, not a case to retry.

Debugging a pattern without guesswork

• Build incrementally against real input, one construct at a time. Never paste a 200-character pattern from the internet into production.
• Test on regex101 with the correct flavour selected — PCRE2 for PHP, JavaScript for Node. Its debugger shows the actual backtracking steps.
• Test the failure cases as carefully as the successes. A pattern that matches everything is worse than one that matches nothing.
• Print raw bytes when Unicode misbehaves: a non-breaking space looks identical to a normal one.
• In PHP, pick a delimiter that does not appear in the pattern, add the u modifier for UTF-8 input, and check for false before using a result.

When not to use regex

• HTML and XML. Use a real parser: DOM, BeautifulSoup, lxml. Markup is not regular, and quoted attribute values, comments, and nesting break every pattern eventually.
• Email validation per RFC 5322. The full grammar is enormous and still cannot tell you whether the mailbox exists. Check a plausible shape, then send a confirmation message.
• JSON, YAML, and CSV. Use a parser. Regex over quoted CSV fields with embedded commas and escaped quotes is a known way to lose data silently.
• Anything nested. Balanced parentheses, nested code blocks, and arithmetic expressions need a tokenizer or a parser generator.

Practical rule: if you cannot describe the pattern in one sentence, or you would need a comment per group, write the twenty-line loop instead. Regex earns its place on short, anchored, shallow patterns — and there, nothing is faster to write or to read.