Free · Fast · Privacy-first

Regex Cheatsheet, The Complete Pattern Reference

Stop searching scattered documentation every time you forget a quantifier or flag.

⚡

Full coverage of anchors, classes, quantifiers, and groups

🔒

Lookahead and lookbehind syntax with examples

✨

All standard flags explained with real-world use cases

⚡

Copy any pattern directly into the live tester

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Regex Tester to your website

Drop the Regex Tester into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/developer/regex-tester?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Regex Tester by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/developer/regex-tester?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Regex Tester by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Why a Regex Cheatsheet Belongs in Every Developer Workflow

Regular expression syntax has remained largely stable for decades, but its density means that even experienced developers frequently forget the exact token for a behaviour they have not used recently. Is it (?<=...) or (?=...) for a lookbehind? Does {3,} mean three or more, or exactly three? A cheatsheet eliminates those questions without requiring a full documentation read. It is the difference between a five-second lookup and a two-minute context switch to a documentation site that requires further navigation to the right section. For teams onboarding developers who are new to regex, a concise cheatsheet also serves as a structured introduction: it maps the abstract concept to the concrete syntax and a minimal example in a single line, which is faster to absorb than reading a tutorial that starts from theory.

The core taxonomy of regex tokens breaks into six groups. Anchors (^, $, \b, \B) match positions rather than characters, asserting where in the string a match must occur without consuming any input. Character classes ([a-z], \d, \w, \s and their uppercase negations) describe sets of characters that can occupy a position. Quantifiers (*, +, ?, {n}, {n,m}) specify how many times the preceding token must occur. Groups ((...) and (?:...)) scope quantifiers and optionally capture substrings. Lookarounds ((?=...), (?!...), (?<=...), (?<!...)) assert surrounding context without consuming characters. Flags (g, i, m, s, u, y) modify how the engine traverses the input at a global level. Understanding which group a token belongs to resolves most syntax confusion instantly and provides the right mental model for combining tokens correctly.

For practical sessions, the most productive approach is to keep the cheatsheet open in an adjacent browser tab during any regex-heavy work. Write the pattern in the tester, look up any uncertain token in the cheatsheet, paste the cheatsheet example into the tester to confirm your understanding, then return to building your pattern. This three-tab workflow covering cheatsheet, tester, and your codebase handles the full cycle from syntax lookup to verified pattern without requiring you to leave the browser or break the development flow for a longer documentation excursion.

Cross-flavour awareness matters because regex syntax varies more across engines than newcomers expect. The shorthand classes \d, \w, and \s mean ASCII-only digits, word characters, and whitespace in JavaScript even with the u flag, but mean Unicode-aware sets in .NET and in Python under re.UNICODE which is the default in Python 3. Named-group syntax is (?<name>...) in JavaScript, .NET, and PCRE, but (?P<name>...) in Python's re module. Possessive quantifiers like a++ and atomic groups (?>...) work in Java and PCRE but throw syntax errors in JavaScript. The cheatsheet flags these differences inline so you do not waste time chasing a pattern that looks correct but was copied from a tutorial written for a different engine. When in doubt, write a tiny test case in the target language's real environment before trusting a pattern.

MDN Regular Expressions reference ECMA-262 RegExp specification

How to use this tool

💡

Open the Regex Tester alongside this cheatsheet. Copy any pattern from the reference, paste it into the tester, and test it against your real data immediately.

How It Works

Step-by-step guide to regex cheatsheet, the complete pattern reference:

1
Identify the token category
Decide whether the behaviour you need falls under anchors (position matching), character classes (set membership), quantifiers (repetition counts), groups (scoping and capturing), lookarounds (context assertions), or flags (engine-level settings). This categorisation tells you which section of the cheatsheet to consult first and prevents you from searching the wrong area.
2
Find the token in the cheatsheet
Locate the relevant section of the cheatsheet and identify the specific token or syntax form you need. Read the brief explanation alongside the token to confirm it describes the behaviour you want. Copy the example pattern if one is provided: using the example as a starting point is faster than writing the syntax from memory.
3
Open the Regex Tester
Paste the copied example pattern into the pattern field of the live tester. This immediately confirms that the syntax is valid and shows you what the example matches. Adapt the example to your specific use case by modifying the character classes, quantifiers, or anchors in the pattern field.
4
Paste your test data
Enter representative strings from your project into the test string area to verify that the pattern based on the cheatsheet example behaves as the documentation describes. If it does not, return to the cheatsheet to check whether a flag or additional syntax modification is required for your specific context.

