Regex Tester
Write a regular expression, test it against sample text, and see matches highlighted live — with capture groups broken out individually so you’re not squinting at a wall of matched text trying to figure out which group is which.
Why test regex before shipping it
Regular expressions are notoriously easy to get almost right. A pattern that works perfectly on your three test cases can silently fail on the fourth — an email with a + in it, a phone number with parentheses, a filename with a space. Testing against a broader set of real examples before committing a regex to production code (form validation, log parsing, data cleaning scripts) catches these edge cases early, when they’re a two-second fix instead of a production bug report.
How to use it
- Type your pattern into the regex input field. Flags (global, case-insensitive, multiline, etc.) are toggleable as checkboxes rather than needing to be memorized as letter codes.
- Paste your test string — a single line, a paragraph, or a whole log file — into the text area below.
- Matches highlight in the test string in real time as you edit the pattern, so you can see immediately whether a tweak fixed or broke something.
- Capture groups (both numbered and named) are listed separately below the match, so
(\d{4})-(\d{2})-(\d{2})shows you exactly what landed in group 1, 2, and 3 for each match. - A plain-English breakdown panel explains what each part of your pattern is doing — useful both for double-checking your own logic and for understanding a regex you inherited from someone else’s code.
- Use the “generate code” option to get your tested pattern pre-formatted as a working snippet in JavaScript, Python, or a few other common languages, with the correct escaping and flags already applied.
Common situations this solves
- Validating form input (emails, phone numbers, postal codes) against real-world examples before deploying validation logic.
- Debugging why a regex isn’t matching something you’re certain it should, by isolating the pattern from the surrounding code and testing it in true isolation.
- Extracting structured data from unstructured text — log lines, CSV-like text, scraped HTML — using capture groups to pull out just the fields you need.
- Reverse-engineering an unfamiliar regex you found in a codebase, using the plain-English breakdown to understand what it’s actually matching.
- Testing find-and-replace patterns before running them against a real file, since a regex replace with the wrong pattern can silently mangle data with no easy undo.
Frequently asked questions
Which regex flavor does this use — PCRE, JavaScript, Python? The default engine follows JavaScript’s native regex implementation (ECMAScript), since that’s what runs in-browser. There’s a flavor selector to approximate PCRE or Python-style syntax differences (like named group syntax, which differs slightly between engines), though for advanced flavor-specific features you should always do a final test in your actual target language before shipping.
Why does my pattern match in the tester but not in my code? The most common causes are: missing or extra flags (especially the global g flag, which changes how .exec() behaves across repeated calls in JavaScript), differences in how the string is escaped in your source code versus pasted directly here, or a difference in regex flavor between the tester and your runtime environment. Double-check flags first — it’s the single most common mismatch.
What’s the difference between greedy and lazy matching, and how do I see it here? Greedy quantifiers (*, +, {n,}) try to match as much text as possible, while their lazy counterparts (*?, +?, {n,}?) match as little as possible before backing off. Toggle between a greedy and lazy version of the same pattern against the same test string in this tool and watch the highlighted match region change size — it’s the fastest way to build intuition for this if it hasn’t clicked yet.
Can I test multiline patterns, like matching across line breaks? Yes — paste multiline text directly into the test area, and use the multiline (m) and dotall (s) flag toggles to control whether ^/$ match at line boundaries and whether . matches newline characters, respectively.
Does this support lookaheads and lookbehinds? Yes, both positive and negative lookaheads ((?=...), (?!...)) and lookbehinds ((?<=...), (?<!...)) are supported and will highlight correctly in the match preview, since these are standard in the JavaScript regex engine this tool runs on.