Regex tester online for JavaScript
Write a pattern and watch the matches highlight as you type, with every capture group listed out.
Runs entirely in your browser. Your patterns and test text are never uploaded.
How to use the regex tester
- Type your pattern between the two slashes. Do not include the slashes themselves — they are shown to make clear where the pattern starts and ends.
- Set your flags with the checkboxes, or type them directly into the small box after the closing slash. Global is on by default because you almost always want every match rather than just the first.
- Paste your test text underneath. Matching runs on every keystroke, so you can watch a pattern go from matching nothing to matching too much and correct it as you go.
- Read the match table. Each row shows the full match, its position in the text, and every capture group separately — which is usually where a pattern that "does not work" turns out to be capturing the wrong part.
What you can use it for
Building a validation pattern before putting it into a form is the safest way to do it. An email or phone pattern that looks right and quietly rejects legitimate addresses is a real cost, and the only way to know is to throw a list of awkward real examples at it and see what survives.
Extracting data from messy text is where regular expressions earn their keep. Pulling every URL out of an export, every invoice number out of a log, every date out of a scraped page — write the pattern here against a real sample first, then move it into your code once the match table shows exactly what you expect.
Search-and-replace across a codebase is safer when the pattern has been tested. Most editors accept a regular expression in their find dialog, and a badly written one can match far more than intended across hundreds of files. Testing against a representative sample first is cheap insurance.
It is also the fastest way to learn regular expressions. The instant feedback loop — change one character, see the highlighting change — teaches the syntax faster than any reference document, because you can see immediately what a quantifier or a character class actually does.
Things to know
This uses the JavaScript regular expression engine, the same one that runs in your code. Patterns tested here behave identically in a browser or in Node. PHP, Python and Go use different engines with different syntax for some features, so a pattern using lookbehind or named groups may need adjusting for those.
The global flag changes behaviour more than people expect. Without it, only the first match is returned. With it, the regular expression object keeps an internal position between calls, which is a classic source of bugs when the same object is reused in a loop.
A greedy quantifier matches as much as it can. The pattern <.+> against "bold" matches the entire string rather than just the first tag, because .+ takes everything it can and then backtracks. Adding a question mark to make it <.+?> makes it lazy and matches each tag separately.
Some patterns can be catastrophically slow. Nested quantifiers such as (a+)+ against a long non-matching string cause the engine to try an exponential number of paths, and the page will freeze. If typing a pattern makes the tab hang, that is what happened — reload and simplify the nesting.
Frequently asked questions
The most common causes are an unescaped special character and a missing flag. Characters like . + * ? ( ) [ ] { } | ^ $ all have special meanings and need a backslash before them to match literally. And if your text spans several lines but your pattern uses ^ or $, you probably need the multiline flag.
Parentheses create a capture group, which extracts a piece of the match separately. An empty group usually means that part of the pattern was optional and did not participate in the match, or you used a non-capturing group (?:...) which deliberately does not capture. The match table shows each group separately so you can see which is which.
Close but not identical. The core syntax — character classes, quantifiers, anchors, groups — is shared. Differences appear in lookbehind support, named group syntax, Unicode property escapes and some flags. Test in the engine you will actually run the pattern in when it matters.
You can, but be careful how strict you make it. The formal specification for a valid email address is far more permissive than most patterns allow, and over-strict validation rejects real customers. A loose check for something-@-something-dot-something plus an actual confirmation email is more reliable than any pattern.
No. The pattern and the text both stay in your browser and matching runs locally. That matters when you are testing patterns against production log samples or customer data, which is exactly when you should not be pasting into a remote service.