BrowserTools
Advertisement
Home / Validators / Regex Tester & Debugger

Regex Tester & Debugger

Test JavaScript regular expressions live with match highlighting, capture groups and replace preview.

Loading Regex Tester & Debugger… If nothing happens, please enable JavaScript.

Frequently asked questions

Is my input sent to a server?
No. The regular expression is evaluated entirely in your browser using the native JavaScript RegExp engine. Your pattern, test string, and any replacement template never leave your device and are never transmitted over the network.
Which regex flavour does this tool use?
This tool uses the JavaScript ECMAScript regex engine via the native RegExp constructor. It supports all standard ES2024 features including named capture groups (?<name>...), lookbehind assertions ((?<=...) and (?<!...)), the dotAll flag (s), the Unicode flag (u), the indices flag (d), and the recently added v flag for Unicode set notation. It does not support PCRE-specific features like recursive patterns or possessive quantifiers.
When should I use a regex instead of simple string methods?
For simple fixed-string searches, String.prototype.includes() or indexOf() is faster and more readable than a regex. Reach for a regex when you need pattern matching (e.g., 'starts with a digit'), alternation (match 'cat' or 'dog'), character classes (match any vowel), quantifiers (match one or more digits), or capture groups to extract sub-matches. Regex shines for validation, extraction, and transformation tasks where the target pattern has structure that cannot be expressed as a single literal string.
How is JavaScript regex different from PCRE (Python, PHP, Perl)?
JavaScript's regex flavour is similar to PCRE but has some notable differences. JavaScript does not support atomic groups, possessive quantifiers, or recursive patterns. The \K (keep) assertion available in PCRE is absent in JavaScript. Named capture groups use the syntax (?<name>...) in JavaScript, versus (?P<name>...) in Python. The global (g) flag in JavaScript affects the stateful lastIndex property of the RegExp object, which can cause subtle bugs when reusing a regex object in a loop.
What are the available flags and what do they do?
The main JavaScript regex flags are: g (global) — find all matches instead of stopping at the first; i (case-insensitive) — treat uppercase and lowercase as equivalent; m (multiline) — make ^ and $ match line boundaries instead of string boundaries; s (dotAll) — make the dot (.) match newlines; u (Unicode) — enable full Unicode matching and code-point escapes; and d (indices) — include start and end indices for each match and capture group in the result.
Is there a limit on how long the test string or pattern can be?
There is no hard limit enforced by the tool, but very long patterns or very large test strings may cause the browser to become unresponsive, especially if the pattern involves nested quantifiers that can trigger catastrophic backtracking. Patterns with unbounded backtracking on large inputs can consume CPU indefinitely. If the browser tab freezes, close and reopen it. For production use, always test regex patterns against adversarial input before deploying.
Can I use this to test a replacement pattern?
Yes. Enter a replacement string in the replace field and the tool shows a live preview of the output after applying String.prototype.replace (for the first match) or replaceAll (with the g flag). Standard replacement syntax is supported: $1 and $2 for numbered capture groups, $<name> for named capture groups, $& for the entire matched string, $` for the text before the match, and $' for the text after the match.
What is catastrophic backtracking and how do I avoid it?
Catastrophic backtracking occurs when a regex engine explores an exponential number of possible match paths on a string that does not match the pattern. It typically arises from nested quantifiers on overlapping character classes — for example, (a+)+ on a long string of 'a' characters followed by a character that cannot match. To avoid it: prefer atomic patterns, use possessive quantifiers if available, avoid ambiguity in what each part of the pattern can match, and always test on inputs designed to fail as well as inputs designed to succeed.
What is the difference between a capturing and a non-capturing group?
A capturing group (...) matches the pattern inside the parentheses and stores the matched text so it can be referenced later via $1, $2, or group indices. A non-capturing group (?:...) groups the pattern for quantification or alternation purposes without storing the match, making it slightly more efficient. Named groups (?<name>...) are capturing groups that can be referenced by name ($<name> in replacements, match.groups.name in JavaScript code) instead of by index.
What is a common beginner mistake with regular expressions?
One of the most common mistakes is forgetting to escape the dot (.) when you mean a literal period. The dot in a regex matches any character (except newline by default), so a pattern like 3.14 will also match 3X14 or 3-14. Write 3\.14 to match a literal dot. Another frequent error is omitting the global flag (g) and wondering why only the first match is highlighted. A third pitfall is anchoring with ^ and $ and being surprised that they match line boundaries only when the multiline flag (m) is set.

About Regex Tester & Debugger

Regular expressions (regex or regexp) are a formal language for describing patterns in text. The theory traces back to mathematician Stephen Cole Kleene, who formalised the algebra of regular languages in 1956, and to Ken Thompson, who implemented regex in the QED editor and the original Unix tools grep, sed, and awk in the 1960s and 70s. Modern regex engines extend the theoretical foundation with practical features like lookaheads, backreferences, and named capture groups — making them one of the most powerful text-processing tools available in any programming language.

Regular expressions are indispensable for a wide range of real-world tasks. Form validation — checking that an email address, phone number, or postcode matches the expected format — almost universally uses regex. Log parsers extract structured fields from unstructured log lines using capture groups. Code editors and IDEs use regex for find-and-replace across large codebases. Security tools use regex to detect injection patterns and sensitive data leakage. Data transformation pipelines use regex to normalise inconsistent formats. Network device configurations are audited with regex. Understanding and debugging a regex pattern interactively is far faster than running a script repeatedly.

This tester evaluates JavaScript regular expressions against your input in real time, highlighting every match as you type. It lists all capture groups (numbered and named) for each match so you can immediately see what each group captured. A replacement mode lets you type a replacement template and preview the result of String.prototype.replace or replaceAll, with support for $1, $2, and $&lt;name&gt; backreferences. Everything runs entirely in your browser's JavaScript engine — your patterns and input text are never sent to any server.

Regex is notoriously easy to get subtly wrong. A bare dot (.) matches any character including newlines in some modes, not just a literal period. Greedy quantifiers (*, +) will match as much as possible, often capturing more than intended — use lazy versions (*?, +?) to match as little as possible. The ^ and $ anchors match the start and end of the entire string by default; add the multiline flag (m) if you want them to match at line boundaries. Catastrophic backtracking — where a poorly written regex causes exponential matching time on adversarial input — is a real denial-of-service risk in web applications that apply user-supplied patterns to user-supplied text.

From formal language theory to grep

The concept of regular expressions originates in theoretical computer science. In 1956, mathematician Stephen Cole Kleene published a paper describing 'regular events' — sets of strings that could be described by a finite automaton — and introduced the algebraic notation that would become regex syntax. The star operator (*), called the Kleene star, is named after him. At this point, regular expressions were purely a mathematical abstraction with no connection to computing practice.

The leap from theory to tool came in 1968 when Ken Thompson implemented regex search in the QED text editor and then in the Unix tool grep (whose name stands for 'globally search a regular expression and print'). Thompson's key innovation was an efficient algorithm that converted a regular expression into a nondeterministic finite automaton (NFA) and simulated it, guaranteeing linear-time matching with no catastrophic backtracking. Many modern regex engines abandoned Thompson's NFA approach in favour of backtracking engines that support more features (like backreferences) but can exhibit exponential worst-case behaviour.

Today, regular expressions are supported natively in virtually every programming language and text editor. Yet the syntax has splintered into dozens of incompatible flavours — POSIX BRE, POSIX ERE, PCRE, .NET, Java, Python, JavaScript, Ruby — each with subtle differences in syntax and semantics. A regex written for one language will often work in another, but edge cases abound. This fragmentation is why testing a pattern in the specific engine you will actually use is always recommended before deploying it in production.

Related tools

JSON Validator & Formatter

Validate, format and minify JSON in your browser with detailed error locations.

XML Validator & Formatter

Validate and pretty-print XML in your browser using the DOMParser.
Advertisement