Regex Tester

The Regex Tester lets you write a regular expression, apply flags, and see exactly what it matches in your sample text -- with matches highlighted in place, a running match count, and a breakdown of numbered and named capture groups for each match.

Regular expressions power log parsing rules, SIEM detections, WAF signatures, YARA-adjacent string matching, and data-loss-prevention patterns (like credit card or SSN detection). Testing a pattern against real or representative sample text before deploying it into a detection rule catches false positives and false negatives early, without touching production systems.

Your pattern and flags are compiled into a native JavaScript RegExp. The tool always runs matching in global mode internally so it can enumerate every match, while respecting the other flags you select (case-insensitive, multiline, dotAll, unicode). To avoid the page hanging on catastrophically backtracking patterns, matching stops after a capped number of iterations.

1. 1Enter a pattern, or click one of the example buttons to load a ready-made security-relevant pattern.
2. 2Toggle flags such as global, ignore-case or multiline as needed.
3. 3Paste or edit the test string to see matches highlighted live.
4. 4Review the match table for exact positions and any capture groups, including named groups.

Testing EventID[:=]\s*(?<id>\d+) against Windows security log text extracts the event ID into a named group called id, which is exactly the kind of extraction used in log-parsing pipelines.

Testing an IPv4 pattern against a firewall log line confirms it correctly matches source and destination addresses without accidentally matching version numbers or other dotted-number strings.

• Forgetting the global flag when you expect multiple matches (the tool always searches globally internally, but be aware production tools may not).
• Writing greedy quantifiers like .* when a non-greedy .*? or a more specific character class would avoid overmatching.
• Not anchoring patterns with \b or ^/$, causing partial matches inside longer tokens.
• Using catastrophic backtracking patterns (heavily nested quantifiers) that are slow on real-world text -- this tool caps iterations to protect your browser, but production regex engines may not.

Poorly written regular expressions can cause denial-of-service conditions (ReDoS) in production systems that evaluate untrusted input against them. When designing detection rules or input validation regexes, test with adversarial and edge-case input, keep patterns as specific as possible, and prefer engines/configurations with matching timeouts in production.