Welcome to the final lesson of Regex Foundations: Matching Patterns in JavaScript! You've come remarkably far in your regex journey. In the first three lessons, you mastered literal matching and special characters, learned to control repetition with quantifiers, and gained precision through character classes and shorthands. These tools have given you the power to match almost any pattern within text.

However, there's one critical dimension we haven't yet explored: position. So far, your patterns have searched for matches anywhere within the text. But what if you need to verify that a string starts with a specific pattern? Or ensure it ends with a particular extension? Or count only whole-word occurrences without matching partial substrings? These positional requirements are essential for validation, parsing, and precise text extraction.

In this lesson, you'll learn to control where matches occur using anchors and word boundaries. The start-of-string anchor ^ and end-of-string anchor $ let you enforce that patterns appear at specific locations. Word boundaries \b help you distinguish between whole words and partial matches within larger strings. You'll also explore grouping with parentheses and alternation with the pipe operator, which allow you to structure complex patterns and match multiple alternatives. By the end, you'll be able to validate formats precisely, extract structured data reliably, and build sophisticated patterns that combine all the regex fundamentals you've learned throughout this course.

Until now, your regex patterns have searched through text looking for matches anywhere they might occur. When you search for \d+ in "Room 42, Floor 3", the pattern finds both "42" and "3" regardless of their positions. This behavior is often exactly what you want: flexible searching that locates patterns wherever they exist.

But many real-world tasks require positional awareness. Consider validating a JavaScript function definition: you need to ensure the text begins with function followed by a function name. If someone writes "This function is wrong," you shouldn't accept it even though it contains your keyword. Similarly, when validating file extensions, "script.js" should match, but "script.js.backup" should not, even though both contain ".js" somewhere in the string.

Positional constraints transform your patterns from flexible searchers into precise validators. Instead of asking, "Does this pattern exist somewhere in the text?" you can ask, "Does the text start with this pattern?" or "Does it end with this pattern?" or "Is this a complete word, not part of a larger string?" These distinctions are fundamental for tasks like input validation, format verification, and structured data extraction.

The caret symbol ^ serves as the start-of-string anchor. When placed at the beginning of a pattern, it asserts that the match must occur at the very start of the text. The pattern ^abc will only match if "abc" appears as the first characters; it won't match "xyz abc" even though "abc" exists in the string.

Let's examine this pattern carefully. The ^ anchor ensures your match begins at the start of the string. Following the anchor, you have (?:function|class), which uses grouping and alternation (you'll explore these concepts more deeply shortly). The key point here is that without the ^, this pattern would match "This function is wrong" because it contains "function " somewhere. With the anchor, you enforce that "function " or "class " must be the very first characters.

Just as ^ anchors to the beginning, the dollar sign $ anchors to the end of the string. A pattern like abc$ matches only if "abc" appears as the final characters. This proves essential for validating endings, such as file extensions or status codes in log files.

The pattern /\.(?:js|mjs|cjs|ts|jsx|tsx|json)$/ combines several elements. You start with \. to match a literal dot (escaped because the dot has special meaning). Then (?:js|mjs|cjs|ts|jsx|tsx|json) matches one of seven extensions common in the JavaScript ecosystem. Finally, the $ anchor ensures this extension appears at the very end. Without $, "script.js.backup" would match because it contains ".js" somewhere, but with the anchor, you correctly reject it since ".js" isn't the final part.

The results confirm your pattern works correctly. The "script.js" and "app.tsx" files return true because they ends (thanks to the $ anchor) with an extension in your alternation group. Both "README.md" and "data.csv" return false because neither "md" nor "csv" are among the JavaScript ecosystem extensions you specified, demonstrating how the end-of-string anchor and alternation work together for precise validation.

When you use both ^ and $ together, you create an exact match requirement: the entire string must match your pattern with nothing before or after. This is crucial for strict validation, where you need to accept precisely formatted input and reject anything with extra content.

These examples demonstrate anchor behavior. The first two return true because they start with your required keywords. The third returns false despite containing "function ": the leading spaces mean the string doesn't start with your keyword, so the ^ anchor prevents a match.

The output confirms your expectations. Both valid function and class definitions match successfully. However, the indented definition fails validation because the ^ anchor requires the keyword to be at position zero, and the spaces violate this requirement.

Beyond start and end positions, you often need to distinguish complete words from partial matches. The sequence \b represents a word boundary: a position between a word character (letters, digits, underscore) and a non-word character (spaces, punctuation, string boundaries). Unlike anchors that match positions relative to the entire string, word boundaries match positions around individual words.

Consider searching for "cat" in the text "The cat scattered." Without boundaries, you'd match two occurrences: once in "cat" and once in "scattered" (the "cat" substring appears within "scattered"). But if you only want complete word matches, you need to ensure "cat" isn't part of a larger word. The pattern \bcat\b solves this by requiring word boundaries on both sides.

