Regex Tester
Test JavaScript regular expressions against sample text — see matches, groups, and replace preview.
How to Use
- Enter your regex pattern between the slashes — no need to escape the surrounding /.
- Add flags after the second slash (g, i, m, s, u, y).
- Paste sample text into the test area. Matches highlight live as you type.
- Numbered and named capture groups are listed under each match.
- Optionally enter a replacement string to preview Replace output. Use $1, $2, ... for capture groups, or for named groups.
- Try one of the common-pattern presets (email, URL, IP, hex color, UUID) to learn the syntax.
Common Patterns
A Brief History of Regular Expressions
Regular expressions began as a 1951 mathematical formalism by Stephen Kleene to describe the patterns recognizable by what would later be called finite automata. The "Kleene star" (the * in regex) is named after him. The notation moved from theory to practice in the 1960s when Ken Thompson, working on a QED text editor at Bell Labs, implemented Kleene's notation as a search facility — the same compile-to-NFA technique he later used in grep (1973), the canonical Unix tool whose name is short for "g/re/p" (the editor command "globally search for a regular expression and print").
Different tools added different features and the syntax fragmented. Henry Spencer's regex library (1986) became POSIX BRE/ERE. Larry Wall's Perl (1987) extended regex aggressively with backreferences, lookahead, non-greedy quantifiers, and non-capturing groups; the Perl flavor became the de facto standard for "modern" regex via PCRE (Perl-Compatible Regular Expressions, 1997). JavaScript regexes track the Perl tradition, with Russ Cox's RE2 (2010) representing the linear-time alternative used inside Google for untrusted input.
The fundamental tension hasn't changed since the 1970s: regular languages (in the formal sense) are limited and fast; the extensions that make practical regex tools convenient (backreferences, recursion) push them out of the regular class and into territory where pathological inputs can take exponential time. Picking the right tool — POSIX BRE for portability, JavaScript for the web, RE2 for hostile input, a real parser for nested data — is most of what regex experience comes down to.
About This Tester
This tester uses the browser's native RegExp engine — the same one that runs in your applications, with full ECMAScript 2018+ feature support. Patterns are compiled with the flags you supply, then matched against the test text. Each match is highlighted in place; numbered and named capture groups are surfaced for inspection. The replace preview uses String.prototype.replace with the standard backreference syntax ($1, $2, ${name}, $&).
If your pattern is invalid, the error message comes straight from V8/Spidermonkey/JavaScriptCore and includes the position of the syntax error. Everything runs entirely in your browser — no patterns or test data are transmitted or stored. For very long inputs or pathological patterns, your browser may freeze briefly; if that happens, the regex is probably one to rewrite anyway.
Frequently Asked Questions
Which regex flavor does this support?
JavaScript regular expressions (ECMAScript 2018+). That includes lookbehind (?<=...) and (?<!...), named capture groups (?<name>...), Unicode property escapes \p{...}, and the dotAll flag (s). It does NOT support some PCRE features: recursive patterns, conditional patterns, or atomic groups.
What are the common flags?
g — global (find all matches, not just the first). i — case-insensitive. m — multiline (^ and $ match line starts/ends). s — dotAll (. matches newlines). u — unicode (handles non-BMP code points correctly, enables \p{...}). y — sticky (matches must start at lastIndex).
How do capture groups work?
Parentheses around part of the pattern create a capture group. The first set of parens is group 1, second is group 2, etc. Named groups (?<name>...) capture into a name you can reference. In the replacement string, $1 / $2 / refer to those groups; $& is the whole match.
What's a non-capturing group?
(?:...) groups for alternation or repetition without creating a numbered capture. Use it when you need grouping but don't want the match to land in your captures array — slightly faster, and keeps your group numbers tidy.
Why does my regex run forever?
Catastrophic backtracking. Patterns like (a+)+b or (.*)*x can take exponential time on certain inputs. Avoid nested quantifiers and prefer atomic-style alternatives (possessive quantifiers aren't in JS, but you can usually rewrite to avoid the issue). For untrusted input, set a timeout or use a regex engine that guarantees linear time (re2).
When should I NOT use regex?
Parsing HTML, parsing XML, parsing JSON, or anything with nested/recursive structure — use a real parser. Validating email addresses precisely (RFC 5322 is too complex for regex; just check for @ and call it good). One-shot text munging where the pattern is going to be discarded — use the language's built-in string functions when possible.
Common Use Cases
Validating user input
Check that an email, phone number, postal code, or URL roughly matches the expected shape before submitting a form.
Extracting data from logs
Pull timestamps, IP addresses, status codes, or session IDs from log lines for one-off analysis.
Search-and-replace across files
Test the pattern here before running it through grep -E, sed, or your IDE's find-and-replace across an entire codebase.
Building a tokenizer
Iterate on patterns for parsing simple DSLs, log formats, or CSV variants where a full parser is overkill.
Cleaning CSV / unstructured data
Strip whitespace, normalize separators, or extract fields from messy data dumps before importing them anywhere structured.
Learning regex
Try patterns interactively with instant feedback. Start with the preset library and modify them to see what each piece does.
Last updated: