Regex Tester: Build and Debug Patterns Live (Free Guide)

By ZeroFee Tools · October 4, 2026 · 7 min read

Regular expressions are one of those skills everyone needs and nobody enjoys debugging. You write a pattern, it almost works, and you spend twenty minutes squinting at backslashes trying to find the one thing that is wrong. The cycle of tweak, run, squint, repeat is slow because the feedback loop is slow.

The ZeroFee Tools regex tester fixes that by testing your pattern against your own text as you type, with every match highlighted instantly, a live match count, and each match's capture groups listed underneath. It uses the JavaScript RegExp engine with g, i, m, and s flag checkboxes, clear error messages for invalid patterns, and a built-in cheat sheet. For plain-text jobs that do not need pattern power, the find and replace tool is a simpler companion, and this guide covers both the workflow and the most common gotchas.

How do I test a regex online?

Type your pattern in the pattern box (no slashes needed), tick the flags you want, and paste your test string below. Every match highlights instantly in yellow, the match count updates live, and each match's capture groups are listed underneath. This tester uses the JavaScript RegExp engine, so patterns behave exactly like new RegExp(pattern, flags) in your own code.

The workflow is deliberately simple. Type your pattern in the pattern box without the / / delimiters, tick the flags you want, then paste your test string below. Matches highlight in yellow the moment they are found, the match count updates above the text, and the capture groups section lists each group for every match, including groups that did not participate in a particular match.

Under the hood the tester builds new RegExp(pattern, flags), which means behavior matches your browser exactly. Without the g flag only the first match is returned, so the tool keeps g on by default and most people never need to touch it. That matches how most developers actually test: globally, case choices explicit, multiline only when the text is multiline.

The cheat sheet sits next to the workspace for a reason. Tokens like \d, \w, \s, negated classes, lazy quantifiers (*?, +?, ??), anchors, named groups (?<name>), alternation, backreferences \1, and lookaheads are all one glance away. Keeping the reference visible while you build is faster than flipping to documentation, and it is how most people gradually memorize the tokens they use daily.

What do the g, i, m, and s flags do?

The g flag finds all matches instead of stopping at the first. The i flag makes matching case-insensitive. The m flag lets ^ and $ match at line boundaries. The s flag lets the dot match newlines too. The two most common bugs are forgetting m for multi-line logs and forgetting s for patterns spanning line breaks.

Flags change what a pattern can see, and two of them cause most of the confusion. The g flag finds all matches instead of stopping at the first, which is why the tool enables it by default. The i flag makes matching case-insensitive, so error also matches ERROR and Error.

The m flag is about anchors: normally ^ and $ match only at the very start and end of the whole string. With m on, they also match at line boundaries, which is what you want when your test string is a stack trace or a log file with many lines. The classic multiline bug is writing ^\d{4}-\d{2}-\d{2} to grab dates and wondering why only the first line matches: you forgot m.

The s flag (dotAll) fixes the other classic bug: the dot matches any character except newlines unless s is set. A pattern like <div>.*?</div> silently fails across line breaks without it. If your pattern works on single-line samples but breaks on real data, check s first. One practical tip: combine flags freely. gis is a perfectly reasonable default for scraping tasks where you want everything, case-insensitively, across line breaks.

Why is my regex not matching anything?

Shrink your test string to the smallest example that should match, then check the three usual suspects: greedy quantifiers consuming too much (fix with lazy *? or +?), escaping errors inside and outside character classes, and hidden context like different whitespace. The live highlight makes each visible, and error messages name syntax problems explicitly.

When a pattern matches nothing, resist the urge to rebuild from scratch. Instead, shrink the test string to the smallest example that should match and check the pieces. If \d{3}-\d{4} fails on 555-1234, something structural is wrong; if it works there but fails in your document, the issue is context like hidden characters, different whitespace, or line endings.

Greedy quantifiers are the second suspect. .* consumes as much as it can, so "(.*)" on "a" and "b" captures a" and "b instead of just a. Switching to the lazy form "(.*?)" fixes it instantly. The live highlighting makes this visible at a glance: you see the match stretch too far and know exactly which quantifier to relax.

Escaping is the third suspect, especially in patterns copied from other languages. Inside a character class most metacharacters lose their special meaning, so [.] matches a literal dot without a backslash. Outside a class, .+? is almost always what someone meant when they wrote . and wondered why punctuation matched. And remember the tool shows clear error messages rather than failing silently, so read the message: unclosed groups and stray backslashes are named explicitly. Once the pattern is right, percent-encoding extracted URL parts is a safe next step with the URL encoder, and patterns built to parse API responses pair naturally with the JSON formatter for inspecting the payloads.

How to use the regex tester in 4 steps

1. Type the pattern. Enter it in the pattern box without / / delimiters, exactly as you would inside new RegExp().
2. Tick the flags. Leave g on for all matches; add i for case-insensitivity, m for multi-line anchors, s for dotAll.
3. Paste test text. Drop in your real sample. Matches highlight instantly and the count updates live.
4. Inspect the groups. Read the capture group list under the matches, then fix the pattern and watch the results change.

5 practical tips for better regex

• Start with a tiny test string. One line that should match beats a 10,000-line log for debugging. Add complexity back once the core pattern works.
• Reach for lazy quantifiers. When a match stretches too far, change .* to .*? or .+ to .+? before restructuring the whole pattern.
• Remember s for multi-line. If your pattern works on single lines but fails on real documents, the dot is probably not matching newlines.
• Use named groups for readability. (?\d{4}) is self-documenting in a way that $1 never is, and the tool lists named groups clearly.
• Do not regex what a simpler tool handles. Plain text swaps belong in the find and replace tool, and URL cleanup belongs in the URL encoder.

Frequently asked questions