Free · Fast · Privacy-first

Regex Debugger Online, Fix Patterns That Do Not Match

When a regex does not match what you expect, debugging it manually inside application code is slow and frustrating.

⚡

Highlights both matching and non-matching segments

🔒

Shows capture group values and positions

✨

Displays error messages for invalid patterns

⚡

Live feedback, no page reload needed

Cost: Free tier
Sign-up: Not required
Processing: Tool-specific
Privacy: Clearly disclosed

IframeResponsiveAttribution included

Add this Regex Tester to your website

Drop the Regex Tester into a blog post, product docs, intranet, or school portal with one iframe. Processing, privacy, and usage limits are the same as on the full tool page.

One copy-ready line of HTML
Responsive — adapts to any container width
No API credentials are placed in the snippet

Embed code

<iframe
  src="https://www.fixtools.io/developer/regex-tester?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Regex Tester by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/developer/regex-tester?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Regex Tester by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

How to Isolate and Fix a Failing Regex Pattern

Regex debugging is the process of understanding why a pattern fails to match expected input, matches unexpected input, or captures the wrong content. The challenge is that pattern failures are silent: a regex either produces a match object or it does not, with no built-in indication of where the engine stopped or which alternative branch it abandoned. This silence makes regex one of the harder things to debug inside a full application where many variables can influence the outcome. Isolating the pattern in a dedicated tester is the single most important step: it removes all surrounding code from the equation and forces the problem down to the pure relationship between the pattern and the input text.

The NFA engine that powers JavaScript regex uses ordered alternation and backtracking. When a pattern fails, the engine has exhausted all possible paths through the input without assembling a complete match. Common causes include: anchors (^ or $) that prevent matching a substring when the anchoring is incorrect, a character class that excludes a character present in the input, a quantifier that requires more repetitions than the input contains, or a special character like . or + that was not escaped where a literal character was intended. Understanding which of these is the culprit is much faster when you can see the pattern highlighted against real input and remove or change one token at a time to observe what changes.

The most effective debugging strategy is binary isolation: cut the pattern in half, test each half independently, and identify which half fails to produce the expected match. Then cut the failing half again. Within three or four iterations of this process you will have narrowed the problem to a single token or quantifier that is responsible for the mismatch. This binary approach works regardless of pattern complexity and is consistently faster than reading the full pattern from left to right trying to identify an error by visual inspection alone, especially for patterns longer than 30 or 40 characters.

Catastrophic backtracking deserves a dedicated mention in any debugging discussion because it presents as a different class of failure than a normal mismatch. Instead of the engine quickly returning no match, the browser tab hangs for several seconds or freezes entirely. The cause is almost always nested or overlapping quantifiers: patterns like (a+)+b, (\w+\s?)+$, or (a|aa)+ applied to a string that almost satisfies the pattern but ends with a non-matching character. The engine explores an exponentially growing tree of possible match paths before declaring failure. In the debugger, this appears as the highlight area freezing, sometimes followed by a browser warning about an unresponsive script. The diagnostic move is to shorten the input progressively until the freeze disappears, then rewrite the pattern using negated character classes such as [^a]*a in place of nested groups so the engine cannot revisit consumed positions.

MDN Regular Expressions guide PCRE syntax reference

How to use this tool

💡

Paste your failing regex pattern and the test string it should match. The debugger shows where the match breaks down so you can identify and fix the issue quickly.

How It Works

Step-by-step guide to regex debugger online, fix patterns that do not match:

1
Enter your broken pattern
Paste the regex pattern that is not working as expected into the pattern field. If your pattern came from a code file where it was stored as a JavaScript string, convert double backslashes (\\d) back to single backslashes (\d) before pasting: the tester accepts raw pattern syntax without the extra escaping required inside string literals.
2
Add your test string
Enter the specific string your pattern should match, or a representative sample from the input set that is currently failing. Use the shortest failing input you have: a compact example makes it far easier to see where the match breaks than a 500-character string where the failed match position is buried in the middle.
3
Check the results
If the pattern contains a syntax error, an error message appears below the pattern field explaining the problem. If the pattern is syntactically valid but produces no match highlights, the pattern is not matching the input. Compare the non-highlighted regions of the test string against the pattern tokens to identify which part of the input the pattern is failing to traverse.
4
Adjust the pattern
Edit your pattern incrementally using the binary isolation strategy: remove the second half of the pattern and test, then restore and remove the first half. Once you identify the failing segment, change one token at a time and watch the match highlighting update in real time to find exactly where the mismatch occurs.
5
Confirm the fix
Once the match highlights cover the expected portions of the test string and capture groups display the correct values, copy the corrected pattern back into your code. Also test the fixed pattern against several additional inputs including edge cases to confirm the fix is general and not just valid for the single failing example you used during debugging.

