Regex Tester
Test regular expressions against text in real-time.
About Regex Tester
Write a pattern between the slashes, put your flags in the narrow box after them, and paste something to run it against. The pattern is compiled with the browser's own RegExp constructor on every keystroke, and each match is shaded in place in the panel below.
The engine is the one you ship on
Nothing here reimplements matching. Your pattern goes to V8, SpiderMonkey or JavaScriptCore exactly as typed, which means a result that works in this box works identically in a Node script or a browser bundle. It also means the flavour is ECMAScript and only ECMAScript — patterns copied from a Python codebase, a .htaccess file or a Java validator may compile and still mean something different.
What to watch in the output
The match count above the panel is the fastest signal that something is off. A greedy quantifier collapsing several intended matches into one shows up as a count of 1 with most of the text highlighted; an over-eager character class shows up as a count far higher than expected. Highlighting the matches inside the original text rather than listing them separately is deliberate — it is the only way to see that a pattern is also consuming the comma, the closing bracket or the trailing space next to what you wanted.
Deliberate limits
This is a matcher, not a workbench. There is no capture-group table, no replacement preview, no plain-English breakdown of the pattern and no button that exports the matches — the results panel is your test string with the matches shaded inside it, so what you can copy out is the text, not a list of hits. Collection also stops after ten thousand matches so a large paste cannot freeze the page. What it is good at is the tight loop: adjust one character, glance at the count, adjust again. To compare two candidate patterns, keep the test string fixed and watch how the count and the shaded spans move as you swap between them.
Patterns worth not writing
Some jobs look like regex problems and are not. HTML and XML nest arbitrarily deeply, so no pattern parses them reliably; use a DOM parser. Email validation against the full grammar is famously unwinnable — check for an at sign with something on each side, then send a confirmation message. Your test text and pattern stay in this tab throughout; nothing is uploaded, logged or shared.
Your Browser Is The Engine
The pattern is handed straight to the RegExp constructor, so behaviour is whatever your browser does — including lookbehind, named groups and the v flag on current versions. No re-implementation to disagree with production.
Every Match Highlighted In Place
Matches are shaded inside the original text rather than listed apart from it, which is how you notice a pattern quietly swallowing the whitespace or the delimiter on either side.
Errors Reported Verbatim
An unterminated group or an unknown flag shows the engine's own message, flags and all — typing (a with the default g flag gives "Invalid regular expression: /(a/g: Unterminated group" — with no rewording in between.
Frequently Asked Questions
Which flags can I put in the small box?
Any that your browser accepts: g for every match rather than just the first, i for case-insensitive, m to make caret and dollar match at line breaks, s to let a dot match a newline, u and v for full Unicode handling, y to anchor each attempt at the previous match's end, and d to record capture positions. Anything else throws immediately — a stray q gives "Invalid flags supplied to RegExp constructor 'q'", and so does repeating a flag.
Why does removing the g flag leave only one highlight?
Because that is what g means. Without it the engine reports the first match and stops, which is right for a validation check but not for extracting several values. If the count jumps from one to many the moment you type g, your pattern was fine all along. The opposite trap bites in real code: a global regex kept in a variable carries lastIndex between calls, so repeated tests alternate true and false.
Does it show my capture groups?
No — the count and the highlighting cover the whole match only, so a pattern with capturing parentheses looks the same here as one without. That is worth knowing before you conclude a group is working. Wrap the part you care about in a lookahead or trim the pattern down until the full match is exactly the text you want to capture, and you can verify it visually.
Why did the page freeze on a long test string?
Almost certainly catastrophic backtracking. Nested quantifiers over the same characters, the classic being a pattern shaped like (a+)+b, make the engine explore an exponential number of ways to split the input, and since matching runs on the page's main thread the tab stops responding until it finishes. Reload and rewrite the pattern to be unambiguous. This is not a browser quirk — the same expression can stall a production service, which is the CPU-exhaustion class of denial of service.
My PCRE pattern behaves differently here. Why?
JavaScript is a distinct flavour and some borrowed syntax is silently valid rather than an error. \A and \z are the sharpest edge: in Perl or Python they anchor to the start and end of the subject, but with no flags set JavaScript treats \A as a plain letter A, so the pattern quietly matches the wrong thing. Add the u flag and it becomes a proper error instead. Possessive quantifiers, atomic groups, recursion and conditionals have no equivalent at all — use caret and dollar for anchoring.
Is there a limit on how many matches it will show?
Ten thousand. Beyond that the tool stops collecting, appends a plus sign to the count and prints a notice, because building highlight elements for every match in a very large body of text would otherwise lock up the page. Anything past the cut-off is left unhighlighted. Zero-width matches, which a pattern like a* produces at every position, are handled without looping forever but do count toward that ceiling.