This is an interactive regular-expression token reference that goes beyond a simple lookup. It lists the metacharacters and constructs you use to build patterns — character classes, anchors, quantifiers, groups and lookaround — shows which of the major flavors (PCRE, JavaScript, Python and .NET) support each one, and lets you test any pattern live against your own text.
How it works
A regular expression is a compact language for describing text patterns. Tokens fall into a few families: character classes match sets of characters (\d, [a-z], .), anchors match positions rather than characters (^, $, \b), quantifiers control repetition (*, +, {n,m}), groups capture or organise sub-patterns ((...), (?:...), (?<name>...)), and lookaround asserts what does or does not surround a position without consuming it ((?=...), (?<!...)). The reference marks each token with the flavors that accept it, because syntax such as named groups, possessive quantifiers and inline flags varies between engines.
Why flavor support matters
The four major regex engines share most of their syntax but differ in important corners:
| Feature | PCRE | JavaScript | Python | .NET |
|---|---|---|---|---|
Named groups (?P<name>...) | Yes | No (uses (?<name>...)) | Yes | No |
| Lookbehind | Yes | ES2018+ | Yes (fixed-width) | Yes |
Possessive quantifiers *+ | Yes | No | No | No |
Unicode categories \p{L} | Yes (with /u) | ES2018+ | Yes | Yes |
Atomic groups (?>...) | Yes | No | No | Yes |
If your pattern uses possessive quantifiers or atomic groups, it will work in PCRE and .NET but fail silently or throw in JavaScript and Python. The flavor column in the reference tells you immediately whether a token is safe for your target engine — checking it before shipping saves a debugging session.
Using the live tester
The tester compiles your pattern with the browser’s JavaScript engine and reports every match. Add flags such as g for global, i for case-insensitive, m for multiline and s for dotall. If the pattern is invalid you will see the engine’s error message. Because the engine is JavaScript, PCRE- or .NET-specific constructs may not be valid there — use the flavor column to keep your patterns portable. Everything runs in your browser; your pattern and text are never uploaded.
Greedy, lazy, and possessive quantifiers
Quantifier behavior is one of the most common sources of regex bugs:
- Greedy (
*,+,{n,m}) — match as much as possible, then backtrack. Default in all engines. - Lazy (
*?,+?,{n,m}?) — match as little as possible while still satisfying the pattern. - Possessive (
*+,++,{n,m}+) — match as much as possible and never backtrack. Prevents catastrophic backtracking but only available in PCRE and .NET.
For example, <.*> is greedy and matches the longest possible span between < and >, potentially engulfing multiple HTML tags in a single match. <.*?> is lazy and stops at the first >. If you need to parse HTML, a dedicated parser is still better — but within a line, lazy quantifiers solve most over-matching problems.
Backreferences and groups
A capturing group (...) not only groups sub-patterns for quantifiers — it remembers what it matched. You can refer back to that match later in the same pattern with \1 (first group), \2 (second), and so on. For example, (\w+) \1 matches a word immediately followed by itself, like the the. Non-capturing groups (?:...) group without recording, which is faster and keeps capture indices cleaner when you do not need the submatch.