Test Your Regex in the Browser: 5 Real Bugs + a Free Online Tester

Every week I lose 20 minutes to the same dumb regex bug. Not a clever one — a dumb one. The pattern looks right, the test string looks right, and the match count says 0.

Regex has a tiny set of failure modes and they repeat forever. Here are the five I actually hit, with the fix for each. Paste them into any tester as you read — seeing the match change is the whole lesson.

1. Greedy .* eats your whole string

You want the quoted words out of this:

say "hi" then "bye"

Pattern ".*" matches "hi" then "bye" — one giant match, because .* is greedy and grabs as much as it can.

Fix: make it lazy with ?:

".*?"

Now you get "hi" and "bye" separately. If you want the inside without quotes, capture it: "([^"]*)" — group 1 holds the words.

2. ^ and $ don't mean "start of line" by default

Multiline log:

error 404 page missing
error 500 db down

Pattern ^\w+ \d+ matches only the first line. Without the m (multiline) flag, ^ means "start of the whole string", not "start of each line".

Fix: turn on the m flag. Then both lines match. This is the #1 reason a pattern "works on one line but not on the file."

3. The dot doesn't match newlines

start
middle
end

Pattern start.*end matches nothing — . matches any character except a newline.

Fix: use [\s\S]* instead of .*:

start[\s\S]*end

(\s = whitespace including newlines, \S = everything else, together = literally everything.) In JavaScript you can also use the s (dotAll) flag — start.*end with s on — but [\s\S] works in every flavor.

4. You forgot to escape the special characters

Matching an IP address:

\d+.\d+.\d+.\d+

This "works" on 192.168.1.1 — and also happily matches 192x168y1z1, because an unescaped . means any character. It passes your test, then breaks in production on real data.

Fix: escape the dots:

\d+\.\d+\.\d+\.\d+

Rule of thumb: if you typed . * + ? ( ) [ ] { } ^ $ | \ and you meant the literal character, put a backslash in front of it.

5. Capturing groups you never needed

(\d{4})-(\d{2})-(\d{2})

matches 2026-10-23 and gives you 3 groups. Fine. But this:

(foo|bar|baz)+

captures a group on every repetition you never look at, which clutters the match table and (on huge inputs) costs time.

Fix: non-capturing groups with (?:...):

(?:foo|bar|baz)+

Same match, no junk groups. Use (...) when you need the captured value; (?:...) everywhere else.

A debugging workflow that actually works

1. Paste real sample text, not a toy one-liner — bugs hide in the second line.
2. Toggle one flag at a time (i, m, s) and watch the match count change.
3. Read the groups table, not just the highlight — half of regex bugs are "it matched, but captured the wrong part."

The free tester I built

I make BulkTextKit — 15 free text tools that run 100% in your browser, nothing uploaded. The Regex Tester is the one I open myself: live match highlighting with positions, captured groups in a table, flag toggles for ignore-case / multiline / global, JavaScript's RegExp engine (the same syntax your Node and browser code uses), up to 500 matches shown.

One line on Pro: BulkTextKit Pro ($19 one-time, no subscription) adds Bulk mode — test one pattern against up to 50 texts at once instead of pasting them one by one.

What's the dumbest regex bug that's ever cost you an hour? I want to feel less alone in bug #2.