SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Regex Added 11 February 2026

Regex: Lookbehind not supported

Lookbehind support is a property of the engine, not of the pattern: Go RE2 has none at all, Python and Java accept only fixed width lookbehinds, and JavaScript has supported the full form since ES2018. A pattern copied between languages therefore compiles in one and is rejected in the next.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Who supports what, which decides whether the pattern can be kept at all
# JavaScript (ES2018+): variable width lookbehind, supported everywhere current
# .NET and the Python regex module: variable width
# Python re and Java: fixed width only, so quantifiers inside are rejected
# Go RE2, RE2 based engines and most SQL regex: no lookbehind or lookahead

// The portable rewrite: capture what you were looking behind, use group 1
// instead of: (?<=@)\w+
const m = "[email protected]".match(/@(\w+)/);
m[1];  // example

# Python: keep the lookbehind fixed, or capture instead
re.compile(r'(?<=Total: )\d+')      # fine
re.compile(r'(?<=Total:\s*)\d+')   # look-behind requires fixed-width pattern

// Go has no alternative syntax: match wider and filter in code
re := regexp.MustCompile(`@(\w+)`)

# Replacement is where lookbehind is least needed: a group keeps the prefix
re.sub(r'(Total: )\d+', r'\g<1>0', text)

How to diagnose Regex errors

Regex problems come in two flavours: it does not match what you expect (usually escaping, greediness, or an engine feature difference) and it matches but takes forever. The second is catastrophic backtracking, a genuine denial-of-service vector known as ReDoS, caused by nested quantifiers over overlapping character classes, such as (a+)+b. Any regex applied to untrusted input should be checked for it.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Test against a visualiser that shows backtracking steps, and always test with input that fails to match. That is where catastrophic backtracking appears, not on successful matches.
  2. Eliminate nested quantifiers over overlapping classes. Rewrite (a+)+ as a+, and prefer possessive quantifiers or atomic groups where the engine supports them.
  3. Know your engine: lookbehind, named groups and Unicode property escapes differ between PCRE, RE2, JavaScript, Python and Go. RE2 (used by Go) deliberately has no backtracking and rejects some patterns outright.
  4. Anchor patterns with ^ and $ where you mean a whole-string match. Unanchored patterns silently match substrings.
  5. Set a timeout or use a linear-time engine for user-supplied patterns. Never run an untrusted regex on a request thread.

Tools worth reaching for

  • regex101.com
  • re2 / RE2J
  • Python re.DEBUG
  • grep -P for PCRE testing
  • recheck / redos linters

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

developer.mozilla.org docs.python.org

Related Regex errors

See all 17 Regex errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.