Regex as a Second Language

Most of Regex Is a Small Vocabulary

Regular expressions have a reputation for being unreadable, but the actual working vocabulary most people need is small. You don't need to memorize the whole spec. You need maybe fifteen symbols, used constantly, and the judgment to know when reaching for them is the right call in the first place.

The Core Vocabulary You Actually Need

. matches any single character, * means zero or more of whatever came before it, + means one or more, and ? means zero or one. [] defines a character class, [a-z0-9] matches one lowercase letter or digit. ^ and $ anchor to the start and end of a line. The shorthand classes \d (digit), \w (word character), and \s (whitespace) cover most character-class needs without spelling out a range by hand. That's most of what you'll actually type.

Greedy vs Lazy, and Why It Bites You

By default, quantifiers are greedy, .* grabs as much as it possibly can before backing off to let the rest of the pattern match. Against a string with more than one instance of whatever you're bounding, that means .* often eats far more than you intended, spanning all the way to the last match instead of stopping at the first. Add a ? right after the quantifier, .*?, to make it lazy instead, grabbing as little as possible. Most "why did this match half my document" moments trace back to this exact default.

Capture Groups Are How You Extract, Not Just Match

Parentheses () create a capture group, which lets you pull a specific piece out of a match instead of just confirming the whole pattern matched. Reference them afterward as $1, $2, and so on, in the order they appear. Named groups, (?<year>\d{4}) for example, let you reference the capture by name instead of position, which is worth the extra characters the moment a pattern has more than two or three groups and you don't want to count parentheses to remember which is which.

Test It Before You Trust It

Write a regex, then throw edge cases at it before you ship it: an empty string, a string with extra whitespace, a string that almost matches but shouldn't. A tool like regex101.com shows you exactly what each part of the pattern is doing and why a given string does or doesn't match, which is faster than guessing from a wall of red text in your terminal. A pattern that only gets tested against the one example you wrote it for is a pattern that's already broken somewhere you haven't found yet.

When Regex Is the Wrong Tool

Regex matches patterns in flat text. It doesn't understand nesting, and that's exactly what trips people up trying to parse HTML, JSON, or any structured format with it, those have nested, recursive structure that regular expressions fundamentally can't track. If what you're parsing has real structure, reach for an actual parser instead, your language's HTML or JSON library exists for a reason. Save regex for what it's actually good at: finding and extracting patterns in flat, line-oriented text.