Common Presets
//
Flags:/.../g
0 matches
Matches will appear here...
$
Regex Tester
Test regular expressions with real-time match highlighting, captured groups, and replace functionality.
What are regular expressions?
Regular expressions (regex) are compact patterns that describe sets of strings. They power search, validation, and text transformation everywhere: grep and sed on the command line, log parsing pipelines, input validators, and the find-and-replace dialog of every serious editor. A pattern like \d{4}-\d{2}-\d{2} matches any ISO-style date. The syntax is dense and easy to get subtly wrong, which is why testing a pattern against real sample text before shipping it matters.
How does this tester work?
Type a pattern, paste sample text, and matches highlight as you type. The match details panel lists every match with its string index and any captured groups, and the find-and-replace section previews substitutions, including $1-style group references. Six presets — email, URL, IP address, phone number, date, and hex color — give you a working starting point. Everything runs locally in your browser using the JavaScript RegExp engine, so pasting production logs is safe.
What do the g, i, m, and s flags mean?
g (global) finds every match instead of stopping at the first — without it the match counter here will never go above 1. i makes matching case-insensitive. m (multiline) changes ^ and $ to anchor at every line start and end rather than only the whole string. s (dotAll) lets . match newline characters, which it normally refuses to do — the usual fix when a pattern works on one line but fails across line breaks.
What is the difference between grep and egrep regex?
Plain grep uses basic regular expressions (BRE), where +, ?, | and {} must be backslash-escaped to act as operators. egrep — or the modern grep -E — uses extended syntax (ERE) where they work directly. Neither supports lookaheads or \d shorthand; for those you need grep -P, which enables Perl-compatible regex on GNU systems. This tester uses JavaScript syntax, which is closest to PCRE, so keep that caveat in mind when porting patterns to grep -E or sed.
Why does my regex match too much?
Quantifiers are greedy by default: .* grabs as much text as it can while still allowing the overall pattern to match. Against <b>one</b> and <b>two</b>, the pattern <b>.*</b> swallows everything from the first <b> to the last </b>. Append ? to make it lazy — <b>.*?</b> stops at the earliest closing tag. Better still, use a negated class like [^<]* which can never cross a tag boundary and avoids backtracking entirely.
How do capture groups and $1 replacements work?
Parentheses capture the text they match, numbered left to right by opening bracket. In the replace field, $1 and $2 insert those captures, so pattern (\d{2})/(\d{2})/(\d{4}) with replacement $3-$1-$2 reorders a US date into ISO format. A group inside an alternation branch that did not participate comes back undefined — the match details panel shows that explicitly. Use (?:...) when you need grouping without capturing; it keeps your group numbering stable.
Should I validate emails with a regex?
Only loosely. The full RFC 5322 address grammar is famously hostile to regex, and overly strict patterns reject real addresses. The email preset here takes the pragmatic approach most production code uses: [email protected], then confirm by sending mail. Also beware catastrophic backtracking — nested quantifiers like (a+)+ run against a long non-matching string can hang an engine, a bug class called ReDoS. This tester caps match iterations as a guard; your server-side code will not be so forgiving.