Free regex tester (JavaScript)
Test a JavaScript regular expression against any sample text and see every match and capture group highlighted — with the g/i/m/s flags, character classes, quantifiers and groups all handled by the browser's own regex engine, updated live, as you type.
On this page13 sections
Output is generated client-side in your browser. No data is transmitted to any server.
Results are estimates. Consult a professional.
What this regex tester does
A regex tester runs a regular expression against sample text and shows you exactly what it matches — every match, where it starts, and the contents of each capture group. A regular expression (regex) is a compact pattern that describes a shape of text rather than a fixed string: "one or more digits," "an email-like token," "a date in YYYY-MM-DD form." You write the pattern once, and it finds every place the text fits that shape.
The tester above evaluates your pattern with the JavaScript (ECMAScript) regex engine — the same one built into every web browser — and highlights matches updated live, as you type. Enter a pattern, choose your flags, paste the text to search, and it lists each match and the substrings captured by your parentheses. If the pattern is invalid, it tells you why instead of failing silently.
How regular expressions work
A regex is read left to right. Literal characters match themselves, while metacharacters stand for categories or repetition. The engine scans the text and, at each position, tries to match the pattern; when it succeeds it records the match and moves on, which is how one pattern can return many matches. Parentheses ( ) both group sub-patterns and capture what they match, so you can pull pieces out of each hit.
This tester implements the ECMAScript flavor defined in the language standard, which is also what RegExp, String.match, and String.replace use in Node and the browser. It is close to — but not identical to — other flavors such as PCRE (PHP, grep) and Python's re; the differences are covered in the gotchas section below.
Common regex tokens: a quick reference
Most patterns are built from a small set of tokens. The table below covers the ones you will reach for most often — character classes, quantifiers, anchors, groups, and alternation. Backslash escapes are written with a single backslash in the pattern field above.
| Token | What it matches |
|---|---|
| . | Any character except a newline (any character at all with the s flag) |
| \d \D | A digit 0–9 · any non-digit |
| \w \W | A word character (letter, digit, underscore) · any non-word character |
| \s \S | Any whitespace (space, tab, newline) · any non-whitespace |
| [abc] [^abc] | Any one of a, b, c · any character except a, b, c (character class) |
| [a-z] [0-9] | A range: any lowercase letter · any digit |
| * + ? | Zero or more · one or more · zero or one (quantifiers) |
| {n} {n,} {n,m} | Exactly n · n or more · between n and m repetitions |
| ^ $ | Start of string (or line) · end of string (or line) |
| \b \B | A word boundary · a non-boundary |
| (…) (?:…) | Capturing group · non-capturing group (group without saving the match) |
| a|b | Alternation: match a or b |
| \. \* \( | An escaped literal: a real dot, asterisk, or parenthesis |
Token meanings follow the ECMAScript regular-expression grammar as documented by MDN. Inside a character class [ ], most metacharacters lose their special meaning and match literally.
Regex flags: global, ignore-case, multiline, dotall
Flags change how the whole pattern behaves. They are the letters after the closing slash in /pattern/gim. This tester always applies g so it can collect every match, and lets you add the others.
| Flag | Name | Effect |
|---|---|---|
| g | global | Find every match, not just the first. Required to list all matches. |
| i | ignore-case | Treat A and a as the same — "Cat" matches "cat". |
| m | multiline | Make ^ and $ match at the start and end of each line, not just the whole string. |
| s | dotall | Let . match newline characters too, so a pattern can span lines. |
| u | unicode | Treat the pattern as a sequence of Unicode code points; enables \p{…} property escapes. |
| y | sticky | Match only at the position the engine has reached, anchoring each attempt. |
Flag definitions per MDN's RegExp documentation. Flags combine in any order — /…/gi and /…/ig are identical.
A worked example: matching a date with capture groups
Suppose you have the line "Contact: alice@example.com or bob@test.org by 2026-06-17." and you want the date — broken into year, month, and day. We will write a pattern, run it in the tester, and read the capture groups.
Step 1 — Describe the shape of a date
A date like 2026-06-17 is four digits, a dash, two digits, a dash, two digits. In tokens that is \d{4}-\d{2}-\d{2}. Wrapping each part in parentheses turns them into capture groups: (\d{4})-(\d{2})-(\d{2}).
Step 2 — Run it with the g flag
Paste the pattern, set the text, and the tester reports one match: 2026-06-17 at index 46. Because we used three groups, it also lists the captures — 2026, 06, and 17 — the year, month, and day, ready to reuse.
Step 3 — Try a different pattern on the same text
Swap the pattern for a simple email shape, \b[\w.]+@[\w.]+\.\w+\b, and the tester now returns two matches — alice@example.com and bob@test.org — with no capture groups, because this pattern has no parentheses. One body of text, two patterns, two completely different results.
What regular expressions are used for
Regex shows up anywhere text needs to be searched, checked, or pulled apart by pattern rather than by exact wording. Testing a pattern here first — against real sample text — saves you from shipping one that quietly matches too much or too little.
- Validation — checking that a form field looks like an email, postcode, phone number, or date before accepting it.
- Search and replace — find-and-replace by pattern in an editor or with
String.replace, using capture groups in the replacement. - Log parsing — extracting timestamps, IP addresses, status codes, or error messages from server logs line by line.
- Scraping and extraction — pulling structured fields out of semi-structured text, such as prices or IDs from a feed.
- Routing and tokenizing — matching URL paths, splitting strings on flexible delimiters, or highlighting syntax.
Regex is for patterns, not structured documents. To pretty-print or validate JSON, reach for a JSON formatter instead; to make text safe inside a URL, use a URL encoder. A regex can match parts of those formats, but it is the wrong tool for parsing them whole.
Common regex mistakes and gotchas
Regex is powerful and unforgiving in equal measure. The same pattern can be correct, slow, or dangerous depending on small details. These are the traps that catch people most often.
Catastrophic backtracking (ReDoS)
A pattern with a quantifier inside another quantifier — like (a+)+ or (.*)* — can force the engine to try an exponential number of combinations on certain inputs. Against a long string of as that just fails to match, such a pattern can hang for seconds or longer. This is "catastrophic backtracking," and when attacker-supplied input reaches a vulnerable pattern it becomes a denial-of-service bug (ReDoS). The fix is to avoid nesting quantifiers and to anchor patterns tightly; test suspicious patterns against a near-miss input before you trust them.
Greedy vs lazy quantifiers
By default *, +, and {n,} are greedy: they grab as much text as possible, then give some back if needed. So <.*> on "<a><b>" matches the whole "<a><b>", not just "<a>". Adding a ? makes a quantifier lazy — <.*?> matches "<a>" alone, the smallest piece that satisfies the pattern. Choosing the wrong one is the most common reason a match is "too big."
Escaping special characters
Characters like . * + ? ^ $ { } ( ) | [ ] \ have special meaning. To match a literal dot in "file.txt" you must write \., not . — a bare dot matches any character, so file.txt would also match "fileXtxt." When you only want a plain substring, escaping every special character (or not using regex at all) avoids surprises.
JavaScript regex is not PCRE or Python
A pattern copied from a PHP or Python answer may behave differently here. Modern JavaScript does support lookbehind ((?<=…)) and named groups ((?<name>…)), but it lacks possessive quantifiers, atomic groups, and recursion that PCRE offers, and some Unicode-property syntax needs the u flag. If a pattern from elsewhere does not work, the flavor is the usual reason.
Regex terms, defined
Does this regex tester run in my browser?
Yes. The pattern, the flags, and the text you paste are evaluated entirely in your browser with its own RegExp engine. Nothing is stored, logged, or sent to any server — there is no network request, because the match runs locally — so the tester works the same offline and keeps your sample data on your device.
Because matching happens client-side, you can safely test patterns against real-looking sample text. The one cost that is real is time: a pathological pattern (see catastrophic backtracking above) runs in your own browser tab, so a runaway pattern can freeze the page until you reload it — another reason to test patterns against near-miss input before deploying them anywhere.
Frequently asked questions about the free regex tester (JavaScript)
About this regex tester
This regex tester runs entirely in your browser. The pattern, flags, and text you paste are evaluated locally with the browser's own JavaScript RegExp engine — nothing is stored, logged, or sent to any server, so it works the same offline and keeps your sample data on your device. It lists every match and the contents of each capture group, and reports an error if the pattern is invalid. It uses the ECMAScript regex flavor, which differs in places from PCRE and Python.
It is one of our free developer tools. For working with structured data, try the JSON formatter or the URL encoder.