Тестирование регулярных выражений
Tool guide
A regular expression almost never comes out right the first time: it grabs more than you meant, or it quietly misses the one line in the export that matters. Here you drop in a pattern, a set of flags and a real chunk of text, and see immediately what the pattern actually matched — without restarting a script or rebuilding a project for a single check. It runs your browser's own regex engine, the same one Node.js uses, so a pattern that works here transfers into JavaScript unchanged. Your sample text stays on the page. See also: validate and pretty-print JSON, strip HTML tags from a sample, percent-encode a string for a URL.
JavaScript: the pattern goes into your browser's RegExp constructor. The differences from PCRE show up around inline modifiers such as (?i), recursion and some named-group syntax, none of which JavaScript supports. Patterns written for PHP, Python or grep often work here, but where they diverge, trust the engine that will actually run the expression.
Without the u flag, JavaScript treats \w as [A-Za-z0-9_], which excludes Cyrillic entirely, and \d as the ASCII digits 0-9 only. For Russian text spell the range out as [а-яА-ЯёЁ] — ё and Ё sit outside the а-я range and must be listed separately. The broader fix is the u flag plus the \p{L} property.
No. Slashes with trailing flag letters are the literal notation used inside JavaScript source; here the pattern and the flags live in two separate fields. Put \d+ in «Regular expression» and g in «Flags (g, i, m)». Leaving the slashes in makes them ordinary characters to match, and nothing will be found.
The g flag makes the search global: the engine keeps going past the first hit and returns every occurrence. Without it you get the first match only, which suits validating a whole string but is useless for harvesting values out of text. Do not confuse matches with groups: the pattern (a)(b) against ab with no flags is one match, and what the parentheses caught is listed separately below it. The flags field starts with g already filled in, since that is the more common need.
Catastrophic backtracking. Nested quantifiers like (a+)+ or (\s*\w+)* against the wrong input push the engine into an exponential number of attempts. Reload the tab to escape it. The fix is bounding the repetition and replacing .* with narrower classes such as [^"]* — on a server the same flaw is called ReDoS.
The test runs in a script on the page: neither the pattern nor the «Test text» content leaves your device or gets stored anywhere. That technically makes internal logs fair game. Common sense still applies — swap passwords and full card numbers for invented values of the same shape and length.
It does. Below the list of matches sits a separate block with the capture groups by number, so you can see what each pair of parentheses caught rather than only the whole hit. The counter still counts matches: (\d+)-(\d+) against 10-20 is one match and two groups, not three results. A group that took no part in the match is shown empty.
Before: Pattern [\w.-]+@[\w-]+\.[a-z]{2,}, flags gi, text: "Write to [email protected] or copy [email protected]" After: 2 matches: [email protected], [email protected]
Before: Pattern \d{1,3}(\.\d{1,3}){3}, flag g, text: "10.0.0.5 - - [06/Sep/2026] \"GET / HTTP/1.1\" 200" After: 1 match: 10.0.0.5
Before: Pattern [\wа-яА-ЯёЁ]+, flag g, text: "Заказ №15 от Иванова"
After: 4 matches: Заказ, 15, от, Иванова
Your rating and feedback help decide what to improve next.