Use this page to grab a useful starting pattern and then refine it. The patterns here are intentionally practical rather than exhaustive.
^[^\s@]+@[^\s@]+\.[^\s@]+$Example: Useful for lightweight client-side checks where you only need a reasonable shape test.
Gotcha: This is intentionally simple and does not fully validate all valid email addresses. Use application validation for strict rules.
^#(?:[0-9a-fA-F]{3}|[0-9a-fA-F]{6})$Example: Matches values like `#fff` and `#1f8ced`.
Gotcha: This pattern allows only 3-digit and 6-digit hex colors, not 4-digit or 8-digit alpha forms.
(\d+)Example: Example input: Order #48291 ready. This pattern captures 48291 as group 1.
Gotcha: This captures the first or each digit run depending on the regex engine and how you iterate matches.
\bword\bExample: Use this when `word` should match by itself but not inside `swordfish` or `password`.
Gotcha: Word-boundary behavior depends on the engine and character set rules, especially with Unicode text.
\s+Example: Use as the search pattern in a replace operation and replace matches with one space.
Gotcha: This can collapse newlines too. If you only want horizontal spacing, use a narrower pattern for your engine.
Regex is powerful because it compresses a lot of matching logic into a very small surface. It is also frustrating for the same reason. A single character can change whether a pattern matches once, everywhere, too much, or not at all. This reference page is built for practical regex tasks: searching text, extracting values, validating simple formats, and writing replacements you can trust.
If you searched for regex syntax, regex examples, regex reference python, or a quick explanation of capture groups, this page is meant to be the useful middle layer between a cheat sheet and a full engine-specific manual.
| Pattern piece | Meaning | Example use |
|---|---|---|
. |
Any character except newline in many engines | Match an unknown single character |
\d |
Digit | Find numbers like 2026 |
\w |
Word character | Match identifiers and simple tokens |
[A-Z] |
Character class | Restrict a match to uppercase letters |
+ |
One or more | Match a repeated token |
* |
Zero or more | Allow optional repetition |
? |
Optional or non-greedy modifier context | Make a token optional or lazy |
^ and $ |
Start and end anchors | Validate the whole line |
( ... ) |
Capture group | Extract part of a match |
(?: ... ) |
Non-capturing group | Group without storing |
```regex
^\d{4}-\d{2}-\d{2}$
```
Matches a simple YYYY-MM-DD style date shape.
```regex
[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}
```
Finds email-like strings in free text.
```regex
"userId"\s:\s(\d+)
```
Captures a numeric user ID from JSON-like text.
These examples matter because they demonstrate three different intents: validation with anchors, extraction with capture groups, and flexible whitespace handling for text that may not be formatted consistently.
One of the most common regex bugs is matching too much. Quantifiers such as * and + are typically greedy, which means they consume as much as they can while still allowing the overall pattern to match. If your match seems larger than expected, greediness is often the reason.
For example:
```regex
<.*>
```
can match from the first < to the last > on a line. A more controlled version is:
```regex
<.*?>
```
The ? after * makes the quantifier non-greedy in engines that support lazy matching. This is one of the simplest examples of why a regex reference should explain behavior, not just symbol lists.
Capture groups let you reuse matched text in a replacement or inspect specific subparts of a pattern. Suppose you want to swap last, first into first last:
```regex
^([^,]+),\s*(.+)$
```
A replacement can then use the captured groups in reversed order. Exact replacement syntax varies by engine, but the capture idea is the same. This is why developers often search for a regex reference capture group rather than just “regex syntax.” The structure around the match is where many real tasks live.
Regex is not one universal language. JavaScript, Python, PCRE-style tools, and editor search boxes overlap heavily, but not perfectly. Named groups, lookbehind, backreference syntax, and replacement tokens can vary. That is why a good workflow is:
This page gives engine-agnostic patterns where possible, but the final execution context still matters.
| Mistake | Result |
|---|---|
| Skipping anchors when validating | Partial matches slip through |
Using .* too early |
The pattern becomes too broad |
| Capturing every group by default | Replacements and reading become noisy |
| Forgetting engine differences | A valid pattern in one tool fails in another |
| Escaping inconsistently | Metacharacters stop meaning what you expect |
Regex syntax is a compact language for describing text patterns so you can search, validate, extract, or replace matching strings.
Use a capture group when part of the match needs to be reused, returned, or referenced in a replacement.
Usually because a quantifier such as * or + is greedy and you did not add anchors, tighter character classes, or a non-greedy form.
Usually no. Start small, verify the shape, and only add complexity when the simpler pattern no longer solves the task cleanly.
Combine this page with the JSON reference for structured payload examples, the YAML reference for config-oriented text patterns, the Developer Reference Hub for neighboring syntax pages, or the VS Code shortcut reference when the regex is being applied inside editor search and replace.
Regex patterns often look correct when tested against ideal examples and fail when real data includes extra whitespace, punctuation, or line breaks. That is why practical regex work always includes one more step: test the pattern against messy, representative input before you trust it in a replacement or validation rule.
There are only two things wrong with C++: The initial concept and the implementation.
…
…