The portability problem

"Regular expressions" is not one language. It's a family of dialects that look almost identical and disagree in exactly the places you don't look until production breaks: \w is Unicode-aware by default in Python 3, PCRE2 and .NET, but ASCII-only in JavaScript. Lookbehind must be fixed-width in PCRE2; .NET accepts variable width; RE2-based engines reject lookbehind entirely. Possessive quantifiers, atomic groups, \K, named-group syntax (?<name>…) vs(?P<name>…) — every one of these is a line in some engine's grammar and an error (or worse, a silent behavior change) in another's.

The standard workflow makes this invisible. You test the pattern in one tester with one flavor selected, it works, you paste it into another language, and the failure shows up far away from the regex — a log line that never matches, a validation that rejects valid input, an import script that silently skips rows. By the time anyone connects the symptom back to the pattern, the regex has been through three people and a rewrite.

A flavor selector doesn't solve this — you still have to try every flavor by hand and compare results from memory. What you need is every engine answering at once, side by side, on the same input. That's what the Compat button does.

A 60-second tour

Type your pattern and a representative test string, then hit the Compat button in the toolbar — or share the deep link/compat directly:

The report opens and every engine starts working immediately; rows stream in as each one resolves. For a well-behaved pattern the outcome is short and sweet:

Each row carries a badge naming its execution path — native, WASM engine, interpreter or emulated — so you always know what kind of evidence you're looking at. Click a row to expand the engine's own error message or a preview of its matches.

Same regex, different matches

Here is the case that makes the feature worth having. The pattern is as innocent as regexes get: \w+. The input is héllo wörld. Both compile everywhere. Both "work". And they split the engines into two camps with different outputs:

JavaScript's \w is [A-Za-z0-9_] unless the u flag with property escapes comes into play, so it finds h, llo,w, rld — four matches. PCRE2, Python, .NET, Go and Rust treat \w as Unicode-aware (Go and Rust by design, the others by default), matching héllo and wörld whole — two matches. Java's default \w is ASCII-only too, which is why it clusters with JavaScript.

No error is thrown anywhere. Port this pattern between any two of these engines and the behavior changes silently. The report makes the split visible in one glance: the verdict banner, the two colored cluster dots, and the differs marker on the minority rows.

The three ways a port fails

A pattern that uses \K — PCRE's "keep" escape, which resets where the reported match starts — fails differently in different engines. The report shows all three failure shapes in one view:

• Works as intended. PCRE2 is the only engine doing what the author meant — one match, starting after \K. Its row is marked differs because it's the minority result.
• Rejected outright. .NET refuses the pattern — expand the row and you get the engine's own error, not a paraphrase. You find this out here, instead of in a CI log three languages away from where the regex was written.
• Silently does nothing. The remaining engines accept the pattern and match nothing — the strict \K is consumed as a literal K, and there is no K after the @. No error, no match: the worst failure mode, because nothing announces it.

One row reads valid · untestable here: the dialect parser accepts the syntax, but this site has no faithful execution path for it, so the row refuses to guess. That's a deliberate honesty rule — an untestable engine is labeled untestable, never quietly approximated.

How agreement is decided

Each engine's full match set is reduced to a signature: every match's position, matched text and capture groups. Engines with equal signatures are clustered under one colored dot; the cluster with the most engines is treated as the majority, and any ok-row outside it gets the differs marker. Signatures include positions and groups — not just match counts — because two engines can agree on how many matches while disagreeing on where they are, and that distinction matters when you port.

The verdict banner summarizes the state in one line, in one of three shapes:

• Fully compatible — identical match results in all 7 engines — the signature test passed everywhere.
• Compiles everywhere, but match results differ… — accepted by all, with two or more distinct outcomes.
• 5/7 engines accept this pattern · … — a mixed report: acceptances, divergences, untestables and rejections, counted.

And one consistency guarantee by construction: every row runs through the same execution path the editor itself uses when you select that flavor manually. There is no separate "compatibility mode" — the report can never disagree with what you see when you switch flavors by hand.

The seven engine paths

Seven rows cover the eight flavors the tester supports (PCRE v1 rides along with PCRE2 — they share the dialect and engine here). The badge on each row says which of the four path types it is:

The emulated rows are labeled emulated because pretending they're real engines would be the one unforgivable sin in a compatibility report: they answer "is this valid in the dialect, and what does the normalized equivalent match?" — which is what the editor shows for those flavors — not "what does CPython's or the JVM's engine do?" Every other row runs the production engine binary.

Exporting the report

One click copies the whole report as Markdown — verdict, per-engine outcomes with their execution paths, and the distinct-result groups when engines disagree. Paste it into a pull request, a migration ticket or an architecture-decision record, and the reviewer sees the portability evidence instead of taking your word for it:

## Regex Compatibility Report

Pattern `\\w+` · flags `gi` · 11-char test string · 2026-10-12, 09:41

**Compiles everywhere, but match results differ across engines (2 distinct outcomes) — see the groups below.**

| Engine | Execution path | Result |
|---|---|---|
| ✅ JavaScript | V8 RegExp (browser native) | 4 matches |
| ✅ PCRE2 | PCRE2 10.x WASM · also covers PCRE v1 | 2 matches |
| ✅ Python | dialect parser + normalized execution | 2 matches |
| ✅ Java | dialect parser + normalized execution | 4 matches |
| ✅ .NET | .NET semantics interpreter (TS) | 2 matches |
| ✅ Go | Go regexp (RE2) WASM | 2 matches |
| ✅ Rust | Rust regex crate WASM | 2 matches |

Distinct outcome groups:
- JavaScript, Java → 4 matches
- PCRE2, Python, .NET, Go, Rust → 2 matches

Because the report includes each row's execution path, the evidence stays auditable months later: readers can tell real-engine results from emulated ones without reverse-engineering the tool.

How it compares

Multi-flavor testers exist — you pick a flavor, the tester runs it. Running all flavors on one pattern and diffing the outputs is the part that has always been manual. This feature was built to delete that manual step:

Also in the box: deep link at /compat for sharing the report entry point, per-row engine error messages on expand, and a "How to read this report" primer built into the panel.

FAQ