Regex Tester – Interactive Regular Expression Tool

Test patterns against real text before you trust them

Regular expressions are compact, but they are rarely easy to reason about by eye. A single missing backslash, an anchor in the wrong place, or an omitted flag can turn a careful pattern into one that matches far too much or almost nothing at all. This page gives you a quick browser-based way to see what a JavaScript regex really does. Enter the pattern, add any flags you want, paste representative text, and the results panel highlights every match so you can inspect behavior instead of guessing from memory.

This tester is most useful when you are writing validation rules, extracting structured data, cleaning text, or debugging a pattern that seems right but behaves strangely in production. Developers often discover that the problem is not the visible letters in the pattern, but the assumptions around them: whether the pattern is case sensitive, whether it should match the whole line or just a substring, whether a dot should cross line breaks, or whether a quantifier is too greedy. Seeing the sample text and the highlighted output together makes those mistakes much easier to spot.

What each input means

Regex Pattern is the body of the pattern itself. Type the expression without surrounding slashes. For example, if you would normally write /\bcat\b/i in code, place \bcat\b in the pattern box and i in the flags box. This separation is useful because it mirrors how JavaScript builds a RegExp object internally: the pattern and its modifiers are distinct inputs. It also makes experimentation faster because you can keep the pattern fixed and test several flag combinations without retyping the whole expression.

Flags control how the engine searches. This tool accepts the standard JavaScript flags g, i, m, s, u, and y. Repeated flags are automatically deduplicated, and unsupported characters are ignored so a stray typo does not crash the form before the regex is compiled. One important implementation detail is specific to the highlighter on this page: the tester adds the global flag when needed so it can mark every match in the sample text. That means you can still study all matches even if you forget to type g yourself, while the rest of your flags still behave as entered.

Text to Test is your sample corpus. Paste the exact kind of text you care about: a log line, an email body, a snippet of CSV, a block of HTML, or several lines copied from a real application. Unlike a calculator that starts with placeholder numbers, this tool intentionally begins with empty fields. That is deliberate. Regexes are all about context, so example defaults would often be more misleading than helpful. The best test text includes both positive examples that should match and negative examples that should stay untouched.

How the result panel behaves

After you click Test pattern, the page attempts to compile your input as a JavaScript regular expression. If the pattern is valid, every match in the sample text is wrapped in a highlight so you can inspect the exact span the engine consumed. The line beneath the preview reports how many matches were found and, when your pattern contains capture groups, shows the captured values from the first match. That small detail is practical when you are writing extraction regexes: it helps you confirm that the overall match is correct and that the groups inside it are also returning the pieces you expected.

The preview is escaped before display, so testing snippets that contain angle brackets or other HTML characters will not execute markup in the page. That makes the tool safer for experimenting with HTML fragments or user-generated content. The copy button gathers the visible highlighted result as plain text plus the match summary, which is handy when you want to paste the outcome into a ticket, a chat message, or a code review comment.

Formulas and matching model

A regex tester is not a numeric calculator in the usual sense, but it still maps a set of inputs to a result. In abstract terms, the output depends on the pattern, the selected flags, and the test text. The preserved MathML below expresses that idea in generic calculator form. On this page, the inputs are not dollars, hours, or kilograms; they are a pattern, modifiers, and source text. The point of the formulas is simply that the result changes predictably when the inputs change.

For regex testing, a more practical reading is this: the page builds a RegExp from your pattern and flags, scans the sample text for match spans, escapes the original text for safe display, and wraps each matched span in a mark element. The count in the summary is the number of returned match spans. So while there are no physical units to track here, there is still a model to sanity-check. If adding ^ and $ suddenly reduces many matches to zero, that is expected because you changed the scope from substring matching to full-string matching. If turning on i suddenly creates more hits, that is expected because case differences stop mattering.

Worked example

Suppose you want to find the standalone word “cat” in mixed-case text, but you do not want to match it inside longer words. Enter \bcat\b as the pattern, enter i as the flag, and test it against the sample text Cat, catapult, CAT, bobcat. The word-boundary markers \b say that the letters must sit at word edges, and the i flag says case should be ignored. The result should highlight Cat and CAT, while leaving catapult and bobcat alone because the letters are not isolated as a full word.

