Regex: the 20% that solves 80% of problems

Regular expressions have a reputation as write-only line noise, and the famous joke — 'now you have two problems' — has survived decades because it lands. But most working regex uses a small vocabulary. Learn these pieces and you can read most patterns you'll ever meet:

. any character · \d digit · \w word character · \s whitespace · + one or more · * zero or more · ? optional · [abc] any of these · [^abc] none of these · ^ start · $ end · () capture group · | or. That's the kit. Everything else is refinement.

The two traps

Trap one: greediness. Quantifiers grab as much as possible. Applied to HTML, <.+> doesn't match one tag — it matches from the first < to the LAST > in the line. The fix is the lazy version <.+?>, and the general lesson: when a match is mysteriously huge, you forgot a question mark.

Trap two: unescaped specials. Dots, parentheses, plus signs and friends mean things. Searching for the literal string 3.14 with pattern 3.14 also matches 3514, because the dot means 'anything'. Escape it: 3\.14. When a pattern matches things it shouldn't, look for an unescaped special character first — it's the culprit nine times out of ten.

Test first, always

Nobody — nobody — writes a working regex on the first try. The professionals iterate in a tester with real sample text, watching matches update as they type, and only then paste the pattern into code. The tester above shows every match with its position and capture groups, and errors instead of silence when the pattern is malformed. And know when to stop: parsing arbitrary HTML or JSON with regex is a losing battle — that's what parsers are for. Regex is for patterns in flat text: extract the emails, validate the format, find the needles. Inside that lane, it's unbeatable.