Regex cheatsheet for JavaScript — with a live tester that will not hang your tab

JavaScript, meaning the RegExp built into every browser and into Node. It matters more than most people expect. \d is exactly [0-9] here and stays that way even under the u flag, while PCRE with (*UCP), .NET and Python 3 all make it match Unicode digits — so a pattern that validated numbers correctly in Python quietly accepts ٣٤٥ nowhere and rejects it here. \A, \z and \Z do not exist in JavaScript and silently match the literal letters instead of erroring. Atomic groups and possessive quantifiers do not exist either, which removes the standard cure for catastrophic backtracking. And lookbehind is more permissive here than in PCRE, not less — see below.

Because it matches too much and then backtracks to fit, and both halves of that cause trouble. Run /<.+>/ against “<b>hi</b>” and you match the entire string, not the tag: the dot took everything and gave back only enough to find a final “>”. The lazy form /<.+?>/ gives you “<b>”, which is usually what you wanted, but it still walks forward one character at a time. The better pattern is /<[^>]+>/ — a negated class that physically cannot cross a “>”, so the engine finds the boundary without backtracking at all. As a rule: when there is a delimiter, say what the content may not contain rather than saying “anything” and hoping the quantifier sorts it out.

It is what happens when a pattern can split the same text between two quantifiers in exponentially many ways. The classic is /(a+)+b/ against a run of “a” with no “b”: the engine must try every way of partitioning those characters between the inner and outer plus before it can conclude there is no match, and each extra “a” doubles the work. Thirty of them can take seconds; forty can hang a tab. The shapes to watch for are nested quantifiers — (x+)+, (x*)* — and alternations whose branches can match the same text, like (a|a)+. The cure in other languages is an atomic group; JavaScript does not have one, so you rewrite until the alternatives cannot overlap: [^"]* instead of .*? between quotes, or a single character class instead of a nested group. Test on a long string that does NOT match, because a pattern that matches usually returns fast and hides the problem.

Because a regex runs to completion inside a single function call, and JavaScript on one thread does nothing else while a function is running. There is no yield point inside .exec(), so a timer you set beforehand does not fire, a click is not delivered, and code that would check a limit never gets a turn — which is exactly why a cap on the number of matches, or on the length of the input, cannot save you: your own guard is queued behind the thing it was meant to guard. The only real escape is to run the pattern on a different thread and destroy that thread. This page does that: your pattern goes to a Web Worker, the page keeps a 1.5-second timer, and on expiry it calls terminate() on the worker and starts a fresh one. Terminating is not a request the worker can decline, which is what makes it reliable. If you ever need this in your own code — validating a regex a user supplied, for instance — a worker with a timeout is the pattern, and there is no in-thread substitute for it.

Because it has the g flag and you reused the object. A RegExp with g or y keeps a lastIndex property, and .test() and .exec() both start from it and update it. So calling re.test(s) twice on the same string gives true and then false, which looks like the string changed. The fixes: build a fresh RegExp for each run, or use a method that does not carry state — String.prototype.match with g, or matchAll, which is what you want anyway when you need every match with its groups. This page builds a new RegExp on every run for exactly that reason.

There isn’t one, and this is the most useful thing on the page. Every short “email regex” you find is wrong in both directions: it rejects addresses that are legal — quoted local parts, plus-addressing, new top-level domains, an intranet host with no dot at all — and accepts ones that will bounce, because syntax cannot tell you whether a mailbox exists. RFC 5322’s grammar is genuinely too complex to be worth writing out, and matching it exactly still would not tell you the address works. The one pattern with an authority behind it is the HTML specification’s definition for <input type="email">, which the spec itself calls a “willful violation” of RFC 5322 precisely because it chose to be practical rather than complete — so use type="email" and let the browser apply it. In your own code, check for exactly one @ with something on both sides, and then send a confirmation message. Delivery is the only validation there is.

Named groups, (?<name>…), have been in every current engine for years and are safe. Lookbehind, (?<=…) and (?<!…), arrived in the same version of the language but Safari shipped it years after Chrome and Firefox, so it is the one construct worth checking if you still support genuinely old iOS. Worth knowing: JavaScript’s lookbehind is variable-length, so (?<=\w+\s) is legal here and rejected outright by PCRE, which requires a fixed width. That makes this the rare case where a pattern copied out of JavaScript may fail elsewhere rather than the other way round.

You need u whenever the pattern contains \p{…} or \u{…}, and whenever the text may contain characters outside the Basic Multilingual Plane — emoji, rarer CJK — because without u the engine works in UTF-16 code units and a dot can match half of an emoji. The v flag, unicodeSets, is a superset: everything u does, plus set operations inside classes ([\p{L}--[aeiou]] for difference, && for intersection), \q{…} for multi-character strings inside a class, and properties of strings such as \p{RGI_Emoji} that match whole emoji sequences. u and v cannot both be set — the engine throws — so treat v as the newer replacement rather than an addition.

Take the string <b>bold</b> and <b>more</b>. The greedy /<.+>/ returns one match: the whole string, because the dot took everything and then gave back just enough to find a closing angle bracket at the very end. The lazy /<.+?>/ returns four matches — <b>, </b>, <b>, </b> — because it takes as little as possible and stops at the first “>” each time. The non-backtracking /<[^>]+>/ returns the same four, faster, because the class cannot cross a “>” to begin with. Paste all three into the tester above; the difference is easier to see than to describe.

No. Everything runs in the JavaScript engine already in your browser, in this tab. There is no request of any kind, and nothing is written to localStorage — which matters here more than on most pages, because the strings people paste into a regex tester are log lines, customer records and API responses.