Regex Tester — Free Online Pattern Debugger

Regular expressions are the precision instruments of text processing — a single line of regex can validate an email address, extract phone numbers from a document, or rewrite thousands of lines at once. They are also famously easy to get subtly wrong: one misplaced quantifier and your pattern matches everything, or nothing, with no explanation.

That is why experienced developers never write a regex blind. They test it against real sample text, watch which parts match, and iterate. A live regex tester turns that loop from minutes into seconds: type a pattern, see matches light up instantly, adjust, and repeat until the pattern does exactly what you intended.

This free regex tester runs the same JavaScript regex engine your browser and Node.js use. Paste your test string, type your pattern, set flags like g or i, and every match is listed with its exact index alongside a highlighted preview. Invalid patterns produce the engine’s real error message instead of a blank stare.

How to use the regex tester

1. Enter your pattern without surrounding slashes — for example b[w.-]+@[w.-]+.w+b to find email addresses.
2. Set flags. g finds all matches, i ignores case, m makes ^/$ work per line, s lets . match newlines.
3. Paste your test string — real data from your project beats made-up examples every time.
4. Review the matches. Each match shows its text and character index, so you can verify boundaries precisely.
5. Check the highlighted preview to see matches in context, then refine the pattern until only the right text lights up.

Key features & benefits

• Live results as you type. No run button, no waiting — the match list updates with every keystroke.
• Match positions included. Each match reports its exact index, which is what you need when writing extraction code.
• Highlighted preview. Matches are marked inside the full text so you can judge context, not just isolated hits.
• Real engine errors. An unbalanced parenthesis or bad quantifier shows JavaScript’s actual error message, pointing you at the problem.
• Full flag support. Global, case-insensitive, multiline, dotAll, unicode and sticky flags are all accepted.
• Empty-match visibility. Patterns that match empty strings are shown explicitly instead of silently confusing you.

Practical regex tips with examples

A few patterns cover a surprising share of daily work. Keep these shapes in mind and adapt them rather than starting from zero.

Validate, then extract

Use anchors for validation — ^d{4}-d{2}-d{2}$ accepts only a complete date — but drop the anchors when extracting from larger text. Mixing the two jobs up is the most common beginner mistake.

Prefer specific character classes

.* is greedy and sloppy; [^<]* or d+ say what you actually mean and fail loudly on unexpected input. When parsing markup, remember that regex is the wrong tool for nested HTML — decode entities first with our HTML entity encoder/decoder if you are scraping encoded text.

Test the edges

Always include empty strings, very long strings, and unicode in your test text. The u flag changes how characters like emoji are counted, and it is better to discover that here than in production. Pair tricky patterns with our JSON formatter when your matches feed into structured data.

Frequently asked questions

How It Works: Under the Hood

Regular expressions are compiled into finite automata — state machines that consume the input string character by character. Simple patterns (d+, [a-z]+) compile to efficient DFAs that run in linear time. The trouble starts with backtracking: features like nested quantifiers ((a+)+), alternation with overlap, and lookarounds force the engine to explore exponentially many paths when a match fails — the infamous catastrophic backtracking that hangs on inputs like “aaaaaaaaaaaaaaaaaaaaaa!”.

Most testers (including browser-based ones) use the JavaScript RegExp engine, which differs from PCRE (PHP), .NET, or Python’s re in subtle ways: lookbehind support, named-group syntax, and Unicode flag behavior all vary. A pattern validated here may behave differently in production if the engines differ — always confirm which engine your target uses.

Flags change engine behavior fundamentally: g (global — find all matches, not just the first), i (case-insensitive), m (multiline — ^/$ match line boundaries, not just string boundaries), s (dotAll — . matches newlines). The same pattern with different flags is effectively a different program.

Real-World Use Cases

• Form validation: a developer tests an email pattern against 20 real-world addresses (including name+tag@domain.co.uk and quoted local parts) before shipping — catching the false rejections that anger users.
• Log parsing: an SRE builds a pattern to extract timestamps, log levels, and request IDs from 2GB of server logs, iterating in the tester until it handles every observed line format.
• Data cleanup: an analyst writes a find-and-replace regex to normalize 50,000 phone numbers (“(555) 123-4567” → “+15551234567”), testing edge cases like extensions and country codes first.
• Code refactoring: a developer crafts a pattern matching an old API call signature across a codebase, verifying it doesn’t also match similarly-named functions before running the replacement.
• Content moderation: a community manager tests a profanity/obfuscation filter against leetspeak variants (a$$, @ss) to see what slips through before deploying.

Advanced Tips

• Test the failure cases, not just matches: paste inputs that should not match. A pattern that matches everything you want but also matches garbage is worse than useless — it’s a false sense of security.
• Use atomic groups or possessive quantifiers where supported: (?>a+) or a++ prevent the engine from backtracking into already-matched territory — the standard fix for catastrophic backtracking on nested quantifiers.
• Anchor your patterns: ^d+$ validates “the whole string is digits”; d+ merely finds digits somewhere. Unanchored validation patterns are the #1 source of “but it passed validation!” bugs.
• Prefer explicit character classes over . : [^s@]+ is clearer and safer than .+ in email-like patterns — the dot matches things you’ll regret, including the delimiters you’re trying to split on.

Common Mistakes to Avoid

• Validating emails with a mega-regex: the RFC-5322-compliant email regex is 6,000+ characters and still wrong for edge cases. Send a confirmation email instead — it’s the only real validation.
• Forgetting to escape metacharacters: matching a literal dot in “file.txt” requires . — a bare . matches any character, so “filetxt” and “file_txt” match too.
• Greedy vs lazy confusion: <.*> on “<b>hi</b>” matches the whole string (greedy), not just the tags. Use <.*?> (lazy) or better, <[^>]+>.
• Assuming engine parity: lookbehind, named groups, and Unicode property escapes (p{L}) behave differently across JS, Python, PCRE, and .NET. Test in the engine you’ll deploy to — this tester’s JS results are a starting point, not a guarantee.

Reading the Match List Like a Debugger

Beginners stare at the highlighted text; experienced developers read the match list. Each entry shows the matched text and its exact character index, which is what you need when the regex will live inside extraction code — off-by-one boundaries are invisible in a highlight but obvious in an index. Patterns that match empty strings are flagged explicitly instead of silently confusing you, and invalid patterns surface JavaScript’s real error message so you can fix the actual problem. When the pattern is right, minify the script it lives in with the JavaScript minifier.

Taking a Tested Pattern Into Production

A pattern that works in the tester can still break in code. Watch for escaping: backslashes need doubling inside string literals in most languages, and delimiters differ — JavaScript uses /pattern/flags while Python uses raw strings. Flags matter too: a pattern tuned with the m flag behaves differently without it. Paste real data from your project rather than tidy examples, because production text always contains the edge case you forgot. For patterns that decode or encode data, the Base64 encoder decoder is a handy companion.