Regex Tester

Often, but not reliably. The common syntax — character classes, quantifiers, anchors, groups — is shared. The differences appear in lookbehind support, named-group syntax ((?<n>) versus (?P<n>)), Unicode property escapes, and constructs like atomic groups that JavaScript simply does not have. Test in the target language before shipping.

Quantifiers are greedy by default: .* consumes as much as it can and gives back only what it must, so ".*" against "a" and "b" matches the whole line rather than the first quoted word. Add ? to make it lazy (.*?), or better, use a negated class like [^"]* that cannot cross the delimiter at all.

Without g, matching stops at the first result. With it, the scan continues and returns every non-overlapping match. It also makes a regex object stateful in code — it keeps a lastIndex between calls — which is a common source of bugs when the same object is reused across test() calls.

You can approximate it, and every short pattern that claims to is wrong at the edges — the real grammar in RFC 5322 permits quoted strings, comments and nested constructs almost nobody handles. In practice check for a single @ with something plausible either side, then verify by sending mail to the address.

A pattern can match without consuming a character, which would otherwise leave the scan at the same index forever. The tester advances after a zero-length global match so the result can be displayed without an infinite loop. Review those matches carefully in production code.

Yes. JavaScript matching runs synchronously here, and nested ambiguous quantifiers can cause catastrophic backtracking on certain inputs. Test with small representative text, simplify risky repetitions, and avoid pasting sensitive or very large logs into an untrusted pattern.