Regex Tester

About this tool

A regular expression is a small, dense language for describing patterns in text — not a specific string to find, but a shape a string can match: "one or more digits," "an @ symbol surrounded by word characters," "anything that starts with http and has no whitespace." That compactness is exactly what makes regex both powerful and hard to read back — a pattern like ^\d{3}-\d{3}-\d{4}$ is unambiguous to a regex engine and nearly opaque to a human seeing it cold, which is why testing a pattern against real sample data, rather than reasoning about it purely in your head, is how most people actually write correct regex.

This tool runs your pattern against your test text live, using your browser's native regex engine — the exact same engine your code will use if you're writing JavaScript, since there's no simulation layer in between. Matches highlight directly in the text as you type either the pattern or the test string, so you see immediately whether a change made the pattern more or less permissive, rather than running a script and reading through printed output. The four flags cover the cases that come up constantly: g (global) finds every match instead of stopping at the first, i (case insensitive) ignores letter casing, m (multiline) changes ^ and $ to match the start and end of each line rather than only the whole string, and s (dotall) lets . match newline characters, which it doesn't by default.

The plain-language breakdown exists because regex syntax is genuinely difficult to hold in working memory — the difference between {3} and {3,}, or between a capturing group (...) and a non-capturing group (?:...), is one character but changes behavior significantly. Rather than requiring you to look up every symbol, the tool walks through your pattern and translates each token — anchors, character classes, quantifiers, groups — into a short description, so you can sanity-check that the pattern says what you meant it to say, not just what it happens to match on your current test string.

A caution worth stating plainly: a pattern that works on your test cases isn't automatically correct for every input it will ever see in production — email validation regexes in particular are a notorious trap, since the actual specification for a valid email address is far more permissive than almost any regex people write for it. Use this tool to build and sanity-check a pattern quickly, but for anything security- or validation-critical, pair it with real test cases covering the edge cases that matter for your use, not just the happy path.