Regex Cheat Sheet: Patterns That Cover Most Tasks

Regular expressions match text patterns — emails in a log, digits in a filename, quoted strings in JSON-ish dumps. They are not a full parser, but for quick extraction and validation they save hours. Keep a cheat sheet nearby and test on real samples before shipping to production. Regex excels at finding patterns in semi-structured logs; it fails at validating nested JSON — reach for a parser when braces must balance recursively.

Literals and anchors

. matches any character except newline (in default mode). ^ start of line or string, $ end. \d digit, \w word character (letter, digit, underscore), \s whitespace. Capital versions negate: \D non-digit, etc. Escape metacharacters when you mean them literally: \. for a period, \\ for backslash.

Quantifiers

* zero or more, + one or more, ? optional (zero or one). {3} exactly three, {2,5} between two and five, {3,} three or more. Greedy quantifiers take as much as possible; add ? after them (*?, +?) for lazy matching inside long strings.

Character classes and groups

[abc] any of a, b, c. [a-z] range. [^0-9] not a digit. (pattern) capture group — use $1 in replacements. (?:pattern) non-capturing group for alternation without remembering. Alternation with |: cat|dog matches either word.

Practical recipes

Rough email shape: \b[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}\b — not RFC-perfect, fine for triage. US phone loose: \(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}. ISO date: \d{4}-\d{2}-\d{2}. Shell grep uses basic regex unless `-E`; escaping differs from JavaScript — test in /tool/regex-tester before pasting into `.gitlab-ci.yml`. Replace spaces with dashes in slugs: find \s+, replace with - after lowercasing in your editor.

Test before deploy

Paste sample lines into /tool/regex-tester, toggle flags (i caseless, m multiline, s dotall), inspect matches and groups. Open /tool/regex-cheat-sheet for a compact reminder of escapes and quantifiers. For bulk extraction in logs, pair with /tool/extract-emails or /tool/extract-urls when the pattern is standard.

Pitfalls

Catastrophic backtracking on nested quantifiers can hang engines — simplify or possessive quantifiers where supported. Unicode letters need u flag in JavaScript. HTML and JSON need parsers, not one giant regex.

Production hygiene

Cap input length on server-side regex validation, log slow paths, and prefer parsers for HTML, JSON, and XML at boundaries. Keep a copy of patterns that passed review in your repo with a comment linking to sample inputs in /tool/regex-tester — future you will forget why a lookbehind was needed. When onboarding juniors, start with literal search, then anchors, then quantifiers; /tool/regex-cheat-sheet is the desk reference, not a substitute for reading error messages when a pattern fails.

Character classes are not Unicode-aware unless you enable the right flag — accented letters may sit outside \w. Word boundaries \b behave oddly with hyphenated tokens; test on real product codes. Prefer possessive or atomic groups in engines that support them when profiling shows backtracking hotspots. For replace pipelines, run match-only first, then replace on a copy. Document why you chose greedy versus lazy in a comment — the next maintainer will otherwise flip it and break extraction. Keep a library of vetted patterns in your org wiki linked to /tool/regex-tester examples.

Lookahead and lookbehind vary by engine: JavaScript added fixed-width lookbehind in modern runtimes; Python re supports variable lookbehind in 3.5+ with limits. Named capture groups improve readability in large patterns — use them in /tool/regex-tester before pasting into production code. When extracting from multilingual text, explicit Unicode property escapes \p{L} beat ad hoc character ranges. For log sampling, combine regex prefilter with jq or SQL to avoid over-promising one pattern. Email validation for signup forms should combine regex sanity check with confirmation links — pattern match alone does not prove deliverability. Phone numbers need country context; a single regex for all regions usually fails edge cases. Log samples that failed match to refine patterns instead of widening regex until it accepts garbage. Split large validation problems: use regex to tokenize, then validate tokens with code. Property-based tests that generate random strings help find edge cases your cheat-sheet pattern missed.

FAQ

Which flavor does the tester use? JavaScript-style RegExp; PCRE and Python differ slightly on lookbehind and flags.

Are regexes secure? ReDoS is real — cap input length on server-side validation.

Why no match? Check multiline anchors, Windows \r\n, and accidental greedy .* swallowing the rest.

Memorize or cheat sheet? Cheat sheet plus tester beats rote memorization for rare flags.