Regex tester that cannot freeze your tab

Because it is backtracking, not working. When a pattern can match the same text in more than one way — an open-ended repeat inside another open-ended repeat, as in (a+)+ — the engine tries every possible split before it is allowed to report failure, and the number of splits doubles with each extra character. Measured in V8 against a string of a characters ending in an x that can never match, (a+)+$ takes 98 ms at 24 characters, 392 ms at 26, 1.6 seconds at 28 and 6.3 seconds at 30. This page runs every attempt inside a Web Worker and terminates it after 1,000 ms, which is why you get a message here instead of a spinning tab.

A lookbehind, written (?<=…) or (?<!…), asserts that something does or does not appear immediately before the current position without consuming it — (?<=\$)\d+ pulls 42 out of “$42” and leaves the dollar sign behind. JavaScript got it in V8 with Chrome 62 in 2017, Firefox 78 in 2020, and Safari only in 16.4 in March 2023, so an iPhone left on iOS 15 throws a SyntaxError on the entire pattern rather than ignoring the one construct. JavaScript's version is also unusually capable: the lookbehind may be variable length, where PCRE, Python's re and Java all demand a fixed width, so a pattern copied from this tool into those engines can fail for a reason that has nothing to do with your logic.

Because a regex with the g or y flag carries a lastIndex property that survives the call. Calling re.test(s) twice in a row on the same object returns true then false, since the second call resumes from where the first stopped and runs off the end; the same trap catches re.exec inside a loop over an array, and a regex declared as a module-level constant is the usual victim. Either build the regex where you use it, set re.lastIndex = 0 before each run, or use s.match(re) which does the reset for you.

Because a group that never took part in the match has no value at all, and JavaScript reports that as undefined. In (a)|(b) exactly one of the two groups participates in any given match, so the other is undefined — not "" — and code that does m[2].length crashes rather than measuring zero. An optional group behaves the same way: (\d+)? that matched nothing is undefined, while (\d*)? that matched nothing is the empty string, and the tables on this page distinguish the two.

No — the dot matches every character except the four line terminators \n, \r, \u2028 and \u2029. Turn on the s flag, dotAll, and it matches those too; that flag arrived in ES2018 and is safe everywhere today. The older workaround still found in production code, [\s\S] or [^], works by asking for a character class that has no exception, and it survives in patterns that must run through a build target predating the flag.

Because a JavaScript string is a sequence of UTF-16 code units, and anything above U+FFFF occupies two of them. Without the u flag the dot matches one code unit, so /./ against a grinning face returns a lone surrogate that renders as a broken box, and "😀".length is 2 rather than 1. Add u and the pattern works in code points, which also unlocks \u{1F600} and property escapes such as \p{Letter} or \p{Emoji_Presentation}. Note that even a code point is not always a whole character — a family emoji or an é written as e plus a combining accent is several code points that render as one grapheme.

Often, but four differences bite most: Go's standard regexp package and RE2 refuse backreferences and lookarounds outright, in exchange for a guarantee that matching is linear in the input and can never blow up the way JavaScript's can; POSIX grep needs -E before it will read +, ? or | the way you wrote them; Python's \d matches Devanagari and Arabic-Indic digits unless you pass re.ASCII, while JavaScript's \d is always exactly 0-9; and PCRE offers atomic groups (?>…) and possessive quantifiers such as a++ that JavaScript simply does not have, which is precisely why catastrophic backtracking is easier to hit here than there.