Real-world examples

Common situations where this approach makes a real difference:

Diagnosing a validation pattern that rejects legitimate inputs

A developer notices that a password validation regex rejects valid passwords containing certain special characters. Pasting the pattern and a rejected password into the debugger immediately reveals which character class is too restrictive, because the non-matching region of the password highlights precisely which character is causing the failure. Adjusting the character class in the tester and confirming the password now matches before touching production code prevents an iterative deploy-and-test cycle that would take 20 or more minutes per attempt on a deployed service.

Fixing a log-parsing regex that stops matching after a format change

When a logging library updates its output format, a downstream parsing regex silently stops matching and the pipeline begins producing empty fields. Loading the new log sample and the old pattern into the debugger shows exactly which token no longer aligns with the updated format. In a common case, a date separator changed from a hyphen to a slash, and the character class in the timestamp group needs a single character added to resume matching. The fix is visible in the tester in under two minutes.

Resolving a capture group that returns undefined

A data extraction script receives undefined for an expected capture group in some records but not others. Pasting a failing record into the tester alongside the pattern reveals that the group is inside an optional branch that does not match when a particular field is absent from that record format. The results panel clearly shows which groups are populated and which are empty. The fix involves adjusting the quantifier on the surrounding group or adding a fallback alternative that provides an empty string instead of undefined.

Understanding catastrophic backtracking before production deployment

Before deploying a user-configurable regex to a service that processes untrusted input, a developer tests worst-case non-matching strings in the tester. A pattern with nested quantifiers applied to a long string of characters that almost but do not quite match causes noticeable browser lag, flagging a catastrophic backtracking risk before the pattern reaches production. The pattern is rewritten with a negated character class that eliminates the backtracking paths, and the revised version processes the same worst-case input instantly.

Pro tips

Get better results with these expert suggestions:

Simplify to the shortest failing case first

Copy the shortest substring from your test input that the pattern should match but does not. Testing against a five-character string rather than a 500-character block eliminates visual noise and makes it immediately obvious whether the failure is in the pattern core or in an edge case specific to the longer input. Once you confirm the pattern fails on the short string, the debug problem is cleanly isolated and takes only a few iterations to resolve.

Remove anchors to test partial matching

If a fully anchored pattern (^...$) fails to match, temporarily remove the anchors and test again. If the pattern then matches as a substring within the input, the core pattern logic is correct and the problem is with your anchor placement or the flags that are active. This tells you exactly what to fix: the pattern tokens are not the issue, only the boundary assertions are. Re-add anchors one at a time to confirm which anchor is wrong.

Test one quantifier at a time

When a quantifier is suspected, replace it temporarily with a literal repetition of the token. Replace \d{3} with \d\d\d to confirm the pattern works with exactly three digit positions before reintroducing the quantifier syntax. If the literal version matches but the quantifier version does not, the issue is in the quantifier bounds or syntax rather than the token itself. This two-step test narrows the problem to a single cause.

Check for invisible characters in pasted input

Copy-pasted strings from PDFs, terminal output, or rich text editors sometimes contain invisible Unicode characters such as zero-width spaces (U+200B) or non-breaking spaces (U+00A0) that are visually identical to regular spaces but are not matched by \s in some contexts or by the space character class in others. If a pattern inexplicably fails on pasted input but succeeds on manually typed input, the pasted string contains invisible characters that are not in the pattern.

FAQ

Frequently asked questions

The most frequent causes are: missing the global flag when expecting multiple matches and only the first is returned, using ^ and $ anchors on a search pattern where substring matching is intended, forgetting to escape a special character such as . * + ? ( ) [ ] { } that has a meaning in regex syntax, using a character class that excludes a character present in the input, applying a quantifier that requires more occurrences than the input contains, and case sensitivity mismatch when the i flag is absent. Start diagnosis by removing the pattern to its simplest matching token and rebuilding it piece by piece until the mismatch reappears.