That example shows a good regex-testing habit: vary one idea at a time and watch the output shift. Remove the boundaries and the pattern becomes much broader because substrings inside longer words begin to qualify. Remove the i flag and uppercase CAT stops matching. In other words, the best way to understand a regex is not to stare at the syntax until it “feels right.” It is to run concrete text through it, then tighten or loosen the pattern intentionally until the preview matches your real-world goal.

Common JavaScript flags at a glance

The table below is not a replacement for testing, but it helps explain why the same letters can behave very differently once you change the modifiers.

How to interpret surprising output

If the preview says No matches found, that does not automatically mean the pattern is wrong. It may mean the text lacks the format you assumed, the case does not line up, an anchor is too strict, or an escape sequence is too narrow. Start by asking whether you are trying to match a whole field or just a piece of one. Anchors and word boundaries are common culprits because they are easy to forget and they sharply change the size of the allowed match.

If the page reports an Invalid regex error, the issue is usually structural: an unclosed parenthesis, an unterminated character class, an unsupported lookbehind in an older browser, or a malformed escape. This tester surfaces the JavaScript engine error directly so you can correct the syntax before moving on. When the output looks technically valid but semantically wrong, compare one controlled change at a time. Toggle i. Remove a quantifier. Replace .* with something narrower. Add sample lines that should fail. That deliberate workflow is much faster than making three edits at once and not knowing which one caused the change.

Zero-length matches are another special case worth remembering. Some patterns can match an empty position rather than a visible chunk of text. JavaScript still counts those matches, but they may not be visually dramatic in a highlighted preview because the consumed span has no width. Greedy quantifiers can cause the opposite problem: they consume far more text than you intended. When the preview appears to swallow entire sections of your sample, that is a clue that your pattern may need a tighter class, a boundary, or a non-greedy strategy.

Assumptions and limitations

This page uses the regex engine built into your current browser, so results follow modern JavaScript behavior. That matters because regex syntax varies by language. A pattern copied from a PCRE tutorial, a Python script, or a .NET project may need changes before it works here. The tester is excellent for JavaScript debugging, front-end validation experiments, and quick proof-of-concept work, but it should not be treated as a universal regex oracle for every programming environment.

• Flavor matters: browser JavaScript regexes are the reference behavior here, not server-side engines with extra features.
• Flags are filtered: only standard JavaScript flags are kept, and duplicates are removed before the regex is compiled.
• HTML is escaped: if you paste markup, the preview shows it safely as text rather than rendering it into the page.
• Large samples can feel slower: extremely long text combined with complex patterns can still be expensive because the browser is doing real regex work.
• Capture-group details are brief: the summary reports the first match’s groups, which is enough for debugging structure without overwhelming the page.

The best way to use this kind of tool is as a fast inspection surface. Test real examples, confirm a few negative cases, and then move the regex into your application with confidence. If a pattern is intended for security filtering, input validation with business consequences, or data migration at scale, treat this page as a verification step rather than the final authority. The browser view helps you see what the engine is doing; your production context still decides whether the pattern is appropriate.

A practical workflow for better regexes

Start with a small, literal version of the pattern that matches one obvious example. Then add only one advanced idea at a time: a boundary, a capture group, an optional segment, or a quantifier. Each time you change the pattern, rerun the same positive and negative examples. That sequence gives you a stable baseline and makes regressions obvious. It is also why blank inputs are a good design here. Instead of being nudged toward generic demo text, you can paste the exact data shape that matters to your task.

As you refine a pattern, keep at least one example that should pass and one that should fail. For an email-like regex, test a normal address, a missing-at-sign case, and a malformed domain. For code extraction, test the exact code format plus near misses that differ by one character. A regex often looks perfect until you place a realistic near miss beside it. The highlighted preview is especially good at revealing where a pattern is overreaching, because you can literally see whether the engine selected too much text, not enough text, or the wrong slice entirely.

Finally, use the result summary as a checkpoint rather than a victory message. A high match count is only useful when the matched spans are the ones you actually wanted. Read the preview line by line, especially after adding broad constructs such as .*, nested groups, or alternation. If the matches stay stable while you introduce more precise rules, your pattern is becoming more reliable. If the preview suddenly changes in a surprising way, the page has already done its job by exposing the problem early, before that regex reaches production code or a fragile data-cleanup script.