Real-world examples

Common situations where this approach makes a real difference:

Confirming the syntax for a word boundary anchor

A developer wants to match the word "cat" only as a standalone word, not as a substring inside "concatenate" or "scatter". Looking up \b in the cheatsheet confirms it matches a zero-width word boundary between a word character and a non-word character. The pattern \bcat\b is pasted into the tester against "I have a cat and a concatenation problem". Only the standalone "cat" is highlighted, with no match inside "concatenation", confirming the anchor behaves as documented and the pattern is ready for the search feature.

Looking up how to match one or more digits non-greedily

A developer processing HTML attribute values needs to match the shortest sequence of digits between quotation marks, not the longest span across multiple attributes. The cheatsheet shows that \d+? is the lazy variant of \d+. Testing the string height="100" width="200" with the pattern "\d+?" in the tester confirms each digit group is captured individually as 100 and 200 rather than the engine greedily spanning from 100 to 200 as a single long match.

Checking lookahead syntax for a password strength rule

A security engineer needs a pattern that only matches if a string contains at least one uppercase letter and at least one digit, without consuming characters or prescribing their positions. The cheatsheet shows (?=.*[A-Z]) and (?=.*\d) as positive lookahead forms. Combining them into ^(?=.*[A-Z])(?=.*\d).{8,}$ and testing against sample passwords of varying strength in the tester confirms that the rule correctly enforces both requirements simultaneously without restricting where in the string the uppercase letter or digit appears.

Teaching a junior developer the difference between * and +

A tech lead uses the cheatsheet during a code review to explain why \d* matched an empty string at a position where \d+ was clearly the intended choice. The cheatsheet entry shows that * means zero or more occurrences while + means one or more and requires at least one match. Testing both patterns against an empty string in the tester makes the difference immediately visual: \d* highlights the empty position while \d+ produces no match. The demonstration takes under 30 seconds and cements the concept far more effectively than a verbal explanation.

When to use this guide

Use this page when you need a quick lookup for regex syntax, want to confirm the exact token for a behaviour, or are introducing a colleague to regular expressions for the first time.

Pro tips

Get better results with these expert suggestions:

Group cheatsheet tokens by what they match versus what they assert

Tokens that consume characters (character classes, literals, quantified groups) behave fundamentally differently from tokens that assert position (anchors, lookarounds). Keeping this distinction in mind when reading a cheatsheet prevents a common mistake: attempting to quantify an anchor such as writing ^+ or \b?, which has no meaningful effect because anchors match zero-width positions and do not consume input that a quantifier could count.

Learn the six flags before the advanced token types

The g, i, m, s, u, and y flags change how the entire engine processes input, not just individual tokens. Misunderstanding flag behaviour accounts for a disproportionately large share of "my pattern works in the tester but not in my code" issues. Mastering what each flag does and when each is appropriate resolves an entire category of subtle bugs before they are written, making flag knowledge one of the highest-return topics in the cheatsheet.

Use the cheatsheet to review unfamiliar patterns from colleagues

When reviewing code containing a regex pattern you do not immediately recognise, cross-reference each unfamiliar token against the cheatsheet before asking a question. This practice builds pattern-reading fluency over time, usually resolves the uncertainty in under a minute, and avoids interrupting the original author for explanations that the cheatsheet can provide faster.

Bookmark the cheatsheet alongside the live tester

Keep both the cheatsheet page and the regex tester open in adjacent browser tabs during any session where you are writing or reviewing patterns. The lookup-and-verify cycle takes under 30 seconds per uncertain token and is far faster than navigating a search engine, reading a tutorial page, and returning to your work. The proximity of the two tools in adjacent tabs is what makes the habit practical.

FAQ

Frequently asked questions

\d matches any decimal digit character from 0 through 9, equivalent to [0-9]. \w matches any word character, which in ASCII mode is equivalent to [a-zA-Z0-9_] including the underscore. \s matches any whitespace character, including the space character, horizontal tab (\t), newline (\n), carriage return (\r), and form feed (\f). The uppercase counterparts negate each class: \D matches any character that is not a digit, \W matches any non-word character, and \S matches any non-whitespace character. In JavaScript with the u flag, \w still covers only ASCII word characters rather than expanding to Unicode letters.

