JavaScript Regexes: From Afterthought to Modern Standard

Regular expressions in JavaScript were standardized in ECMAScript 3 (1999), borrowing heavily from Perl’s flavor. That was a solid starting point, but for roughly two decades the language lagged behind other modern regex implementations. Features like lookbehind, named groups, and Unicode property escapes either didn’t exist or required awkward workarounds. That era ended with ES2018 and ES2024, which brought JavaScript regexes to parity with — and in some cases ahead of — the competition.

The quiet story here is that nearly every new ECMAScript edition since ES5 has made at least minor regex improvements. Here’s the timeline:

  • ES5 (2009): Fixed literal evaluation semantics (new object per evaluation) and allowed unescaped / inside character classes (/[/]/).
  • ES6/ES2015: Added the y (sticky) flag for parser-style scanning and the u (unicode) flag with stricter error handling and Unicode-aware matching. Also introduced RegExp.prototype.flags and regex subclassing.
  • ES2018: The turning point. Added the s (dotAll) flag, lookbehind assertions, named capture groups, and Unicode property escapes via \p{...}/\P{...}.
  • ES2020: Added the string method matchAll for global, capture-aware iteration.
  • ES2022: Added the d (hasIndices) flag, exposing start and end substring indices.
  • ES2024: Added the v (unicodeSets) flag, an upgrade to u that brings multicharacter property-of-strings escapes, nested character classes, set subtraction ([A--B]), intersection ([A&&B]), and corrected case-insensitive negated sets.

Each edition from ES2019 through ES2023 also expanded the catalog of supported Unicode property escapes. ES2021 contributed replaceAll, which behaves like replace with the g flag but throws otherwise. These features are all widely supported today; the most recent addition, flag v, is available in Node.js 20 and 2023-era browsers.

How JavaScript Stacks Up Now

Evaluating a regex flavor involves more than feature count. Three dimensions matter:

  • Performance. JavaScript’s backtracking engine is fast in practice — V8’s Irregexp runs in Node and Chromium browsers, and even Firefox adopted it in 2020. But there’s no syntax to control backtracking, which leaves patterns more exposed to catastrophic backtracking and ReDoS attacks.
  • Advanced feature support. ES2018 and ES2024 were major leaps. JavaScript now leads in areas like infinite-length lookbehind and Unicode properties with multicharacter “properties of strings,” set intersection/subtraction, and script extensions — functionality that’s absent or weaker in most other flavors.
  • Readability and maintainability. Here, native JavaScript still trails. It lacks the x (extended) flag for whitespace and comments, and has no subroutine support or definition groups as found in PCRE and Perl — tools that allow composing complex patterns grammatically. This has historically made native JavaScript regexes the hardest to write and maintain among major languages.

These remaining gaps are significant. However, unlike the feature deficits of the past, they can be filled today with a lightweight JavaScript library, which we’ll get to shortly.

Modern Regex Features Worth Using

JavaScript's regex support has matured considerably, and several newer features are particularly useful for extracting data and handling complex text. The examples below assume a moderate comfort level with regular expressions.

Named Capture Groups

When you need to pull substrings out of a match, named capturing groups make the pattern and the resulting code far more self-documenting. The syntax is (?<name>...), and identified values land on the groups object of the match result.

const record = 'Admitted: 2024-01-01\nReleased: 2024-01-03';
const re = /^Admitted: (?<admitted>\d{4}-\d{2}-\d{2})\nReleased: (?<released>\d{4}-\d{2}-\d{2})$/;
const match = record.match(re);
console.log(match.groups);
/* → {
  admitted: '2024-01-01',
  released: '2024-01-03'
} */

Beyond extraction, named backreferences via \k<name> let you rematch whatever a group captured. In replacements, you can also reference the values directly, and within a replacement callback, the groups object arrives as the final argument.

// Change 'FirstName LastName' to 'LastName, FirstName'
const name = 'Shaquille Oatmeal';
name.replace(/(?<first>\w+) (?<last>\w+)/, '$<last>, $<first>');
// → 'Oatmeal, Shaquille'

