JavaScript regex vs PCRE: the differences that bite

These are the good failures — you find out immediately. Atomic groups, possessive quantifiers, recursion, conditionals, and the global form of inline modifiers all fail at RegExp construction time:

new RegExp('(?>a+)b')      // SyntaxError: Invalid group
new RegExp('a++b')         // SyntaxError: Nothing to repeat
new RegExp('(?i)hello')    // SyntaxError: Invalid group
new RegExp('\\((?R)*\\)')   // SyntaxError: Invalid group
new RegExp('(x)?(?(1)a|b)')// SyntaxError: Invalid group

If a PCRE pattern with these constructs reaches production JavaScript, it fails loudly on first use. The dangerous cases are the ones in the next section.

JavaScript's Annex B grammar (the web-compatibility mode used when a pattern has no u or v flag) treats unknown escapes as identity escapes. PCRE's string anchors therefore degrade into literal letters, and POSIX classes parse as ordinary bracket expressions:

/\Astart/.test('Astart')   // true  - \A is a literal 'A'
/end\z/.test('endz')       // true  - \z is a literal 'z'
/\G/.test('G')             // true  - \G is a literal 'G'
/[[:alpha:]]/.test('a')    // false - not a POSIX class
/[[:alpha:]]/.test('a]')   // true  - class {[ : a l p h} + literal ']'

The fix is mechanical: always compile with the u or v flag. Both switch the grammar to strict mode, and the same broken escapes become compile errors — verified: `new RegExp('\\Astart', 'u')` throws "Invalid escape". For the semantics you actually wanted, `\A` becomes `^` without the m flag, and `\z` becomes `$` without m. Note one asymmetry with no JS equivalent: PCRE's `$` (and `\Z`) match before a string-final newline, while JavaScript's `$` does not — verified, `/end$/.test('end\n')` is false in Node and the Perl equivalent is true. Trim input before anchoring if it may carry a trailing newline.

Lookbehind landed in ES2018 and is safe to use in current runtimes; the long holdout was Safari, which only shipped it in 16.4 (2023), so patterns destined for older WebKit still need a fallback. Verified: `'price 100'.match(/(?<=price )\d+/)[0]` returns "100". What is less known is that JavaScript's lookbehind is more general than PCRE's: it accepts fully unbounded variable-length patterns — verified, `/(?<=^a.*)b$/` matches — while PCRE2 required fixed-length lookbehind branches for most of its history and only relaxed that in recent releases (10.43). If you develop a habit of heavy variable-length lookbehind in JS, expect ports to PHP or grep -P to fail in the other direction.

PCRE lets a pattern carry its own options via `(?i)`; in JavaScript, flags are a separate constructor argument, and the global inline form throws. The scoped form `(?i:...)` was standardized in ES2025 and works in current V8 — verified: `(?i:hello) world` matches "HELLO world", and `(?-i:hello)` under the i flag correctly refuses "HELLO". If you target older runtimes, hoist the modifier to a flag.

PCRE's `\G` (anchor to the end of the previous match) has no pattern-level equivalent, but the sticky y flag reproduces it at the API level: a y-flagged regex matches only at exactly lastIndex. Verified: `/\d+/y` with lastIndex=2 matches "12" in "ab12cd", and with lastIndex=0 returns null rather than scanning ahead. Related and worth internalizing: a g-flagged regex object is stateful across exec calls (verified: successive execs returned "1" then "22" with lastIndex advancing to 6), which is a classic source of alternating match/no-match bugs when a g regex is stored in a constant and reused.

ES2024's v flag (unicodeSets) adds character-class set operations — difference, intersection, and nested classes — that have no PCRE2 counterpart. Verified: `/[\p{L}--[aeiou]]/v` matches "b" and rejects "a": every Unicode letter except ASCII vowels, in one class. The v flag also implies the strict grammar, so it doubles as the lint mode from the Annex B section — verified, `\A` under v throws "Invalid escape". The cost is that v is the newest of the flags; check your runtime floor before shipping it.

PCRE users reach for `a++` or `(?>a+)` to kill catastrophic backtracking. JavaScript has neither, but the lookahead-plus-backreference idiom reproduces the semantics: a lookahead's internal match cannot be backtracked into, and the backreference then consumes exactly what the lookahead captured.

// PCRE:        (?>a+)b
// JavaScript:  (?=(a+))\1b

/^(?=(a+))\1ab$/.test('aaab')  // false - the group will not give back an 'a'
/^a+ab$/.test('aaab')          // true  - plain greedy quantifier backtracks

That verified false/true pair is the whole point: the emulated atomic group commits to its maximal match exactly like PCRE's would. It costs you a capture group slot and some readability, so reserve it for the quantifier-inside-quantifier patterns where backtracking actually explodes.

The regex tester on this site compiles your pattern with the native RegExp of the browser you are sitting in — the same engine class (V8, JavaScriptCore, SpiderMonkey) that will run your frontend code — so what matches there is what matches in production JS. It exposes g, i, and m flag toggles, lists every match with its capture groups and index, highlights matches in the test string, and previews replacements via String.replace, so $1 and $<name> substitutions behave exactly as they will in code.

Where it stops: there are no s, u, y, or v toggles in the UI, so dotAll, strict-grammar, sticky, and set-operation experiments need a devtools console instead; and because it is a JavaScript engine, it will happily accept patterns (unbounded lookbehind, `[\p{L}--[aeiou]]` if typed with flags in code) that your Python, PHP, or grep -P consumers will reject. Validate in the tester for JS targets; validate in the target engine for everything else.