How to use this calculator
Building a pattern the way the engine sees it
A regular expression is a miniature program: the engine walks your text, and at every position it asks whether the pattern matches starting there. The tester makes that walk visible — every match is listed with its position, the exact text it matched, and the capture groups it produced, updated as you type. Start with the literal that must appear (request_id=, say), add the flexible parts around it (a w+ for the value), and check the result against real lines from your data before you trust it anywhere.
The engine here is the platform’s ECMAScript RegExp — the same one JavaScript, Node.js, Deno, and every modern browser use. That is the point of the tool’s fidelity promise: a pattern that matches here matches in your code, and one that fails here will fail there. Dialects like PCRE (PHP, grep, regex101’s default) have features ECMAScript lacks or spells differently — lookbehind syntax, named-group conventions, atomic groups — and the tester rejects them with the platform’s error message rather than pretending to support a dialect it does not run.
Using the flags deliberately
Flags are not decorations — they change what the pattern means. Without g, the engine stops at the first match, and the classic "why does my pattern match once?" confusion is usually a missing g. Without m, the anchors ^ and $ bind to the whole string, not to line boundaries, so a pattern that should match each log line silently matches nothing when the text has multiple lines. The s flag is the one that surprises everyone: . matches every character except line breaks unless s is set, so patterns that should span lines fail on the newline. And the difference between the unicode u and non-unicode modes changes how astral characters like emoji are treated — a point where the ECMAScript engine is stricter than older dialects.
The tester shows the flags you have set at a glance and re-runs the scan on every change, so each flag’s effect is visible the moment you toggle it. That is the fastest way to learn what a flag does: switch it, watch the match list change.
Reading matches, groups, and failures
Each result row shows the matched text, its start position, and its capture groups — the parts of the pattern inside parentheses, which are the values your code will actually consume. The classic use is extraction: with /request_id=(w+)/g against a log line, group 1 holds the id, and the tester shows both matches and their group values before you wire the pattern into a pipeline.
A pattern that matches nothing is a bug report, not a puzzle: the tool shows every match position so the failure is visible at a glance — the pattern matched a different place than you expected, or matched zero times because of a missing flag, a literal space, or an anchor bound to the wrong position. Malformed patterns return the platform’s own error message, which names the position of the problem, so fixing is a matter of reading the message rather than guessing.
Safety and the honest limits
Regular expressions can be pathological: certain patterns take exponential time on certain inputs — the classic "catastrophic backtracking" failure mode — and the tester caps match scanning so a hostile pattern cannot freeze the page. The cap is disclosed; extremely large texts or pathological patterns are truncated with a notice rather than run to completion.
Two things the tool deliberately does not do: it does not judge whether a pattern is efficient enough for production traffic (that is a load-testing question), and it does not claim your pattern is correct in the abstract — it shows what the engine does with your text, which is the only honest answer. And because patterns and pasted text often contain credentials and personal data, everything runs locally: nothing is uploaded, logged, or stored.
Frequently asked questions
Which regex dialect does this tool use?
The platform’s ECMAScript engine — the same dialect JavaScript, Node.js, Deno, and browsers use. Dialects like PCRE (PHP, grep, regex101’s default) have extra features such as lookbehind in different forms and named groups with different syntax; those are not part of ECMAScript.
Why did my pattern match nothing?
Common causes: missing the g flag when you expect multiple matches, forgetting that anchors like ^ and $ match line boundaries only with the m flag, and patterns that accidentally include literal spaces. The tool shows every match with its position so the failure is usually visible at a glance.
Is my text sent anywhere?
No. The pattern and the text are processed entirely in your browser tab — nothing is uploaded, logged, or stored. This matters for log excerpts and configuration files that often contain credentials or personal data.
What does the u (unicode) flag actually change?
It switches the engine to strict Unicode mode: astral characters (emoji, rare scripts) are treated as single code points instead of surrogate halves, and some otherwise-lenient syntax becomes an error. Patterns that work without u can behave differently with it — the tester makes the difference visible as you toggle.
Can I use the same pattern in Python or Go?
Not safely — those languages use different engines (Python’s re, Go’s RE2). The fidelity promise here is specifically ECMAScript: what matches here matches in JavaScript, Node.js, Deno, and browsers. Porting a pattern to another language means re-testing it in that language’s tester.