JavaScript regular expressions implement the ECMAScript RegExp pattern grammar, which shares many tokens with PCRE, Python, .NET, and Java but diverges in syntax, Unicode behavior, supported flags, and a handful of semantics. A token that compiles in another engine may be rejected by JavaScript or may carry a different meaning, which is why any working list of common regex patterns intended for JavaScript code needs to be checked against the ECMAScript grammar rather than copied from a PCRE or Python reference. The 44-entry Regex Cheat Sheet was built for exactly this kind of lookup: every row contains the exact token, a concise meaning, and a JavaScript example written as a literal so the necessary slash delimiters and flags remain visible, while a Copy button places only the token itself on the clipboard with no surrounding example or explanation. Entries cover characters, character classes, groups and references, quantifiers, assertions, and flags, and every example uses JavaScript APIs such as RegExp.prototype.test and RegExp.prototype.exec rather than syntax borrowed from a command-line engine. Search and category filtering run entirely in the current browser tab, so looking up a token never leaves the page or sends the query anywhere.
What "Common Regex Patterns" Means in JavaScript
The phrase "common regex patterns" usually points to one of two jobs. The first is a quick lookup of a token such as \d, \w, \s, \b, or the dot while writing or reviewing a pattern. The second is a sanity check that a borrowed snippet from a Stack Overflow answer, a Python tutorial, or a shell script is actually valid in the engine that will run it. JavaScript sits in a slightly awkward spot for that second job because its RegExp implementation is close to but not identical with PCRE, the de facto reference for "modern" regular expressions on the web.
Concrete gaps show up fast. \d in JavaScript means ASCII digits 0 through 9; it is not a shortcut for every Unicode decimal digit, as it is in some other engines. \w primarily covers ASCII letters, ASCII digits, and underscore, with a documented Unicode-aware case-folding nuance when the i and u flags are combined. Unicode property escapes such as \p{Letter} require the u or v flag, and JavaScript does not allow u and v on the same RegExp. Lookbehind is written as (?<=...) and (?
The Six Categories of a Dialect-Specific Reference
A curated JavaScript RegExp reference groups entries by what they do at the pattern level. The cheat sheet organizes 44 selected tokens into six non-empty categories, each row showing the category, the exact token, a one-line meaning, and a runnable-style example expressed as a JavaScript literal. The table below summarizes what each category covers so the lookup target is obvious before the search box is even touched.
| Category | What it contains | Sample entries |
|---|---|---|
| Characters | Single-character escapes, Unicode code-point forms, and digit or word shortcuts | ., \d, \w, \s, \u{1F600} |
| Character classes | Bracketed sets, negated classes, ranges, and Unicode property escapes | [abc], [^abc], [a-z], \p{Letter}, \P{Letter} |
| Groups and references | Capturing, named-capturing, and non-capturing groups, alternation, and backreferences | (...), (?<name>...), (?:...), x|y, \1, \k<name> |
| Quantifiers | Greedy and lazy repetition, including exact and bounded counts | *, +, ?, {n}, {n,}, {n,m}, *? |
| Assertions | Anchors, boundaries, lookahead, and lookbehind | ^, $, \b, (?=...), (?!...), (?<=...), (?<!...) |
| Flags | Modifiers applied to the RegExp literal that change matching behavior | g, i, m, s, u, v, y, d |
The category column is not decorative. When a search for "named" returns several rows, narrowing the filter to Groups and references removes the rest so the right token is visible at a glance. Filters combine with the search box, the displayed count always reports the complete number of matches, and an explicit empty state appears when nothing fits, so there is no hidden result cap to worry about while hunting for an uncommon common regex pattern.
Find and Copy a Specific Token in Three Steps
The workflow is deliberately short so it does not interrupt the moment of writing or reviewing a pattern. Every row in the cheat sheet carries the same four pieces of information: category, exact token, meaning, and JavaScript example. Search and category filtering run entirely in the current browser tab, and no query, selected category, copied token, or other input is uploaded to any service.
- Enter a token or concept in the search field. Type a literal symbol such as \d, a flag letter such as u, or a concept such as lookbehind, Unicode, lazy, or named. Symbol searches hit the exact token; concept searches hit meaning text and example text, which keeps the lookup intuitive whichever direction the question comes from.
- Choose a category to narrow the result set. The category selector trims the table to one of the six groups described above, which is useful when a concept term matches more than one row. Review the token, its meaning, and the runnable-style JavaScript example to confirm the token matches the intent before copying.
- Select Copy on the row that contains the right token. The Copy button places only that exact RegExp token on the clipboard. No category label, no slash delimiters from the example, no flag letters, and no surrounding explanation are added, which makes the result drop straight into an existing pattern without polluting it.
Each Copy click requests clipboard access for a single token. A job identifier ensures that only the newest copy attempt may publish success or failure, so a late clipboard response cannot describe a different filtered view. Changing the search or category invalidates an older clipboard job and clears its status, and component cleanup prevents a late clipboard promise from updating an unmounted page. If the browser denies clipboard permission, the tool reports a recoverable error rather than claiming the token was copied.
Flags That Change Pattern Behavior
Flags sit on the literal rather than inside the pattern, and several of them quietly change what tokens mean. A reference that lists the eight flags with concrete effects is more useful than a bare flag index, because the surprising behaviors tend to come from combinations rather than from any single letter. The cheat sheet's flag section lists d, g, i, m, s, u, v, and y, and the table below records what each one actually does to the match.
| Flag | Primary effect on matching |
|---|---|
| g | Enables global matching; affects lastIndex in stateful operations such as RegExp.prototype.exec in a loop. |
| i | Performs case-insensitive matching; combines with u to enable Unicode-aware case folding. |
| m | Changes how ^ and $ treat line boundaries, so they match start and end of any line rather than the whole input. |
| s | Lets the dot (.) match line terminators, which it does not match by default. |
| u | Enables Unicode-aware matching; required for braced Unicode code-point escapes such as \u{1F600} and property escapes such as \p{Letter}. |
| v | Enables UnicodeSets behavior, including class-set operations and properties of strings; cannot be combined with u on the same RegExp. |
| y | Sticky mode; the match must begin at lastIndex rather than anywhere after it. |
| d | Exposes match indices on the result, so each match reports its start and end positions explicitly. |
The u and v incompatibility deserves emphasis. A pattern that uses \p{Letter} needs one of them, but combining both on a single literal throws a syntax error. The cheat sheet states that incompatibility explicitly rather than implying that flags can always be stacked. The m flag is another common source of confusion: people expect ^ and $ to behave the same as in PCRE or in editor search dialogs, only to find that without m the anchors bind to the start and end of the entire string. Whenever code will run in a particular browser, an embedded runtime, or an older Node.js version, that environment's feature support is the last word; the cheat sheet is cross-checked against MDN's JavaScript cheat sheet and the MDN RegExp reference, but engine-version caveats still apply, especially around v flag support and around older lookbehind fallbacks.
When a Reference Isn't Enough — Test the Pattern
A syntax reference confirms that a token is valid JavaScript. It does not confirm that a pattern returns the right matches, captures the right groups, or avoids catastrophic backtracking on untrusted input. Real patterns should always be run against representative inputs before they ship, and a live Regex Tester shows every match, capture group, and named group highlighted as the pattern is typed, which is much faster than building a console snippet for each adjustment. The cheat sheet is intentionally a quick syntax reference rather than a regex validator, security analyzer, compatibility database, or efficiency guarantee, so treating it as a starting point and verifying behavior with a tester keeps the loop short without skipping the test step. For patterns that will run against untrusted text, also avoid uncontrolled backtracking by simplifying greedy quantifiers where possible and leaning on lazy forms or negated character classes to keep the engine bounded.
For a deeper look, see How to Check a Regex Pattern in JavaScript.