Regex Tester
Test regular expressions against sample text with live match results.
How to Use
- Enter a regex pattern and optional flags
- Paste text to test against
- Click "Test Regex" to see matches
- Copy match results if needed
Features
- Instant match listing with indices
- Supports common regex flags
- Client-side testing for privacy
Regex Fundamentals
Regular expressions are pattern-matching rules used to search or transform text.
Safety and Accuracy Tips
- Escape special characters when you want a literal match (for example \.).
- Use anchors like ^ and $ when validating full input.
- Prefer Unicode-aware patterns for international text handling.
- Review complex patterns for performance on large inputs.
How Regex Testing Fits into Real Debugging
Regex testing is most useful when you are moving between examples and real input. A pattern that matches a toy string can fail immediately when whitespace, punctuation, Unicode characters, newlines, or repeated groups appear in production data. Testing against representative samples is what separates a clever pattern from a reliable one.
Seeing match indices and grouped captures is also valuable because many regex bugs are not no-match failures. They are off-by-one errors, partial captures, greedy overmatching, or patterns that accidentally succeed on too much input.
Common Regex Mistakes
One common mistake is forgetting that regex engines differ across languages and platforms. A pattern copied from PCRE, Python, Java, or a database engine may not behave the same way in JavaScript. Inline flags, lookbehinds, Unicode classes, and backtracking behavior are common sources of confusion.
Another mistake is using regex where a parser would be safer. Regex is excellent for matching structured text fragments, log lines, identifiers, and validation patterns, but it becomes fragile when asked to fully parse complex grammars such as nested programming languages or malformed HTML.
Performance and Safety
Complex patterns can become slow when they trigger excessive backtracking. Nested quantifiers, broad wildcard groups, and ambiguous alternation often look harmless in short examples but perform poorly on long input. Testing against bigger samples helps reveal whether a pattern is merely correct or also practical.
Browser-side testing is useful here because you can experiment privately with production-like text fragments, tune anchors and quantifiers, and verify capture groups before moving the pattern into application code, CI checks, or log analysis rules.
Worked Example: Input Validation
A common regex task is validating input such as email-like identifiers, reference codes, slugs, timestamps, or file names. The trouble is that a pattern can seem perfect until it meets messy real-world data. A username field might include trailing spaces, an imported CSV may contain carriage returns, or an identifier copied from a ticket might include punctuation you did not expect. Testing with representative samples is what reveals whether the pattern really matches the operational data instead of only matching the simplified cases you imagined while writing it.
That is also why the surrounding workflow matters. Regex can be a useful first filter, but many validation problems still need normal application logic after the match. A tester page is valuable when it makes those boundaries obvious: use regex to narrow and structure input, then rely on application rules for anything that involves meaning, permissions, or multi-step business checks.
Search, Replace, and Capture Groups
Regex is not only about yes-or-no matching. It is widely used for search-and-replace operations, log extraction, parsing semi-structured text, and grouping repeated patterns inside larger documents. In those cases, the capture groups are often more important than the overall match. If the pattern captures the wrong segment, shifts a group boundary, or greedily swallows neighboring text, the downstream replacement or parser can quietly produce bad output even though the test initially appears successful.
That is why seeing explicit match results matters. A pattern that says "matched" is not enough for serious work. Users need to know what matched, where it matched, and whether the grouped data lines up with how the consuming code will interpret it. A browser-side tester is a good fit for that because it gives immediate feedback while you refine the pattern one step at a time.
Engine Differences and Migration Risk
Regex patterns often move between tools: an expression may start in a text editor, then land in JavaScript, then end up copied into a CI rule, a gateway filter, or a database query. That movement creates risk because regular expression engines are similar enough to look compatible while still differing in important ways. Features like lookbehind support, Unicode classes, multiline handling, and escaping rules can change whether the same pattern is valid or effective across environments.
A practical testing page therefore has value even if it targets only one engine. It gives users a grounded place to verify what JavaScript will actually do, which is often the right answer for browser form validation, client-side filtering, and utility scripts. The educational content is there to stop users from overgeneralizing a working result into "regex works the same everywhere," because that assumption is responsible for many quiet production bugs.
Why This Tool Stays Narrow
This page is intentionally a tester, not a full parser workbench. It does not attempt to benchmark every engine or prove that a pattern is semantically correct for every platform. Instead, it focuses on the jobs users repeatedly need: enter a pattern, try flags, test realistic text, inspect the matches, and catch obvious problems before the pattern is baked into code or configuration.
That narrow browser-side scope is useful in its own right. Teams can try patterns against real examples privately, without uploading internal logs or customer data fragments to an unknown service. For a utility site, that combination of modest scope, fast feedback, and clear limitations is stronger than pretending that regex can safely solve every text-processing problem on its own.
Which Regex Flavor Does This Tool Use?
This tool tests patterns using JavaScript's built-in RegExp engine, often called the ECMAScript regex flavor. It supports named groups, lookahead, and lookbehind, but it is not identical to PCRE, Python's re module, .NET, or database-specific regex engines. If you copy a pattern from another language, re-test it here before trusting it in JavaScript code.
Regex Syntax Reference
Use this table as a quick reference for the JavaScript (ECMAScript) regex syntax supported by this tool.
| Category | Pattern | Meaning |
|---|---|---|
| Character classes | [abc] [^abc] [a-z] . |
Match a set of characters, a range, or any character except a set. |
| Predefined classes | \d \D \w \W \s \S |
Shorthand for digits, word characters, and whitespace (and their opposites). |
| Anchors | ^ $ \b \B |
Match a position rather than a character: start/end of string or line, or a word boundary. |
| Quantifiers | * + ? {n} {n,} {n,m} |
Control how many times the preceding token can repeat. |
| Lazy quantifiers | *? +? ?? {n,m}? |
Match as few characters as possible instead of the default greedy behavior. |
| Groups | (...) (?:...) (?<name>...) |
Group part of a pattern to apply a quantifier, capture the matched text, or both. |
| Alternation | a|b |
Match one of several alternatives, separated by |. |
| Lookahead | (?=...) (?!...) |
Assert that a pattern does (or does not) follow, without including it in the match. |
| Lookbehind | (?<=...) (?<!...) |
Assert that a pattern does (or does not) precede, without including it in the match. |
| Flags | g i m s u y |
Change how the whole pattern is applied: global, case-insensitive, multiline, dot-matches-newline, Unicode, or sticky matching. |
Worked Examples
Paste any of these patterns into the tool above along with some matching sample text to see them in action.
Email Address
/^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$/
A practical (not fully RFC-5322-compliant) pattern for validating typical email addresses.
URL
/^https?:\/\/[\w.-]+\.[a-zA-Z]{2,}(?:\/\S*)?$/
Matches http/https URLs with an optional path, without validating every edge case of the URL spec.
Phone Number (US-style)
/^\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}$/
Matches common US phone number formats with optional parentheses, spaces, dots, or dashes. International formats vary widely and need a different pattern.
Date (YYYY-MM-DD)
/^\d{4}-\d{2}-\d{2}$/
Matches the shape of an ISO-style date. It checks the format only — it will still match an impossible date like 2026-02-30, so pair it with real date validation when correctness matters.
Extracting Capture Groups
/^(\d{4})-(\d{2})-(\d{2})$/
Wrapping parts of a pattern in parentheses captures them separately. Testing the date pattern above with groups splits it into year, month, and day, which is exactly what this tool's Matches output shows for each match.
Extracted values like this are often reshaped into JSON afterward. Validate that output with the JSON Formatter.
Validating a UUID
/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i
Checks that a string has the shape of a version-4 UUID.
Need to generate one instead? Try the UUID Generator.
Validating a SHA-256 Hash
/^[a-f0-9]{64}$/i
Checks that a string is 64 hexadecimal characters, the shape of a SHA-256 digest.
Need to produce a hash instead? Try the Hash Generator.
JavaScript Regex Gotchas
A few JavaScript-specific behaviors trip up even experienced developers.
The Global Flag and lastIndex
A RegExp object created with the g flag is stateful: each call to exec() or test() on the same object continues from its lastIndex property instead of starting over. Reusing one global regex across multiple calls without resetting lastIndex can silently skip matches. This tool sidesteps the problem by creating a fresh RegExp for every test run.
Escaping Depends on How You Build the Pattern
A literal pattern like /\d+/ only needs single backslashes. Building the same pattern from a string with new RegExp("\\d+") needs the backslash escaped again, because the string parser processes it first. Forgetting the extra backslash is a common reason a pattern that works as a literal fails when built dynamically.
Greedy vs. Lazy Quantifiers
Quantifiers are greedy by default: <.+> applied to <b>bold</b> text matches the entire span instead of stopping at the first closing tag. Adding ? to make it lazy, <.+?>, matches as little as possible, which is usually what you want when matching delimited tags or quoted strings.
Frequently Asked Questions
How do I test a regular expression?
Enter your pattern in the Regex Pattern field, add any flags you need (like g or i) in the Flags field, paste sample text into Test Text, then click Test Regex. Matches, their positions, and any capture groups appear in the Matches box.
What regex flavor does this tool use?
JavaScript's built-in RegExp engine (the ECMAScript flavor). It is close to PCRE but has its own rules for lookbehind support, named groups, and flag behavior, so patterns copied from other languages should be re-tested here.
How do I match an email address with regex?
A practical pattern is /^[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}$/ — see the Worked Examples section above for the full breakdown. Fully validating every email address the RFC allows requires a much more complex pattern, so most real-world validation uses a pattern like this plus a confirmation step.
Why does my pattern with the g flag behave differently the second time?
A global regex object tracks its position between calls using lastIndex. If you reuse the same RegExp instance across multiple exec() or test() calls, it resumes from where it left off instead of starting at the beginning. See the JavaScript Regex Gotchas section for details.
What is the difference between greedy and lazy quantifiers?
Greedy quantifiers (*, +, {n,m}) match as much text as possible, then backtrack if needed. Lazy quantifiers (*?, +?, {n,m}?) match as little as possible. Both can technically satisfy a pattern, but they often produce very different match boundaries on the same input.