function fahrenheitToCelsius(str) {
  const re = /(?<degrees>-?\d+(\.\d+)?)F\b/g;
  return str.replace(re, (...args) => {
    const groups = args.at(-1);
    return Math.round((groups.degrees - 32) * 5/9) + 'C';
  });
}
fahrenheitToCelsius('98.6F');
// → '37C'
fahrenheitToCelsius('May 9 high is 40F and low is 21F');
// → 'May 9 high is 4C and low is -6C'

Lookbehind Assertions

Lookbehind, added in ES2018, is the counterpart to lookahead. Both are zero-width assertions, meaning they don't consume characters but simply pass or fail based on surrounding context. A positive lookbehind, (?<=...), requires the subpattern to appear immediately before the current position.

const re = /(?<=fat )cat/g;
'cat, fat cat, brat cat'.replace(re, 'pigeon');
// → 'cat, fat pigeon, brat cat'

Negative lookbehind, (?<!...), inverts the condition:

const re = /(?<!fat )cat/g;
'cat, fat cat, brat cat'.replace(re, 'pigeon');
// → 'pigeon, fat cat, brat pigeon'

JavaScript's lookbehind implementation is notably permissive. Unlike many other regex flavors, which impose complex restrictions on variable-length patterns inside lookbehind, JavaScript accepts any valid subpattern there.

The matchAll Method

Added in ES2020, String.prototype.matchAll provides a cleaner way to loop over matches when you need the full match object. It returns an iterator, which works naturally with for...of and sidesteps pitfalls like infinite loops with zero-length matches.

const re = /(?<char1>\w)(?<char2>\w)/g;
for (const match of str.matchAll(re)) {
  const {char1, char2} = match.groups;
  // Print each complete match and matched subpatterns
  console.log(`Matched "${match[0]}" with "${char1}" and "${char2}"`);
}

Note that matchAll requires the g flag. You can materialize all results into an array with Array.from or spread syntax.

const matches = [...str.matchAll(/./g)];

Unicode Property Escapes and Flag v

Unicode properties, introduced in ES2018, use \p{...} and its negation \P{...} to match by category, script, or binary property. They require either the u (unicode) or v (unicodeSets) flag. Flag v, added in ES2024, upgrades u and adds set subtraction (A--B) and intersection (A&&B) within character classes.

// Matches all Greek symbols except the letter 'π'
/[\p{Script_Extensions=Greek}--π]/v

// Matches only Greek letters
/[\p{Script_Extensions=Greek}&&\p{Letter}]/v

Using u or v is best practice to avoid bugs from the default, Unicode-unaware mode. Prefer v when you can target Node.js 20 or 2023-era browsers; otherwise, fall back to u.

Matching Emoji Correctly

Emoji are deceptive: a single one like “👩🏻‍🏫” (Woman Teacher: Light Skin Tone) is composed of multiple code points, including skin-tone modifiers and a zero-width joiner. Hand-rolled emoji regexes frequently get this wrong.

// Code unit length
'👩🏻‍🏫'.length;
// → 7
// Each astral code point (above \uFFFF) is divided into high and low surrogates

// Code point length
[...'👩🏻‍🏫'].length;
// → 4
// These four code points are: \u{1F469} \u{1F3FB} \u{200D} \u{1F3EB}
// \u{1F469} combined with \u{1F3FB} is '👩🏻'
// \u{200D} is a Zero-Width Joiner
// \u{1F3EB} is '🏫'

// Grapheme cluster length (user-perceived characters)
[...new Intl.Segmenter().segment('👩🏻‍🏫')].length;
// → 1

The ES2024 property \p{RGI_Emoji}, available only with flag v, matches complete emoji as single units. In environments without v support, the emoji-regex and emoji-regex-xs libraries are reliable alternatives.

Readability and Resilience

