Regex Tester

JavaScript regex sandbox with live highlights

Dialect differs from PCRE or POSIX—verify lookbehind support in your target engines. Use flags g/i/m/s deliberately: dotAll (s) changes “.” semantics dramatically.

Redact PII before sharing regex screenshots; logs often contain emails and phone numbers.

How the tester works

Type the pattern without surrounding slashes, toggle flags, and paste the text to search. The pattern runs on your browser’s own JavaScript RegExp engine on every keystroke, so what you see is exactly how the same pattern behaves in JavaScript and TypeScript code.

All matches are listed even if the g flag is off — the tester adds it internally for the list — together with each match’s position and its capture groups in order. Matches are highlighted in the text below. Patterns that can match an empty string, such as a* or \b, are stepped through one position at a time, so they show zero-width matches without freezing the page.

Five presets (email, URL, IPv4, date and hex colour) load a working pattern with sample text — useful starting points to adapt rather than definitive validators.

Worked examples

• Prices: \$\d+(?:\.\d{2})? on “Coffee $4.50, bagel $3, total $7.50” matches $4.50, $3 and $7.50. The dollar sign and the dot are escaped because both are special characters; (?: … ) groups the cents without capturing them.
• Dates with groups: (\d{4})-(\d{2})-(\d{2}) on “Due 2026-10-01” gives one match with groups 2026, 10 and 01 — in code, a replacement string such as $3/$2/$1 reorders them to 01/10/2026.
• Whole words: \bcat\b on “cat concatenate cat.” matches the two standalone words and skips “concatenate”.
• Log lines: ^ERROR.*$ with the m flag matches every line that starts with ERROR. Without m, ^ and $ only match the start and end of the whole text.
• Greedy vs lazy: <.+> on “<b>bold</b>” matches the entire string, because .+ grabs as much as it can. <.+?> matches “<b>” and “</b>” separately.

Mistakes that cause most regex bugs

• Unescaped dots: example.com matches “exampleXcom” too. Write example\.com.
• Missing anchors when validating: \d{5} finds five digits inside “123456789”. For a whole-input check use ^\d{5}$.
• Catastrophic backtracking: nested quantifiers such as (a+)+$ take exponential time on input like “aaaaaaaaaaaaaaaaaaaaaaaa!”. In a browser that freezes the tab — here as well as in production. Rewrite with a single quantifier — a+$ instead of (a+)+$ — or a more specific character class.
• Expecting regex to fully validate emails or parse HTML: the email preset accepts typical addresses, not every address RFC 5322 allows, and nested HTML needs a real parser.
• Forgetting flags: case-sensitive matching is the default — add i if “Error” and “ERROR” should both match.

Moving a pattern to another language

Most everyday syntax — character classes, quantifiers, groups, anchors, lookahead — is identical across JavaScript, Python, Java, C#, PHP and Go. The differences that bite are mostly about escaping and a few advanced features:

• String escaping: in Java and C# source code every backslash is doubled (“\\d+”); in Python use a raw string, r"\d+".
• Named groups: JavaScript, .NET and Java write (?<year>\d{4}); Python writes (?P<year>\d{4}).
• Go (RE2) has no lookahead, lookbehind or backreferences, by design, in exchange for guaranteed linear-time matching.
• PHP’s preg_ functions need delimiters around the pattern, for example /\d+/i.
• Lookbehind (?<=…) works in all current browsers and Node.js, but very old browsers lack it.

Privacy

Patterns and test text are processed only in your browser. Log excerpts often contain email addresses, IP addresses and tokens; you can test against them here without them leaving your machine, but scrub them before sharing a screenshot.