A searchable regular expression cheat sheet for the JavaScript flavour: character classes, bracket sets, quantifiers, anchors, lookaround, groups and flags, each with an example.
Forty-one regex tokens with examples. Filter across tokens, descriptions and examples, then copy the syntax you need. Covers the JavaScript (ECMAScript) flavour used in browsers and Node.js.
No syntax entry matches that filter.
Regular expressions are dense by design. A pattern like ^(?:\d{1,3}\.){3}\d{1,3}$ packs an entire IPv4 validator into thirty characters, which is wonderful when you wrote it and miserable when you are reading someone else's. Most of the difficulty is not conceptual — it is that the vocabulary is large, terse and easy to half-remember.
This page is a lookup table for that vocabulary, organised the way patterns are actually built: what matches a single character, how to define your own character sets, how to say "repeat this", where to anchor the match, how to group and alternate, and which flags change the engine's behaviour. The filter searches tokens, descriptions and examples at once, so typing "lazy", "boundary" or "lookbehind" jumps straight to the row you half-remember.
Regular expressions are not one language. Grep, PCRE, Python, Java, Go's RE2 and JavaScript all share a common core but disagree at the edges. Everything listed here targets the JavaScript flavour defined by ECMAScript, because that is what runs in the browser, in Node.js and in most front-end tooling.
Three differences are worth calling out. First, lookbehind — (?<=...) and (?<!...) — is supported in modern JavaScript engines but absent from Go's RE2 and from older Safari versions, so patterns that rely on it are not portable everywhere. Second, JavaScript has no x verbose flag, so you cannot spread a pattern across multiple lines with comments the way Python allows; long patterns are usually assembled from string fragments instead. Third, \d and \w are ASCII-only by default in JavaScript, so \w does not match accented letters or CJK characters unless you switch to Unicode property escapes such as \p{L} with the u flag.
Two habits prevent most regex pain. The first is to anchor deliberately. An unanchored pattern searches for a match anywhere in the string, which is what you want when scanning and almost never what you want when validating. Adding ^ and $ turns "contains something that looks like a date" into "is a date", and that distinction is behind a surprising share of validation bugs.
The second is to prefer laziness and negated character classes over greedy wildcards. The classic mistake is <.+> on HTML-like text: because + is greedy, it swallows everything up to the last > on the line. Writing <.+?> or, better, <[^>]+> matches a single tag. The negated-class version is also considerably faster, because the engine never has to backtrack.
Finally, be aware of catastrophic backtracking. Nesting quantifiers, as in (a+)+b, can make the engine explore exponentially many ways to split the input before it concludes there is no match, which turns a validation call into a denial-of-service vector when the pattern touches user input. If a pattern contains a quantified group that itself contains a quantifier, rewrite it — usually a single character class with one quantifier does the same job in linear time. And when a pattern grows past a line or two, the honest answer is often that a real parser is the right tool and the regex is not.