Regex Tester
100% private — runs on your device, never uploaded. Works offline once loaded.
Write a regular expression, set flags (g, i, m…) and test it against sample text to see every match with its index. Everything runs locally in your browser.
What a regular expression engine is actually doing
A regular expression describes a pattern, and the engine tries to match that pattern against your text character by character, backtracking and retrying whenever a branch fails. JavaScript's engine (the one this tool runs, since it executes entirely in your browser) is what's called a backtracking NFA — the same general family as PCRE (used by PHP, and closely mirrored by Python's re module), but with its own quirks around lookbehind support, Unicode property escapes, and named groups, which is why a pattern that works perfectly in one language can behave slightly differently in another.
Every match this tool finds is shown with its starting index and, if your pattern includes parentheses, the text captured by each group — which is usually more useful for real debugging than just knowing whether a match occurred.
Flags change how the whole pattern behaves
A pattern's flags aren't cosmetic — they change matching behavior entirely. g (global) finds every match instead of stopping at the first one; i makes matching case-insensitive; m (multiline) makes ^ and $ match the start/end of each line rather than the whole string; s lets . match newline characters, which it doesn't by default. Forgetting g is probably the single most common reason a "working" regex only replaces or extracts the first occurrence in a block of text.
Where testing a pattern first actually saves time
Regex shows up in log parsing (pulling IP addresses or error codes out of server logs), form validation (checking phone number or postal code formats before they hit a database), find-and-replace across a codebase, and data extraction from semi-structured text like CSV exports or scraped HTML. Writing a pattern blind and running it directly against production data or a live script is how you end up with either silent false negatives or, worse, a pattern with catastrophic backtracking that hangs the process on certain inputs — testing against representative sample text first catches both.
- Greedy quantifiers (
.*,+) grab as much as possible then backtrack — often not what you want with HTML or nested delimiters. - Lazy quantifiers (
.*?,+?) grab as little as possible instead, which is usually the safer default for anything between delimiters. - Nested quantifiers like
(a+)+are the classic cause of catastrophic, exponential-time backtracking on pathological input.
A practical tip for building patterns incrementally
Build complex patterns in small pieces rather than all at once: write a fragment that matches the simplest case, confirm it in the match list below, then extend it — chasing one wrong match at a time is far faster than debugging a 200-character pattern that silently matches nothing at all.
Frequently asked questions
Is my text uploaded?
No — regex testing happens on your device.
Which regex flavour?
JavaScript (ECMAScript) regular expressions.
Why does my regex work in Python but not here, or vice versa?
Regex flavors differ — JavaScript lacks some PCRE features like atomic groups and possessive quantifiers, while Python's re module has its own syntax for named groups (?P<name>...) versus JavaScript's (?<name>...). Since this tool uses JavaScript's engine, always test against the flavor your production code will actually run.
What's the difference between a capturing and non-capturing group?
(pattern) captures the matched text so you can reference it later, while (?:pattern) groups the pattern for logic purposes — like applying a quantifier — without storing the match, which is slightly more efficient when you don't need the captured value.
Is there a limit to how much text I can paste in?
There's no hard-coded limit, but very large text combined with a pathological pattern can make matching slow or freeze the tab, since matching runs synchronously in your browser.
Why did a valid-looking email fail to match my pattern?
Fully correct email validation by regex alone is notoriously hard — the official spec (RFC 5322) allows far more edge cases (quoted strings, comments, unusual but legal characters) than most hand-written patterns account for, so most practical patterns intentionally cover the common 95% rather than the full spec.
Does this support lookahead and lookbehind?
Yes — JavaScript supports both positive/negative lookahead ((?=...), (?!...)) and, in modern browsers, lookbehind ((?<=...), (?<!...)), which are useful for matching a pattern only when adjacent to other text without including that text in the match.
Is my test text sent anywhere?
No — matching happens using your browser's built-in regex engine, so neither your pattern nor your sample text leaves the page.
Advertisement