How to Use the Regex Tester: Step-by-Step

What Regex Tester does in one screen

The Regex Tester compiles a regular expression with JavaScript's built-in RegExp engine and highlights every match inside your pasted text as you type — no submit button and no server round trip. Everything lives on a single screen: a monospace pattern field with six flag chips beside it, a test-string textarea underneath, and the results below a thin divider.

The layout is deliberately minimal so you can debug mid-task. The pattern field is autofocused on load, the textarea grows as you paste, and an invalid pattern prints the engine's own error message inline instead of failing silently. That inline message is usually more useful than a generic "invalid regex" banner, because it points at the exact construct the parser rejected.

Because evaluation happens locally in the page, patterns and test strings never leave the machine. We built it as part of OnlineFree.app's free online tools for people who need to validate a regular expression right now, on a laptop or a phone, without ads or account prompts interrupting them.

Step-by-step: pattern, flags, then text

Start with the text, not the pattern. Paste a real sample — an access-log line, a CSV row, a paragraph you pulled through the Clean Article Reader — so whatever you build has to survive the messy version of the data. Toy samples like "test123" hide the trailing spaces, punctuation and newlines that break patterns in production.

Then build the pattern in small increments. Type a literal first, such as \d{4} for any four-digit run, confirm it highlights, and only then wrap pieces in groups. If nothing lights up, delete the last thing you added instead of rewriting the whole expression; the highlighted preview turns debugging into a bisect.

Flags come next, and reading the output comes last. Suppose the pattern is (?<name>[A-Za-z]+)\s+(?<year>\d{4}) and the test string is "Ada Lovelace 1843". The single match starts at index 4, the full matched text is "Lovelace 1843", numbered group 1 and the named group name both hold "Lovelace", and group 2 holds "1843".

Once the pattern behaves, copy the JSON dump of matches and paste it into a unit test as the expected fixture. That one step converts a throwaway experiment into a regression test.

How do the six flags change your matches?

The chips toggle JavaScript's six standard flags: g, i, m, s, u and y. Global (g) is on by default so every match is returned rather than just the first, and it is the flag people most often uncheck by accident. Case-insensitive (i) means the pattern error also matches "Error" and "ERROR".

Multiline (m) and dotAll (s) are the pair that gets mixed up. The m flag changes where ^ and $ are allowed to match — at the start and end of each line instead of the whole string. The s flag changes what the dot matches, letting . cross line breaks; without s, . stops at every newline, so a greedy .* silently truncates at the end of the first line.

Unicode mode (u) makes property escapes such as \p{Script=Greek} work and treats a surrogate pair, like an emoji, as one character instead of two. It also turns identity escapes such as \A into syntax errors, which is why some patterns that work elsewhere fail the moment u is enabled. Sticky (y) pins the match to the position immediately after the previous one — on a fresh pattern the first match must begin at index 0 — which is handy for tokenising but rarely what you want when searching prose.

Reading indexes, groups and named groups

Above the result list you get a one-line count — "7 matches" or "No matches" — and each row below shows the 0-based start index, the full matched text, and then every capture group. Numbered groups begin at 1, since group 0 is the whole match, and a named group appears twice in the row: once by its number and once by its name.

A group that never participated in the match shows up empty, which is not the same as matching an empty string. That distinction matters when you port results into code, because a non-participating group becomes undefined rather than "". Watch the index base too: JavaScript positions, and therefore Regex Tester's output, start at 0, while some tools and SQL dialects return 1-based positions.

The copyable JSON dump is the part we reach for most. It holds every match with its index, text and groups, so you can paste it straight into a test file or a short script instead of retyping values by hand.

Common mistakes and honest limits

The classic mistake is writing a pattern for a host language and testing it here without checking the syntax overlap. This tool runs the engine defined in the ECMAScript specification; PCRE adds recursion, \K and atomic groups that JavaScript does not have, and Python's re module accepts the (?P<name>...) spelling of named groups where JavaScript wants (?<name>...). Always retest in the runtime that will execute the pattern for real.

Backslash handling in code is the second trap. In JavaScript string literals a single backslash is an escape character, so a pattern that pastes cleanly into the tester may need re-escaping in source. If your expression works here but not in your program, that extra escaping layer is the first thing to check.

Greedy quantifiers cause most of the rest. .* grabs as much as it can, so <(.*)> applied to "<a><b>" matches the whole string rather than just "<a>"; use .*? or a negated class such as [^>]* instead. Nested quantifiers like (a+)+$ can backtrack exponentially on a long line, which is why the test string is soft-capped around 200,000 characters and live re-evaluation is debounced by roughly 120 milliseconds. Verify important extraction output before trusting it — a pattern that looks right on two samples can still fail on the third.

For a quick sanity check on the text you feed in, the Hash Generator is useful when you need to confirm two samples are byte-identical before blaming the pattern.

References

• MDN: Regular expressions guide (JavaScript)
• ECMAScript Language Specification (ECMA-262)