Regex Tester

How to test regular expressions with this tool?

Testing and debugging regular expressions requires seeing exactly what your pattern matches in context. This regex tester provides instant visual feedback with detailed match information:

• Enter your regular expression pattern in the Pattern field without delimiters. For example, enter \d{3}-\d{4} to match phone number formats like 123-4567, or [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,} to validate email addresses. The pattern uses JavaScript RegExp syntax, which supports most standard regex features including character classes, quantifiers, anchors, groups, and lookahead assertions.
• Select the flags that apply to your pattern: g (global — find all matches, not just the first), i (case-insensitive — match regardless of letter case), m (multiline — ^ and $ match line boundaries instead of string boundaries), s (dotall — let . match newline characters), or u (unicode — enable full Unicode support for \\w, \\d, and other shorthands). Multiple flags can be combined, such as 'gi' for global case-insensitive matching.
• Paste or type your test text in the main text area. As you type, all matches are highlighted in distinct colors directly within your text. Each unique match receives a different color, making it easy to visually distinguish between multiple occurrences. Clicking on a match in the result list below scrolls the corresponding highlight into view.
• Review the detailed match information displayed below the text area. For each match, you see the matched value, its starting position (character index), ending position, and any captured groups with their values and positions. This granular detail is essential for debugging complex patterns and verifying that your groups capture exactly what you expect.

Building regex patterns systematically

Effective regex construction follows a methodical approach rather than trial-and-error guessing. Start by identifying the exact structure you want to match — break it down into components. For a US phone number like (555) 123-4567, the components are: opening parenthesis, three digits, closing parenthesis, optional space, three digits, hyphen, four digits. Translate each component to regex: \( matches the literal open paren, \d{3} matches exactly three digits, \) matches the literal close paren, ? makes the space optional, and \d{4} matches four digits. Combine them: \(\d{3}\) ?\d{3}-\d{4}. Test incrementally — verify each component works before adding the next. Common pitfalls include forgetting to escape special characters (parentheses, brackets, dots, asterisks, plus signs, question marks, caret, dollar signs, backslashes all need escaping with \ when used literally), using greedy quantifiers when lazy ones are needed (* vs *?), and forgetting that ^ and $ anchor to string boundaries unless the multiline flag is set. Practice with progressively complex patterns builds intuition faster than memorizing syntax.

Debugging regex patterns when they don't match

When a regex pattern fails to match expected text, systematic debugging saves hours of frustration. First, simplify: strip away everything except the core part of your pattern and verify it matches a minimal example. Then add complexity one piece at a time. Second, check your escaping: unescaped special characters are the #1 cause of unexpected behavior. A dot (.) matches any character, not a literal period — you need \.. Third, verify your flags: searching for uppercase letters with [A-Z] without the 'i' flag won't match lowercase text. Using ^ and $ on multi-line text without the 'm' flag only checks the very beginning and end of the entire string. Fourth, consider quantifier greediness: the pattern .* will consume as much text as possible, potentially swallowing content you intended to match later. Use .*? (lazy) when you want the shortest match. Fifth, check character class boundaries: [a-z] matches lowercase letters but not uppercase; [a-zA-Z] is needed for both. Sixth, watch for invisible characters: tabs, carriage returns, and zero-width spaces in your test text can prevent matches that seem like they should work. Copy-paste clean test data from reliable sources when debugging.