Write a pattern, paste the text you are really working against, and watch every match light up as you type, with capture groups, named groups, offsets, a replacement preview, and syntax errors explained in English rather than in the runtime's own words.
3 matches, 3 capture groups. First match at index 9.
Or paste a whole literal such as /\d+/gi and the flags come with it. Everything below recalculates on every keystroke.
Compiles. 3 capture groups (year, month, day) · pattern is 70 characters.
/\b(?<year>\d{4})-(?<month>0[1-9]|1[0-2])-(?<day>0[1-9]|[12]\d|3[01])\b/g against 114 characters.
Matches tint as you type. Adjacent matches alternate shade and each one carries a rule down its left edge, so two touching hits never read as one.
114 / 100,000 characters · 4 lines
Every match, with its offsets and its capture groups.
Turn on the d flag to see where each group sits, not just what it holds.
Each one loads its pattern, its flags, a replacement, and sample text containing the cases it deliberately rejects.
Anchored patterns that ask whether a whole line is the right shape.
Unanchored patterns that pull items out of running prose or logs.
Patterns whose point is the substitution rather than the search.
JavaScript syntax specifically: the notes call out the places it parts company with PCRE and with Python.
One position in the subject, and the set of characters allowed to fill it.
How many times the thing in front may repeat. Greedy by default; add ? to make it lazy.
Zero-width assertions. They consume nothing and only ask about position.
Capturing is what turns a test into extracted data, and what costs memory when you did not need it.
Assertions that inspect the text around the current position without consuming it.
Set on the regex as a whole. JavaScript has no inline (?i) modifier: the flag applies everywhere or nowhere.
Twelve characters are special. To match one literally, put a backslash in front of it.
The pattern goes straight to the runtime's RegExp constructor, so what you see is what Node and the browser will do. Python's re, PCRE, Go's RE2, and grep all differ: sometimes in syntax, sometimes in what identical syntax means.
JavaScript keeps \d, \w, and \b on ASCII regardless of the u flag. Python and .NET widen \d to every Unicode decimal digit by default, so ٢٠٢٦ passes there and fails here. Ask for \p{Nd} when you want the wide meaning.
No regular expression can match balanced brackets, which rules out HTML, JSON, and source code however long the pattern grows. The HTML preset here is deliberately labelled as a skim, not a parser.
Everything on this page runs in your browser against your browser’s own RegExp implementation: no pattern, no test text, and no result is ever sent anywhere. The guards are stated rather than implied: up to 100,000 characters of test text, 5,000 matches, and 250 ms of wall clock per run, after which the run stops and says so. A zero-length match always advances the cursor by a full code point, so a pattern like /a*/g terminates instead of looping.
When the subject is JSON, a pattern is the wrong instrument: parse it, then read the tree and the exact line of any syntax error.
For the neighbouring question. When you want to know what changed between two versions rather than what matches in one, a diff answers directly.
The UUID preset here insists on a correct version and variant nibble; this produces identifiers that carry them, across v1, v4, v5, v6, and v7.
A regular expression is a tiny program, and the reason it is hard to debug is that it runs invisibly: you see the answer, never the working. This page makes the working visible. Your pattern is compiled by the browser's own RegExp constructor, run over your text under a cap on length, match count, and wall-clock time, and reported match by match: where each one starts and ends, what every capture group holds, which groups did not participate at all, and what a substitution would produce. Because it is the runtime's engine and not a reimplementation, the results are the results your JavaScript will get. They are not, honestly, the results Python, PCRE, Go's RE2, or grep will get.
Type the pattern without the surrounding slashes, or paste a whole literal such as /\d+/gi and the flags come across with it. Each of the seven flags is a labelled switch rather than a letter to remember, and a syntax error is answered in a sentence instead of the runtime's phrasing.
Real input, not a contrived example: a log excerpt, a CSV column, a page of prose. Matches highlight as you type, alternating shade so two matches that touch are still two matches, and a zero-width match is drawn as a marker rather than disappearing.
Every match lists its offsets and each numbered and named group, including the ones that did not participate. Switch to Replace to preview a substitution with $1, $<name>, $& and friends expanded, or to Split to see what String.split makes of the same pattern.
A zero-length match advances the cursor by a whole code point, so /a*/g terminates instead of looping forever. A wall-clock budget stops a run that has started grinding and says the pattern is backtracking badly, rather than freezing behind a spinner that never resolves.
On /(a)|(b)/ against “b”, group 1 is undefined and group 2 holds the match. Testers that drop the empty slot silently renumber everything after it. Here the slot stays, labelled as not having participated, which is exactly the distinction that breaks code downstream.
Turn on the d flag and each capture reports its own start and end index, read from match.indices. Without it you get the position of the whole match and have to search for the group's text again, which goes wrong the moment the same text appears twice.
$1, $<name>, $&, $` and $' and $$ are all expanded here rather than described, including the rule that $12 means group 12 when it exists and group 1 followed by a “2” when it does not. The output is checked against what String.replace produces.
“Invalid regular expression: /(/: Unterminated group” becomes “A ( was opened and never closed”, with a note that a literal bracket needs escaping. Around fifteen error families are recognised across the wording that V8, JavaScriptCore, and SpiderMonkey each use.
The email pattern is described as the pragmatic form that catches typos, not as RFC 5322 validation. The IPv4 one bounds each octet to 255 and admits it will still find an address inside a version string. Every preset ships with sample text containing the cases it rejects.
The one already running in your browser. There is no engine bundled into this page: your pattern is handed to the JavaScript runtime's own RegExp constructor and the matches you see are the matches your code will get. That makes the results exactly right for JavaScript, TypeScript, Node, Deno, and Bun. For anything else they are only approximately right. Python's re, PCRE in PHP and Perl, Go's RE2, Rust's regex crate, .NET, Java, grep, sed, and ripgrep all differ, sometimes in syntax and sometimes in what the same syntax means. If the pattern is destined for a different language, test it there before shipping it.
A greedy quantifier takes as much as it possibly can and then gives characters back one at a time until the rest of the pattern fits. A lazy one (written by adding a question mark, so *? +? ?? {n,m}?) takes as little as it can and grows only when forced. The classic demonstration is /<.+>/ against “<a><b>”: the greedy .+ swallows everything to the end, backtracks to the last “>”, and returns “<a><b>” as a single match. Change it to /<.+?>/ and you get “<a>”, then “<b>”. Neither is more correct; they answer different questions. The practical rule is that greedy is the right default when the delimiter is unique and lazy is the right default when it repeats.
It is what happens when a pattern can split the same text many different ways and the match ultimately fails. JavaScript matches by backtracking, so on failure it retries every remaining combination before giving up. The textbook trigger is a repeat inside a repeat, such as /(a+)+$/ against a long run of “a” followed by one “b”. There are exponentially many ways to divide 30 a's into groups of one or more, and the engine tries all of them before concluding the “$” cannot match. Thirty characters take milliseconds; forty take about a thousand times longer. The fixes are to make the inner and outer repeats unable to match the same text, to replace a quantified group with a character class, or to anchor the pattern so failure is detected early. This page scans your pattern for those shapes and names them before you run it.
Lookahead was in the language from the beginning, but lookbehind only landed in ES2018 (more than twenty years later), and until Safari shipped it in 2023 a pattern using it threw a syntax error on a browser many sites still supported. The delay was partly the general slowdown in language evolution between ES4's abandonment and ES6, and partly that lookbehind is genuinely harder to implement: the engine has to match backwards from the current position. JavaScript's implementation ended up better than most, because unlike PCRE, Python's re, and Java it allows variable-length lookbehind. /(?<=\$\d+ )item/ is legal here and rejected outright in those. If a pattern of yours needs to run in an old environment, the traditional workaround is to capture the preceding context in a group and discard it afterwards.
The u flag, from ES2015, puts the pattern into Unicode mode: astral characters such as emoji count as one unit rather than two UTF-16 halves, \u{1F600} becomes valid, \p{…} property escapes are unlocked, and escapes with no meaning become syntax errors instead of being quietly ignored. The v flag, from ES2024, is a superset that adds set notation inside character classes (difference with --, intersection with &&, and multi-character string properties), so you can write [\p{Letter}--[a-z]] to mean “any letter except an ASCII lowercase one”. The two flags are mutually exclusive: a regex is either u-mode or v-mode, never both. This page offers u and not v, because a pair of buttons that silently cancel each other is a worse interface than one that is honest about its scope.
Because a regex carrying the g or y flag is stateful. It stores a lastIndex property, and exec and test both start from there and update it on success. Store one in a module-level constant, call test twice on the same string, and the second call starts halfway through and returns false. The same bug bites when a global regex is reused across items in a loop. There are three ways out: build the regex fresh where it is used, reset lastIndex to 0 before each call, or use matchAll and String.match, which do not leave the cursor where you can trip over it. This page sidesteps the problem entirely by compiling a private working copy for every run, so the regex you are looking at is never the one being mutated.
Several things, and knowing which ones saves a lot of confused debugging when you copy a pattern across. There are no atomic groups: PCRE's (?>…) commits to a match and refuses to backtrack into it, which is the standard hand-fix for catastrophic backtracking, and JavaScript's only substitute is a lookahead wrapping a capture. There are no possessive quantifiers (a*+) for the same reason. There is no recursion (?R) and there are no subroutine calls, so balanced brackets are out of reach. There are no inline modifiers: (?i) mid-pattern is a syntax error, because a JavaScript flag applies to the whole regex or not at all. There are no conditionals, no \A \z \Z anchors, no POSIX classes such as [[:alpha:]], and no comment mode. What JavaScript does have that many engines do not is variable-length lookbehind.
No, and the difference is a real source of security bugs. In JavaScript \d is exactly [0-9], always, with or without the u flag. In .NET and Python 3, \d matches any character with the Unicode decimal-digit property by default, which includes Arabic-Indic digits ٠١٢, Devanagari digits, and fullwidth ０１２. A validator written in Python that accepts ٢٠٢٦ and a JavaScript one that rejects it will disagree about the same input, which is precisely the sort of mismatch that gets exploited. The same caution applies to \w, which is [A-Za-z0-9_] here and so does not consider “é” a word character, and to \b, which is defined in terms of \w and therefore lands in the middle of “naïve”. If you want Unicode semantics in JavaScript you have to ask for them explicitly: \p{Nd} with the u flag for digits, \p{L} for letters.
When the thing you are matching can nest. Regular expressions in the formal sense cannot count, and although backreferences push JavaScript's engine past a strictly regular language, it still cannot match balanced structure. That rules out HTML, XML, JSON, source code, and any bracket language, not because the pattern is hard to write but because no pattern exists. Use DOMParser, JSON.parse, or a real parser. Three softer signals point the same way: the pattern has grown past a line or two and nobody can read it, it needs a comment to explain each clause, or it keeps acquiring special cases for inputs it was supposed to already handle. A regular expression is at its best finding and validating flat, well-shaped fragments (a date, a hex colour, a log prefix), and at its worst pretending to be a grammar.
They are the substitution patterns String.replace understands in the replacement string. $1 through $99 insert the text of that numbered capture group, and $<name> does the same for a named one. $& inserts the whole match. $` inserts everything before the match and $' inserts everything after it; both are surprisingly useful for wrapping and surprisingly easy to trigger by accident, since a backslash does not escape them. $$ inserts a single literal dollar sign. Two rules catch people out: a reference to a group that does not exist is left in the output as plain text rather than throwing, and $12 means group 12 if the pattern has twelve groups and group 1 followed by the character “2” if it does not. This page expands all of them in the preview and flags any reference it could not resolve.
Explore the growing collection for calculations, documents, writing, and everyday work.