Regex Tester & Builder

I built this after debugging the same class of regex bug in three different projects in one month — a pattern that worked fine in testing and then matched way more than intended the moment it hit real-world data with HTML tags, or quotes, or repeated delimiters in it. Regex is genuinely useful and genuinely easy to get subtly wrong, and staring at a wall of backslashes in your editor is a bad way to catch that. Seeing the match highlighted against real text is a much better way.

How it works

The engine underneath this tool is just JavaScript's built-in RegExp — the exact same one running in your browser's console, so anything that matches here will match identically in your actual code. It reads your test text character by character, and at each position it tries to line up your pattern; if a full match isn't possible from that character, it moves one character forward and tries again. With the g flag it keeps going after each match to find every occurrence; without it, it stops at the first one. When a pattern has some ambiguity in it — say a quantifier that could grab 3 characters or 30 — the engine uses backtracking: it tries the greedy option first, and if the rest of the pattern fails to match afterward, it backs off one character at a time until something works. That backtracking is powerful, but it's also where the two most common regex bugs live.

A real example — the greedy-dot bug

Say you're trying to pull the content out of the first HTML tag in <div class="a">Hi</div><span>Bye</span>, and you write <.+>. Because + is greedy by default, it matches as much as it possibly can and still succeed — which means it grabs everything from the first < all the way to the very last > in the string: the entire thing, both tags included. Add a ? right after the quantifier — <.+?> — and it becomes lazy, matching as little as possible, so it correctly stops at the first > and gives you just <div class="a">. This single character is responsible for more "why is my regex matching the whole file" questions than anything else.

Common mistakes

• Forgetting anchors on validation patterns. \d{5} without ^ and $ will happily "validate" the string "abc12345xyz" as a valid 5-digit ZIP code, because it just finds 5 digits somewhere in there. If you're validating a whole field, anchor it: ^\d{5}$.
• Nested quantifiers that cause catastrophic backtracking. A pattern like (a+)+b run against a long string of a's with no trailing b can make the engine try an exponential number of ways to fail, freezing the tab. This tool's performance analyzer flags these shapes before you paste them into production code where they might hit a much longer input and take down a request.
• Not escaping the characters that mean something to regex. A literal period in an IP address or a version number needs to be \., not . — an unescaped dot matches any character, so 192.168.1.1 written as a pattern would also match 192a168a1a1. It rarely bites you in testing because your test string is usually well-formed; it bites you in production when it isn't.