.NET & PowerShell regex tester — System.Text.RegularExpressions rules, including the group-numbering quirk

System.Text.RegularExpressions is the one engine underneath C#, F#, VB.NET regex code and PowerShell's -match, -replace and Select-String — one implementation, several front doors, and one group-numbering rule that is different enough from every other flavor here to be worth its own paragraph before anything else.

Unnamed capturing groups are numbered first, in left-to-right source order — and named groups are numbered afterward, in their own left-to-right order, not interleaved by position the way Perl-family engines number them. (\d)(?<x>\w)(\d) puts the named group x at index 3, not 2, because both unnamed groups claim indices 1 and 2 first. A $2 written with a PCRE2 or JavaScript mental model, used against a .NET Match.Groups collection or a PowerShell $Matches array, silently reads the wrong capture — and it looks correct until the input changes shape and the group that used to be empty starts mattering.

.NET is also the one flavor here that allows duplicate group names outright — the same name reused for two different capturing groups in one pattern compiles without complaint, where PCRE2 rejects it unless the (?J) modifier is set and most other flavors reject it unconditionally. This is occasionally useful for alternation branches that want the "same" named capture regardless of which branch matched, but it's also a silent footgun if it happens by accident in a long pattern.

\d, \w and \s are Unicode-aware by default here, matching Python's default rather than JavaScript's or Java's ASCII-only one — RegexOptions.ECMAScript reverts them to ASCII-only and additionally restricts the rest of the pattern's syntax to an ECMAScript-compatible subset, which is the specific option name to reach for if you need .NET regex behavior to match JavaScript's rather than assume it already does.

PowerShell adds its own layer on top of the engine itself: the shell's own quoting rules run before .NET ever sees the pattern. A double-quoted PowerShell string interpolates $ — so a replacement template containing $1 written in double quotes gets the $1 eaten by PowerShell's own string interpolation before -replace ever receives it, silently turning your intended backreference into whatever $1 happens to resolve to as a PowerShell variable (usually nothing). Single-quoting the pattern and replacement string, or using a here-string, is the fix, and it's the single most common reason a -replace pattern that looks syntactically correct produces the wrong output.

Lookbehind here is unbounded-width, the same permissive rule Java and modern JavaScript use, so a pattern like (?<=\d+)abc that would fail to compile under Python or PCRE2's fixed-width restriction works fine in .NET without modification — one of the few places porting a pattern into .NET from a stricter flavor requires no rewriting at all.

.NET also has its own free-spacing mode, RegexOptions.IgnorePatternWhitespace (the x letter here), working the same way it does in PCRE2, Python and Java: unescaped whitespace and # comments inside the pattern are ignored, letting a long pattern be laid out and annotated field by field. Combined with C#'s verbatim string literals — @"\d+" needs no backslash-doubling the way a normal "\\d+" string does — a well-formatted .NET pattern in source code can be genuinely more readable than the equivalent single-line pattern in most other languages, at the cost of one more flag to remember to set consistently between where the pattern is written and where it's tested.

For PowerShell specifically, it's worth testing both directions of a pattern separately: -match (and the case-insensitive-by-default -match, with -cmatch for case-sensitive) populates the automatic $Matches variable as a hashtable keyed by group number and name, while Select-String is built for scanning files or piped text and returns richer MatchInfo objects with filename and line-number context attached. Both run the identical .NET engine underneath, so a pattern that's right for one is right for the other — the difference is entirely in what PowerShell hands back to you afterward, not in what matched.