What is this calculator for?
You're debugging a form validation regex that's rejecting valid emails. Or you need to extract all phone numbers from a 2,000-line log file. Or you're learning regex from scratch and need an interactive playground to test patterns. The regex tester lets you build, test, and debug regular expression patterns against sample text in real time — seeing matches highlighted, capture groups identified, and error messages explained.
Regular expressions (regex) are a pattern-matching language for text. Used in: form validation (email, phone, URL formats), search and replace operations, log parsing, data extraction, syntax highlighting, configuration files. Every modern programming language supports regex with slight syntax variations. The basics: literal characters (a, b, 1, 2) match themselves; metacharacters (., +, *, ?, [], (), {}) have special meaning. Combining these into patterns lets you describe text categories precisely.
This tool tests patterns against input text, highlighting matches and showing capture groups. Supports common regex flavors (PCRE / JavaScript / Python style). Use to verify your pattern before deploying to production code.
How to use this calculator
Enter your regex pattern (e.g., \d{3}-\d{3}-\d{4} for phone numbers) and the test text you want to match against. The tool highlights matches in real time as you adjust the pattern.
Use flags to modify behavior: i (case-insensitive), g (global, find all matches not just first), m (multiline), s (dotall — . matches newlines too).
For capture groups: parenthesize portions of the pattern you want to extract. (\d{3})-(\d{3})-(\d{4}) matches phone numbers AND captures the three parts separately. Useful when extracting structured data from text.
For common patterns: email ^[\w.+-]+@[\w-]+\.[\w.-]+$. US phone \(?\d{3}\)?[-. ]?\d{3}[-. ]?\d{4}. URL https?://[\w.-]+(?:/[\w./?%&=-]*)?. Date YYYY-MM-DD \d{4}-\d{2}-\d{2}. SSN \d{3}-\d{2}-\d{4}. Hex color #[0-9a-fA-F]{6}.
Understanding your results
The tester returns matched substrings, capture groups for each match, and execution time information.
Regex syntax essentials. Metacharacters: . (any character except newline), \d (digit), \D (non-digit), \w (word char: letter, digit, underscore), \W (non-word), \s (whitespace), \S (non-whitespace). Quantifiers: * (0+), + (1+), ? (0 or 1), {n} (exactly n), {n,m} (n to m). Anchors: ^ (start of line/string), $ (end), \b (word boundary). Character classes: [abc] (a, b, or c), [^abc] (NOT a, b, c), [a-z] (range). Groups: () (capture), (?:) (non-capture), (?=) (lookahead), (?<=) (lookbehind).
Common regex pitfalls. Greedy vs lazy quantifiers: .+ is greedy (matches as much as possible); .+? is lazy (matches as little as possible). For matching content between tags: lazy is usually what you want. Escape special characters: . in regex means "any character"; to match a literal dot, escape as \.. Same for parentheses, brackets, plus, etc. Anchors matter: ^abc$ matches only strings that ARE exactly "abc"; without anchors, matches "abc" anywhere in the string.
Email validation reality. The "perfect" email regex is hundreds of characters long because the email spec (RFC 5322) is complex. For practical use: a simple pattern like ^[\w.+-]+@[\w-]+\.[\w.-]+$ covers 99% of real emails and rejects most invalid ones. Trying to perfectly validate emails with regex is a rabbit hole; better practice is rejecting obviously-malformed, then sending a confirmation email (deliverability = truth).
Performance considerations. Catastrophic backtracking: poorly-written regex patterns can have exponential runtime on certain inputs. (a+)+ against a long string of "a" characters can take exponentially long. For production code: test regex performance with large inputs; consider compiled regex if used repeatedly; use non-capturing groups when capture isn't needed.
A worked example
Marcus needs to extract all dates from a log file. Format example: "2025-03-14T08:42:15Z user login successful." He wants to extract just the date portion (YYYY-MM-DD).
Pattern attempt 1: \d{4}-\d{2}-\d{2}. Tests in regex tester against sample log lines. Matches "2025-03-14" correctly. But also matches "1234-56-78" (clearly not a real date) — too loose. Acceptable for his use case since log file only contains real dates.
For tighter validation: (?:19|20)\d{2}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01]). This validates year starts with 19 or 20, month is 01-12, day is 01-31. Rejects "1234-56-78." Trade-off: longer, harder to read, more potential for bugs. For most use cases, the simpler pattern is fine.
Extension: he wants to capture year, month, day separately. Pattern: (\d{4})-(\d{2})-(\d{2}). Now each match returns 3 capture groups for analysis (count occurrences per month, per year, etc.).
Variation: Lin is validating phone numbers in a registration form. She wants to accept multiple formats: "555-123-4567", "(555) 123-4567", "555.123.4567", "5551234567". Pattern: ^\(?(\d{3})\)?[-. ]?(\d{3})[-. ]?(\d{4})$. Tests against each format — all match correctly. Also captures area code, prefix, and line number separately for processing. The pattern doesn't validate that the number is real (no way to do that with regex alone), just that the format is plausible.
Caveat: she also needs to reject obviously fake numbers (555-555-5555, 000-000-0000). She adds an explicit reject pattern in code, post-regex-match. Regex handles format validation; business logic handles content validation. Trying to encode "not all 5s" in regex is possible but ugly; cleaner to do it in code.
Related resources
For general text manipulation, see Word Counter and Case Converter. For URL encoding (often paired with regex for URL extraction), the URL Encoder. Regex101 is the most popular interactive regex tester with detailed pattern explanations; RegExr is another popular interactive tool; Regular-Expressions.info is the comprehensive reference for regex syntax and theory.