Regex Tester

How to use this regex tester

1. Type your pattern and flags (like gmi).
2. Paste or type test text.
3. Matches highlight instantly, with a live match count.

What is a regular expression?

A regex is a pattern used to match character combinations in strings, widely used for validation, search-and-replace, and parsing text.

How this tester matches patterns

This tool runs your pattern through the browser's native RegExp engine — the same engine JavaScript uses everywhere, from client-side validation to Node.js backends. That matters because JavaScript's regex flavor isn't identical to what you'd find in Python, PHP, or grep: it added support for named capture groups ((?<name>...)), lookbehind assertions ((?<=...) and (?<!...)), and the Unicode-aware u flag only in relatively recent engine versions, so a pattern tested here behaves the same way it will in a browser or in Node, but not necessarily the same way in another language's regex implementation.

Regex flavors — why patterns don't always port

"Regex" isn't one single standard — it's a family of similar but incompatible dialects. PCRE (used by PHP and many command-line tools), POSIX (used by classic grep and sed), Python's re module, and JavaScript's RegExp all share the same basic vocabulary (character classes, quantifiers, groups) but differ in the details: possessive quantifiers and atomic groups exist in PCRE but not in JavaScript; POSIX doesn't support non-greedy quantifiers at all; and even something as basic as how \b (word boundary) treats Unicode characters can differ between engines. If you're writing a pattern to use somewhere other than a browser or Node.js, test it in that actual environment before relying on it — a pattern that works perfectly here can throw a syntax error, or silently match differently, in another language.

Common regex mistakes

The single most common mistake is using a greedy quantifier (*, +) when you meant a lazy one (*?, +?). Given the text <a><b>, the pattern <.*> greedily matches the entire string from the first < to the last >, while <.*?> stops at the first available >. The second most common is forgetting to escape special characters — a literal period, dollar sign, or parenthesis needs a backslash (\., \$, \() or it will be interpreted as regex syntax instead of the literal character. And a subtler, more dangerous mistake is writing a pattern vulnerable to catastrophic backtracking: nested quantifiers like (a+)+ can cause the engine to try an exponential number of combinations against certain inputs, freezing the tab or the server process running it — this is a real, exploitable denial-of-service vector in production code, not just a performance quirk.

When not to use regex

Regex is good at matching flat, predictable patterns in text — a phone number, an email format, a log line. It's a poor tool for parsing anything with nested or recursive structure, like HTML, XML, or JSON, because regular expressions fundamentally cannot count matching pairs of arbitrary depth (this is a real theoretical limitation, not a skill issue — it's why "don't parse HTML with regex" is such a common piece of advice). If you find yourself writing an increasingly complicated pattern to handle nested tags or brackets, that's the signal to switch to an actual parser for that format instead.

Limitations of this tester

This tool uses the browser's built-in JavaScript RegExp engine directly, so any pattern that's valid JavaScript regex syntax will work exactly as it would in production code. What it won't do is emulate PCRE-only features like atomic groups, possessive quantifiers, or recursive patterns, since those aren't part of the JavaScript regex spec at all — trying them here will produce a syntax error, which is expected behavior, not a bug. Very large test strings (multiple megabytes) combined with a pathological pattern can also make the browser tab unresponsive, for the same catastrophic-backtracking reason described above; if a pattern seems to hang, it's worth simplifying it rather than waiting.