Your Regex Works in the Tester but Fails in Your Code: The Differences That Matter

A tester runs a particular engine. The tester on this site uses the JavaScript engine of your browser, so results match JavaScript and Node.js. If your code is in Python, Java, PHP, Go or .NET, the same pattern can behave differently or fail to compile. Always test in the same flavor as production, or at least know where the flavors diverge.

• ▸Named groups: JavaScript, Java and .NET write (?<name>...), while Python writes (?P<name>...). A pattern copied between them must be rewritten.
• ▸Lookbehind: supported in modern JavaScript engines, Python (with fixed width), Java and PCRE, but missing in older browsers and limited in some engines. Go's standard engine has no lookbehind and no lookahead.
• ▸Inline flags such as (?i) at the start of a pattern work in Python, Java and PCRE but not in JavaScript, which takes flags from outside the pattern.
• ▸The dot and newlines: by default the dot does not match a line break. The flag that changes this is s in JavaScript and Python and DOTALL in Java.
• ▸Possessive quantifiers and atomic groups exist in Java and PCRE but not in JavaScript or Python's older versions.

A regular expression object created with the g flag keeps state in a property called lastIndex. If you call test or exec repeatedly on the same object, each call continues from where the previous one stopped. The result is a function that returns true, then false, then true for the same input. The fix is to avoid the g flag when you only need a yes or no answer, or to create a fresh expression for each check, or to reset lastIndex to zero before each use.

The pattern \d+ in a tester has a single backslash. In many languages you must write that backslash twice inside a normal string, so Java and C# write \\d+ in source code, and JavaScript string literals behave the same way when you build a pattern with the RegExp constructor from a string. Raw string syntax avoids the problem: Python has r prefixed strings, C# has verbatim strings and Go has backtick strings. A pattern that works in a tester and matches nothing in code is very often an escaping problem.

• ▸In Python 3, \d matches any Unicode decimal digit by default for text strings, including Arabic Indic digits, while in JavaScript it matches only 0 to 9. Use explicit classes such as [0-9] when you need ASCII digits.
• ▸The word character class \w is ASCII only in JavaScript, so it does not match é or ü. To match letters from any language in JavaScript, use the unicode flag with the property escape \p{L}.
• ▸A single emoji can be several code units. Without the unicode flag, the dot matches half of an emoji in JavaScript.
• ▸Case insensitive matching of non-ASCII letters depends on the flag and the engine's Unicode support.

The caret and the dollar sign normally match only at the start and end of the whole string. With the multiline flag they match at each line. Windows line endings add a carriage return before the line feed, so a pattern that ends with a dollar sign can fail on text from a Windows file because of the invisible carriage return. Normalize line endings before matching, or allow an optional carriage return in the pattern.

Patterns with nested quantifiers, such as a group of repeated characters followed by another repeat, can take exponential time on input that almost matches. The result is a request that hangs or a CPU that spikes. Prefer specific character classes over the dot, avoid nesting repeats on overlapping alternatives, and set a time limit or use an engine with linear time guarantees when you match untrusted input.