This function demonstrates practical word boundary usage. JavaScript doesn't have a built-in escape function like some other languages, so you use the custom escapeRegExp helper function to handle any special characters in the word parameter, then wrap it with \b on both sides. The result is a pattern that matches only when your word appears as a complete unit, not as part of a larger word. Note that when using new RegExp() with strings, you need to double-escape the backslash (\\b instead of \b) because the string itself processes escape sequences first.

Let's see word boundaries in action with a concrete example:

The text contains "cat" multiple times as a substring: once standalone at the beginning, once inside "concatenate," once inside "scatter," and once at the end followed by a period. However, you only want to count complete word matches.

The output is 2, which is exactly what you want. The \b boundaries correctly identified only the two standalone occurrences of "cat." The substring "cat" within "concatenate" didn't match because there's no word boundary between "n" and "c" (both are word characters). Similarly, "cat" within "scatter" didn't match. The final "cat." matched because the period creates a word boundary after the word.

Parentheses in regex serve multiple purposes, but their most fundamental role is creating groups: treating multiple characters as a single unit. This becomes essential when you want to apply quantifiers to sequences or when you need to specify alternatives. Without grouping, the alternation operator | has low precedence and can produce unexpected results.

Consider the difference between abc|def and a(?:bc|de)f. The first pattern matches either "abc" or "def" completely. The second matches "abcf" or "adef": the alternation applies only to "bc" versus "de," with "a" and "f" required in both cases. Groups clarify these boundaries and control operator scope.

When you need grouping for structural purposes without extracting the grouped content, you use non-capturing groups with the syntax (?:...). The ?: at the start tells the regex engine to treat the parentheses as grouping only, not as a capture group for data extraction. Combined with the alternation operator |, this lets you match one of several alternatives efficiently.

The pattern /\b(?:red|green|blue)\b/g combines several concepts. The \b boundaries ensure you match complete words only. Inside the non-capturing group (?:...), the alternation red|green|blue specifies three alternatives: the pattern matches any of these three color words. The group is non-capturing because you only care about finding these words, not extracting parts of the match separately. The g flag enables global matching to find all occurrences.

Your function found four color matches. It correctly identified "red" and "blue" (twice) and "red" again at the end. Notably, it did not match "greenish" even though it contains "green" as a substring. The word boundaries prevented this false match: there's no boundary between "green" and "ish" since both are word characters, so "green" isn't a complete word in "greenish."

Let's combine everything you've learned in a practical example: extracting URLs that use specific protocols. Many texts contain various URL formats, but you might only care about HTTP and HTTPS links, excluding others like FTP or custom schemes.

This pattern showcases several techniques working together. You start with \b to ensure you're at a word boundary (preventing matches of "pseudo-http://"). Then (?:http|https) matches either protocol. You follow with :\/\/ as literal characters (the forward slashes are escaped in the regex literal). Finally, \S+ matches one or more non-whitespace characters, capturing the domain and path. This pattern is concise yet effective.

The function successfully extracted both HTTP and HTTPS URLs while ignoring the FTP URL. The alternation in your non-capturing group handled both protocol variants, and the \S+ pattern captured everything up to the next whitespace, giving you complete URL strings. This demonstrates how grouping, alternation, and boundaries work together to build precise, practical patterns.

Congratulations on completing the final lesson of Regex Foundations: Matching Patterns in JavaScript! You've accomplished something truly remarkable. From learning basic literals and special characters, through mastering quantifiers and character classes, to now controlling position with anchors, boundaries, and structured grouping, you've built a comprehensive foundation in regular expressions.

In this lesson, you explored how anchors (^ and $) let you enforce where matches occur relative to string boundaries. You discovered how word boundaries (\b) distinguish complete words from partial substrings, enabling precise counting and extraction. You learned to structure complex patterns using grouping with parentheses, and you combined non-capturing groups (?:...) with alternation | to match multiple alternatives efficiently. You also learned about the differences between regex literals and string-based patterns in JavaScript, including the need to double-escape special sequences when using the RegExp constructor. These positional and structural tools complete your regex toolkit, enabling you to validate inputs, parse structured data, and extract information with surgical precision.

You now possess all the fundamental skills needed to write effective regular expressions for real-world tasks. The concepts you've covered form the bedrock of pattern matching across programming languages and tools. As you move forward, remember that regex mastery comes through practice: experimenting with patterns, testing edge cases, and gradually building more complex expressions from simple components.

Before you celebrate, there's one more crucial step: the practice section awaits to solidify your understanding. You'll work with social media handle validation, log file filtering, keyword counting, and API endpoint validation, applying anchors, boundaries, and grouping to solve real-world challenges. These exercises will cement your skills and build confidence in your pattern-matching abilities. Let's put everything you've learned into practice and watch your regex expertise shine in the exercises ahead!