Regex Tester

How to Use

Enter a regex pattern without the surrounding slashes, pick your flags, and type or paste a test string. Every match updates live as you type, showing the matched text, its position in the string, and any capture groups it produced. Turn off the "g" flag to see only the first match, matching how the same pattern behaves without it inside real code. The default example loads a pattern that pulls every run of digits out of a sample order confirmation string, a good first pattern to experiment with since you can watch the match count and match list change as you edit either the pattern or the flags.

Regex Syntax Cheat Sheet

A regular expression is built from a small set of building blocks that combine in endless ways. \d matches any digit, \w matches any letter, digit, or underscore, and \s matches any whitespace character, each has an uppercase opposite (\D, \W, \S) that matches everything except that class. A plain . matches any single character except a newline, unless the "s" flag is on. Quantifiers control repetition: * means zero or more, + means one or more, ? means zero or one, and {n,m} means between n and m repetitions of whatever came before it. Square brackets define a custom character class, [aeiou] matches any single vowel, and a leading caret inside the brackets negates it, so [^0-9] matches anything that isn't a digit. Outside brackets, ^ anchors to the start of the string (or line, with the "m" flag) and $ anchors to the end, while \b matches a word boundary without consuming any characters, useful for matching whole words only.

Understanding Capture Groups

Wrapping part of a pattern in parentheses, like (\d{4})-(\d{2})-(\d{2}), creates a capture group, a piece of the match the engine remembers separately from the full match. This tool lists any captured groups underneath each match in the results, which is exactly how you'd read them back in code using a match object's array indices. Groups are numbered left to right by their opening parenthesis, so in that date pattern, group 1 is the year, group 2 is the month, and group 3 is the day, letting you pull structured fields out of unstructured text instead of just confirming that a match exists. Prefixing a group with ?:, as in (?:https?://)?(\w+)\.com, makes it "non-capturing," useful when you need parentheses purely for grouping or alternation but don't actually want that piece to show up in your results.

Common Patterns for Real Tasks

A handful of patterns cover most everyday text-extraction needs. Pulling every number out of mixed text, as the default example does, just needs \d+ with the global flag checked. Matching a simple word (letters and digits only, no spaces or punctuation) uses \w+. A loose but practical email-shaped pattern is [\w.+-]+@[\w-]+\.[a-zA-Z]{2,}, good enough to flag obviously malformed input, though see the FAQ below on why it isn't a full validator. Matching a date in YYYY-MM-DD form is \d{4}-\d{2}-\d{2}, and matching a hex color code like #a1b2c3 is #[0-9a-fA-F]{6}. Try pasting any of these into the pattern box against your own sample text, the live match list makes it obvious immediately whether a pattern is too loose (matching things it shouldn't) or too strict (missing things it should catch).

Common Mistakes

Forgetting that certain characters are special is the most frequent trip-up: a literal period in a phone extension or IP address needs to be escaped as \., otherwise it matches any character at all, not just a dot, so 192.168.1.1 written unescaped as a pattern would also "match" a string like 192a168b1c1. Reaching for a greedy quantifier when you meant a lazy one is another common source of surprising over-matches, especially around HTML-like tags, as shown in the FAQ below. Building an enormous single regex to validate an entire complex format (a full URL, a full email address, a full credit card number with Luhn checking) is usually the wrong tool for the job, regex is great at finding and extracting patterns but poor at enforcing every business rule a format has, those are better handled with a dedicated parser or a short validation function that uses a simpler regex as just one step. Finally, deeply nested repetition like (a+)+ can cause "catastrophic backtracking" on certain inputs, where the engine's matching time explodes exponentially, freezing the page. If a pattern that worked fine on short test strings suddenly hangs on longer input, that nested-repetition pattern is the first thing to check.

Frequently Asked Questions

Why do I need to check the "g" (global) flag to see all matches?

Without the global flag, JavaScript's regex engine stops after finding the first match. Checking "g" tells it to keep scanning the rest of the string and return every match instead of just the first one, which is what most people expect when testing a pattern.

What do the i, m, and s flags do?

"i" makes matching case-insensitive. "m" makes ^ and $ match the start and end of each line instead of just the whole string, useful for multi-line text. "s" makes . also match newline characters, which it normally doesn't.

What is the difference between greedy and lazy quantifiers?

By default, quantifiers like *, +, and {n,m} are greedy, meaning they grab as much text as possible while still letting the overall pattern match, then backtrack only if needed. Adding a ? after the quantifier makes it lazy instead, grabbing as little as possible. Against the string <a><b>, the greedy pattern <.+> matches the whole string <a><b>, while the lazy pattern <.+?> matches only <a>, stopping at the first closing bracket instead of the last one.

Why does my regex only match part of what I expect?

This usually means the g flag is unchecked, so the engine stops after the first match instead of scanning the whole string. It can also happen when a pattern is more specific than intended, for example a class like [0-9] only matches single digits one at a time unless you follow it with a quantifier like + to grab a whole run of consecutive digits as one match.

Can I use a regex to fully validate an email address?

You can get close, but the official email address specification (RFC 5322) is complex enough that a fully compliant pattern is hundreds of characters long and still allows addresses no real mail provider accepts in practice. Most production systems use a simpler practical pattern to catch obvious typos, then confirm the address really works by sending a verification email, which is the only fully reliable check.

Is my test string or pattern sent to a server?

No. Matching runs entirely in your browser using JavaScript's built-in RegExp engine. Nothing you type into the pattern or test string fields is transmitted, logged, or stored anywhere, which makes it safe to test patterns against real sample data, including sensitive strings you wouldn't want to paste into an unfamiliar third-party site.