What is a regex tester?
A regex tester lets you develop regular expressions interactively: you type a pattern, provide sample text, and instantly see what matches, where it matches, and what each capture group extracted. Regular expressions are a compact language for describing text patterns - “an email address”, “a date in ISO format”, “any line starting with ERROR” - and they are built into every major programming language, editor, and command-line toolkit.
The catch is that regex syntax is dense and unforgiving; a single misplaced character silently changes what a pattern matches. Writing a regex blind and testing it in production code is slow and error-prone. This tool shortens the loop to milliseconds: matches are highlighted in the test string as you type, a table below lists every match with its position and capture groups, and preset buttons load battle-tested patterns for emails, URLs, IP addresses, ISO dates, and UUIDs. It uses JavaScript's native RegExp engine and runs entirely in your browser, so your test data stays private.
How to use the regex tester
- Enter a pattern in the Pattern field - without the surrounding slashes. For example:
\d{4}-\d{2}-\d{2}to find ISO dates. Or click a preset chip to start from a common pattern with matching sample text. - Set the flags. Leave
g(global) on to find every match; addifor case-insensitive matching,mso^/$work per line, orsso.also matches newlines. - Paste your test string - real data works best: an actual log excerpt, CSV row, or API response fragment.
- Read the highlights. Every match is highlighted in the output panel in real time. No highlights means no matches; a red banner means the pattern itself has a syntax error.
- Inspect the match table. Each row shows the matched text, its character index, and the value of every numbered and named capture group - exactly what your code would receive.
Examples
Extract dates and reformat them
Pattern: (?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})
Text: Deployed 2026-07-09, rollback point 2026-06-28.
Matches: 2026-07-09 (year: 2026, month: 07, day: 09)
2026-06-28 (year: 2026, month: 06, day: 28)Named groups like (?<year>...) make replacement code self-documenting: in JavaScript you could reformat with str.replace(re, "$<day>/$<month>/$<year>").
Find emails in messy text
Pattern: [\w.+-]+@[\w-]+\.[\w.]+
Text: Contact sales@example.com or support+tickets@help.example.org
Matches: sales@example.com, support+tickets@help.example.orgNote this is a pragmatic pattern, not a full RFC 5322 validator - which is fine, because for real validation you should send a confirmation email anyway.
Match log lines by severity
Pattern: ^ERROR .+$ (with the m flag)
Text: INFO service started
ERROR connection refused to db:5432
WARN retrying in 5s
Matches: ERROR connection refused to db:5432Regex syntax quick reference
.any character ·\ddigit ·\wword character ·\swhitespace*zero or more ·+one or more ·?optional ·{2,5}between 2 and 5 times[abc]any of a, b, c ·[^abc]anything except a, b, c ·a|ba or b^start of string/line ·$end of string/line ·\bword boundary(...)capture group ·(?:...)non-capturing group ·(?<name>...)named group(?=...)lookahead ·(?<=...)lookbehind - assert context without consuming it
Tips for writing better regex
- Build incrementally. Start with a literal fragment that matches, then generalize one piece at a time, watching the highlights after each change.
- Prefer specific classes over dot-star.
"[^"]*"(quote, non-quotes, quote) is faster and more correct than".*?". - Anchor when validating. To check that an entire string matches - not just part of it - wrap the pattern in
^...$. Validating UUIDs, for example, needs anchors; generate test values with the UUID Generator. - Beware catastrophic backtracking. Nested quantifiers like
(a+)+can take exponential time on non-matching input. Keep quantified groups from overlapping. - Know when not to use regex. Structured formats deserve real parsers - check JSON with the JSON Validator and inspect it with the JSON Formatter rather than pattern-matching against raw JSON text.
Frequently asked questions
Which regex flavor does this tester use?
It uses JavaScript's native RegExp engine (ECMAScript flavor) - the same engine that runs in Node.js and every browser. Most patterns behave identically across flavors, but some advanced features differ: JavaScript supports lookbehind and named groups in all modern engines, while features like atomic groups and possessive quantifiers from PCRE are not available.
What do the g, i, m, and s flags mean?
g (global) finds all matches instead of stopping at the first. i (ignore case) makes letters match regardless of case. m (multiline) makes ^ and $ match at the start and end of each line rather than the whole string. s (dotall) makes the dot . match newline characters, which it normally does not.
What is a capture group and how do I read the results?
Parentheses in a pattern create capture groups that extract sub-parts of each match. For example, (\w+)@(\w+) applied to 'ada@example' captures 'ada' as group $1 and 'example' as group $2. The match table in this tool lists every group's value per match. Named groups, written (?<name>...), appear with their name instead of a number.
Why does my pattern match more than I expected?
Usually because quantifiers are greedy by default: .* grabs as much text as possible while still allowing the rest of the pattern to match. Add a ? to make it lazy (.*?), or better, use a negated character class like [^"]* to match 'everything up to the next quote'. Also check whether an unescaped dot . is matching characters you meant literally.
Why does my pattern match nothing at all?
Common causes: special characters like . + ? ( ) [ ] that need escaping with a backslash, anchors ^ or $ constraining the match to positions that don't exist in your test string, case differences (add the i flag), or the pattern spanning lines while . doesn't match newlines (add the s flag). Simplify the pattern until something matches, then rebuild it piece by piece.
Is it safe to paste production log data into this tester?
Yes. The tester runs entirely in your browser - your pattern and test string are never transmitted or stored. Nothing you paste leaves your device.
Can a regex crash or freeze the tester?
Certain patterns with nested quantifiers, like (a+)+$ against a long string of a's, exhibit catastrophic backtracking and can take exponential time - this is true of any regex engine, not just this tool. The tester caps the number of matches it collects, but an inherently slow pattern can still make the tab briefly unresponsive. If that happens, simplify the nested quantifiers.