The * quantifier matches zero or more consecutive occurrences of the preceding token, so the pattern succeeds even if the token appears zero times at the current position. The + quantifier matches one or more consecutive occurrences and requires at least one occurrence to produce a match. Using * where + is intended is a common source of subtle bugs: a pattern with * can match at a position where the token is entirely absent, producing unexpected empty-string matches in validation logic or match-list results that contain spurious entries at positions between actual occurrences.

Escape the special character with a backslash to match it literally. In regex syntax, . matches any character except a newline by default, but \. matches only a literal dot character. Similarly, \* matches a literal asterisk, \+ a literal plus sign, \? a literal question mark, and $ and $ match literal parentheses. Inside a character class enclosed in square brackets, most special characters lose their special meaning and do not require escaping, with the exceptions of the backslash itself, the closing bracket ], and the caret ^ when it appears as the first character.

A non-capturing group (?:...) applies grouping to a set of tokens for the purpose of scoping a quantifier or structuring an alternation, without recording the matched text as a numbered capture. Use it when you need parentheses for structural reasons but do not need the matched value in your results. This prevents capture group indices from incrementing unnecessarily, avoids undefined entries in match arrays when optional capturing groups do not participate in a match, and makes the intent of the pattern clearer to readers who see (?:...) and know immediately that no capture is intended.

The u (unicode) flag enables full Unicode mode in JavaScript regex. It is required to use Unicode property escapes such as \p{Letter}, \p{Script=Greek}, or \p{Decimal_Number}. It also changes how the engine counts characters: without the u flag, characters outside the basic multilingual plane such as emoji and some rare ideographs are counted as two code units (a surrogate pair), which can cause character class membership tests and quantifier counts to behave unexpectedly on those characters. Enable u whenever your pattern must work correctly with non-ASCII text, emoji, or characters from any script outside Latin and common European alphabets.

The y (sticky) flag forces the regex engine to attempt a match only at the exact index stored in the regex object's lastIndex property, rather than searching forward through the string for any position where the pattern can match. This is primarily useful in parser or tokeniser loops that process input left to right, where each match must begin exactly where the previous one ended. Without the y flag and with the g flag instead, the engine searches forward from lastIndex until it finds a match position, which allows gaps between matches. With y, a gap causes the match to fail.

Character classes match a single character position from a defined set and consume that character as part of the match. Lookaheads are zero-width assertions that check what follows the current position without consuming any characters. A positive lookahead (?=...) asserts that the specified pattern exists immediately ahead, and a negative lookahead (?!...) asserts that it does not. This allows you to express conditions on the context following a match without including that context in the matched text, which is useful for password rules, context-sensitive token boundaries, and patterns where the match depends on what comes after it.

Without word boundary anchors, a pattern like cat matches the substring "cat" anywhere it appears, including inside "concatenate", "scatter", or "category". Add \b anchors to restrict matching to whole words: \bcat\b matches "cat" only when it is preceded and followed by non-word characters or by string boundaries. For full-string validation where the input should consist entirely of the pattern, use ^ and $ anchors instead of \b anchors, since \b does not prevent partial matches within a string that has additional content before or after the matched word.

Regex describes regular languages, which by definition cannot count arbitrary nesting. The moment your input has matched delimiters that nest (HTML elements, JSON objects, balanced parentheses in code, nested function calls) you have left the regular language behind and any regex solution will be brittle. The right tool is a parser: DOMParser for HTML, JSON.parse for JSON, a YAML library for YAML, and a real tokeniser plus AST library like Babel or Acorn for JavaScript source. Regex still has a role inside parsers as the lexer that splits raw text into tokens, but the structural assembly belongs to a grammar. If you find yourself reaching for backreferences to fake balance, stop and switch tools before the pattern accumulates technical debt.

Both g and y advance lastIndex across calls on the same RegExp object, but their search behaviour differs in one critical way. The g flag scans forward from lastIndex until it finds a match anywhere ahead in the string, allowing gaps between consecutive matches. The y flag requires a match to begin exactly at lastIndex; if the engine cannot match at that position, the call fails immediately even if the pattern would match a character or two later. Use g when you want to extract all occurrences of a pattern from a document with arbitrary text between them. Use y when writing a hand-rolled lexer that must consume the input contiguously, token by token, with no gaps tolerated between consecutive matches.