Even with all the recent additions, complex regexes remain notoriously difficult to read. The regex library adds features inspired by PCRE to address this. It provides a template tag and can be used as a Babel plugin, transpiling to native regexes with zero runtime overhead.

Whitespace and Comments

By default, the regex tag lets you sprinkle in whitespace and # comments for readability, equivalent to PCRE's xx flag.

import {regex} from 'regex';
const date = regex`
  # Match a date in YYYY-MM-DD format
  (?<year>  \d{4}) - # Year part
  (?<month> \d{2}) - # Month part
  (?<day>   \d{2})   # Day part
`;

Subroutines and Composition

Subroutines, written as \g<name>, treat a named group as an independent subpattern to match at the current position. This enables reuse and composition:

import {regex} from 'regex';
const ipv4 = regex`\b
  (?<byte> 25[0-5] | 2[0-4]\d | 1\d\d | [1-9]?\d)
  # Match the remaining 3 dot-separated bytes
  (\. \g<byte>){3}
\b`;

Subroutine definition groups go further by letting you define patterns for reference only, which keeps repeated parts of a pattern in one maintainable spot.

const record = 'Admitted: 2024-01-01\nReleased: 2024-01-03';
const re = regex`
  ^ Admitted:\ (?<admitted> \g<date>) \n
    Released:\ (?<released> \g<date>) $

  (?(DEFINE)
    (?<date>  \g<year>-\g<month>-\g<day>)
    (?<year>  \d{4})
    (?<month> \d{2})
    (?<day>   \d{2})
  )
`;
const match = record.match(re);
console.log(match.groups);
/* → {
  admitted: '2024-01-01',
  released: '2024-01-03'
} */

Defaults and Safety

The library enables the v flag by default, gracefully downgrading to u semantics in older environments. It also turns on emulated flags for insignificant whitespace (x) and named-capture-only mode (n). As a raw string template tag, it eliminates backslash escaping required with the RegExp constructor.

Atomic groups and possessive quantifiers are also supported, which guards against catastrophic backtracking (ReDoS) and lets you write simpler, more direct patterns without worrying about pathological performance on edge-case inputs.

Three Regex Proposals Worth Watching

Several active TC39 proposals are working their way toward formal inclusion in future JavaScript editions. Three of them are especially close to landing, and two are already usable in at least some browsers today.

Reusing Capture Group Names Across Alternatives

The duplicate named capturing groups proposal is at Stage 3, meaning it is nearly finalized, and it already works in all major browsers. When named captures were introduced, every (?<name>...) group had to carry a unique name across the entire pattern. That rule becomes awkward when a regex has several alternative paths that logically share the same semantic slot.

With this proposal, a pattern like the following no longer throws a “duplicate capture group name” error:

/(?<year>\d{4})-\d\d|\d\d-(?<year>\d{4})/

The constraint that names be unique within each alternative path still applies, so a single branch cannot declare the same name twice.

Scoped Flag Toggling

The pattern modifiers proposal (also Stage 3) lets you flip the i, m, and s flags for just a portion of a regex. Syntax uses (?ims:...), (?-ims:...), or a combination like (?im-s:...) to enable and disable flags inline, mid-pattern.

Here is the pattern modifier syntax in action:

/hello-(?i:world)/
// Matches 'hello-WORLD' but not 'HELLO-WORLD'

Support landed in Chrome/Edge 125 and Opera 111, with Firefox support expected soon. Safari has not yet announced a timeline.

Literal Escaping Built In

The RegExp.escape proposal also recently reached Stage 3, though no major browser implements it yet. The function RegExp.escape(str) returns input with all regex special characters escaped, so the string can be matched literally without manual escaping.

Developers who need this today typically reach for escape-string-regexp, a lightweight single-purpose npm package with more than 500 million monthly downloads. That utility performs minimal escaping, which is fine for most use cases. However, when you need to guarantee the escaped string is safe at any arbitrary position inside a larger pattern, the regex library mentioned earlier in this article recommends its own interpolation mechanism, which escapes embedded strings in a context-aware way.