The FixTools Regex Tester displays an error message directly below the pattern field whenever your regex has a syntax error, along with a description of what went wrong. All match highlights clear immediately when a syntax error is present. Common errors that trigger this message include unmatched opening or closing parentheses, brackets without a closing counterpart, invalid quantifier ranges such as {5,2} where the minimum is greater than the maximum, escape sequences that are not valid in Unicode mode, invalid Unicode property names in \p{} syntax, and characters used as flags that are not recognised by the JavaScript engine.

If the pattern is syntactically valid but produces no match highlights in the test string, the pattern does not match the input under the current flags. Check anchors first: a pattern anchored with ^ and $ will only match if the entire string conforms to the pattern. Check character classes next: a class like [a-z] will not match uppercase letters without the i flag. Check quantifier minimums: \d{3} requires exactly three digits in sequence. Try removing the pattern down to a single literal character that you can see in the input, confirm it matches, and then build the pattern back up from that working starting point.

First verify that your parentheses are correctly placed and that they are not preceded by the ? character that converts them to a non-capturing group (?:...). Check that the group is not inadvertently escaped with a backslash. Confirm the group is located inside the part of the pattern that is actually matching by temporarily removing everything outside the group and testing the group alone. Also confirm that the branch containing the group is participating in the match: a group inside an optional or alternative branch that is not chosen will always return undefined rather than an empty string.

Yes. Enter multiple test strings on separate lines and enable the m flag to test boundary behaviour across all of them simultaneously. Include a range of inputs that covers the full variety of data your pattern will encounter in production: typical valid cases, minimum-length valid cases, maximum-length valid cases, inputs with only special characters, inputs with Unicode characters outside the ASCII range, and inputs that are specifically designed to be close to valid but should be rejected. Seeing all cases highlighted or not highlighted in a single view makes it easy to spot gaps in coverage before writing any code.

Catastrophic backtracking occurs when a pattern contains nested or adjacent quantifiers that can match the same characters in multiple ways, such as (a+)+ or (\w+\s?)+, applied to a string that almost but does not quite match the full pattern. The engine explores an exponentially growing number of path combinations before concluding there is no match. In the tester, this appears as noticeable lag, a frozen browser tab, or a browser warning about an unresponsive script. Fix it by replacing nested quantifiers with possessive quantifiers if available, or more practically, by substituting nested quantifiers with negated character classes that prevent re-entering the same character positions.

Over-matching usually indicates a quantifier is too greedy. Switch all greedy quantifiers to their lazy equivalents by appending ? after each *, +, or {n,m} and observe whether the highlighted match narrows to the intended range. If lazy matching produces the correct result, consider whether a negated character class such as [^<] would be a more robust and readable solution than relying on lazy semantics, especially for matching content between delimiters like HTML tags where greediness produces incorrect spanning matches.

Start in the online tester. It provides faster iteration, visual match feedback, and a completely isolated environment without any application setup. Paste the pattern and a failing input, identify the fix, and copy the corrected pattern back to your IDE. Reserve IDE-based debugging for issues that only manifest in the context of your full application: situations where the string encoding, multi-pass processing, or how the pattern interacts with surrounding application logic is itself the source of the unexpected behaviour rather than the pattern expression itself.

The most common culprit is flavour differences. Java's Pattern class requires double-escaping in string literals (\\d instead of \d) and uses (?<name>...) for named groups in modern versions but treated lookbehinds as fixed-length until JDK 13. .NET Regex supports balanced groups using (?<open>) and (?<-open>), an unusual feature that has no JavaScript equivalent. Some shorthand classes also behave differently: .NET's \w includes Unicode letters by default, while JavaScript's \w stays ASCII-only even with the u flag. Before assuming the pattern is broken, paste it into a flavour-specific tester for your target language, or rewrite ambiguous shorthand classes using explicit character ranges so the meaning is unambiguous across every engine.

When a pattern works on typed examples but fails on pasted production input, the issue is usually invisible characters rather than the regex itself. Open your browser console and run input.charCodeAt(i) on each character of the failing input to find code points that look like ASCII but are not. The usual offenders are U+00A0 (non-breaking space), U+200B (zero-width space), U+FEFF (byte-order mark) at the start of files, and U+2028 (line separator) in PDF-sourced text. Once you confirm encoding is the cause, the fix is either preprocessing the input to normalise whitespace, or widening your pattern's whitespace class to [\s\u00A0\u200B] so the unusual characters are matched explicitly.