Skip to content
Coding Regex

Regex Basics Every Developer Needs

By ToolzHive · · 3 min read

Regular expressions look like line noise, but underneath they are a small, learnable language for describing patterns in text. Learn a dozen pieces and you can match, search and transform text in ways that would take dozens of lines of code otherwise.

What a regex is

A regular expression is a pattern. You hand it some text, and it tells you where — if anywhere — the pattern matches. The pattern is built from ordinary characters that match themselves, plus a handful of special characters that mean "any digit", "repeat the last thing", "start of line" and so on.

Most of regex is just those special characters. Once they stop looking like noise, the rest is combination.

The core building blocks

A practical starter set, roughly in order of how often you reach for them:

  • Character classes. \d is any digit, \w a word character (letter, digit or underscore), \s any whitespace. Their capitals negate: \D is "not a digit". Square brackets make your own: [aeiou] matches any vowel, [a-z] any lowercase letter.
  • Quantifiers. * means "zero or more", + "one or more", ? "zero or one". {2,4} means "between two and four times". So \d{3} matches exactly three digits.
  • Anchors. ^ matches the start of a line, $ the end. \b is a word boundary, so \bcat\b matches the word "cat" but not "category".
  • The wildcard. . matches any single character (except a newline, usually).
  • Alternation and groups. (cat|dog) matches either word. Parentheses also capture what they match, so you can pull it out or reuse it.

That is enough to write most everyday patterns.

A worked example

Say you want to find email-like strings. A simple version:

\b[\w.+-]+@[\w-]+\.[\w.-]+\b

Read left to right: a word boundary, then one or more word characters/dots/plus/hyphens (the name), an @, the domain, a literal dot (escaped as \.), and the rest of the domain. It is not a perfect email validator — those are famously hard — but it reliably finds addresses in a block of text.

The mistakes everyone makes

  • Forgetting to escape. A dot means "any character". To match a literal dot you must write \.. The same goes for ?, +, *, (, ) and friends.
  • Greedy matching. By default .* grabs as much as possible. In <a>text</a>, the pattern <.*> matches the whole thing, not just <a>. Add a ? to make it lazy: <.*?> stops at the first >.
  • Over-engineering. If you are writing a monster regex to parse HTML or deeply nested structures, stop — use a real parser. Regex is for patterns, not for languages with nesting.

Why it is worth learning

The same pattern language works almost everywhere: in your editor's find-and-replace, in grep on the command line, and in every major programming language with minor dialect differences. Learn it once and you carry it for your whole career. A find-and-replace that understands regex turns "rename these forty variables consistently" from a tedious manual job into one expression.

Test before you trust

Regex is notoriously easy to get subtly wrong — a pattern that works on your three examples and fails on the fourth. The fix is to test against real, varied input before you put it into code: paste in the strings that should match and the ones that should not, and watch which the pattern catches.

Building the pattern piece by piece against live sample text, and running a regex-aware find-and-replace over a block of text, both happen in your browser, so you can iterate quickly and confirm a pattern does exactly what you expect — no more, no less — before trusting it in production.

Tools mentioned in this guide

Accessibility Menu

Personalize your experience. Open with Ctrl+U (Option+U on Mac). Preferences stay in this browser when storage is available.

Move / Hide Widget

Restore at any time with Ctrl+U (Option+U on Mac).

Accessibility statement and help