Anchors, boundaries & lookaround

Positions, not characters

Regex lessons often begin with characters: letters, digits, classes, and repeats. This lesson switches the question. Instead of asking “which character can I eat next?”, anchors, boundaries, and lookaround ask “is the engine standing in the right place?”

We will stay in this lane: anchors, boundaries, lookahead, lookbehind, and inline modifiers. For the surrounding regex tools, revisit patterns and flags, character classes, quantifiers, and groups and backreferences.

^ and $ are the first anchors most JavaScript developers meet. Without the m flag, ^ is only the start of the whole input and $ is only the real end of the whole input. With m, they can also stand at line boundaries inside the same string.

1const text = "alpha\nbeta\n";Run2const pattern = /^beta$/m;3const match = pattern.exec(text);4 5console.log(match ? match.index : null);6console.log(match ? match[0] : "no match");

The final-newline detail is worth testing because different regex traditions disagree. In JavaScript, $ without m does not also match just before a final \n. The pattern must include the newline, or you must use multiline mode when line endings are the thing you want.

1console.log(/end$/.test("end\n"));2console.log(/end\n$/.test("end\n"));3console.log(/end$/m.test("end\n"));

Use unflagged anchors when validating a whole field. Use multiline anchors when scanning a log, textarea, or source file line by line. A bare search finds inside a value; an anchored search validates the whole value.

1const value = "say admin now";2console.log(/admin/.test(value));3console.log(/^admin$/.test(value));4console.log(/^admin$/.test("admin"));

\b is a boundary between a JavaScript regex “word character” and a non-word character. In practice, that word side is ASCII-style: letters A through Z, a through z, digits, and underscore. The opposite assertion, \B, matches positions that are not word boundaries.

1const text = "hi\ncafé cat\nend\n";2console.log([...text.matchAll(/^/gm)].map((m) => m.index));3console.log([...text.matchAll(/$/gm)].map((m) => m.index));4console.log([...text.matchAll(/\b/g)].map((m) => m.index));

That ASCII basis matters with real names and languages. The word café looks like one word to a person, but \b does not treat é as an ASCII word character, even with the u flag. For Unicode words, use lookaround with Unicode property escapes from the character classes lesson.

1console.log(/\bcafé\b/u.test("café"));2console.log(/(?<!\p{L})café(?!\p{L})/u.test("café"));3console.log(/\Bend/.test("weekend"));

1// Proposal syntax: not supported in Node 22 or Chrome 154 today.2const log = "status: ok\n";3console.log(/\Astatus: ok\Z/u.test(log)); // would allow one final line terminator4console.log(/\Astatus: ok\z/u.test(log)); // would require the absolute end

Today, use ^ and $ without m for most whole-input checks, or the absolute-position lookarounds below when you need an anchor that cannot be affected by flags around it.

1const exact = "status: ok";2const withFinalNewline = "status: ok\n";3 4console.log(/^status: ok$/.test(exact));5console.log(/(?<![\s\S])status: ok(?![\s\S])/.test(exact));6console.log(/(?<![\s\S])status: ok(?![\s\S])/.test(withFinalNewline));

Positive lookahead (?=...) says “the next text must match this.” Negative lookahead (?!...) says “the next text must not match this.” Either way, the engine stays at the same position after the assertion succeeds.

1const text = "ababa";2const starts = [...text.matchAll(/(?=aba)/g)].map((match) => match.index);3console.log(starts.join(","));4console.log(text.replace(/(?=aba)/g, "|"));5 6const captured = /(?=(aba))/.exec(text);7console.log(captured[0].length);8console.log(captured[1]);

The first line finds two start positions for aba in ababa: 0 and 2. The replacement inserts markers at those positions without deleting any letters. The final two logs show a subtle but useful rule: captures inside a positive lookahead still capture. The whole assertion match is empty, but group 1 holds aba.

1const strong = /^(?=.{8,}$)(?=.*[A-Z])(?=.*\d)(?!.*\s).+$/;Run2console.log(strong.test("desk-2"));3console.log(strong.test("Desk 2026"));4console.log(strong.test("Desk-2026"));

Lookahead is also useful for formatting. The thousands separator pattern places a comma at a non-boundary position only when complete groups of three digits are ahead and no extra digit follows that group.

1const value = "1234567890";2console.log(value.replace(/\B(?=(\d{3})+(?!\d))/g, ","));

Positive lookbehind (?<=...) says “the previous text must match this.” Negative lookbehind (?<!...) says “the previous text must not match this.” Current Chrome, Firefox, Edge, and Safari support lookbehind; Safari support begins at 16.4, so old Safari is the main browser caveat.

1const receipt = "Tea $3.50, mug $12, tax 0.90";2const prices = [...receipt.matchAll(/(?<=\$)\d+(?:\.\d{2})?/g)].map((match) => match[0]);3console.log(prices.join(", "));

The dollar sign is checked but not consumed. That makes lookbehind a clean fit for extraction: keep context out of the returned match without using a separate capturing group after the match.

1const strong = /^(?=.{8,}$)(?=.*[A-Z])(?=.*\d)(?!.*\s).+$/;2console.log(strong.test("desk-2"));3console.log(strong.test("Desk 2026"));4console.log(strong.test("Desk-2026"));

Inline modifiers use syntax such as (?i:...), (?-i:...), and (?m:...) to turn flags on or off for one group. They are ES2025 syntax. The current compatibility picture is uneven: current Chrome and Firefox support them, Safari does not yet according to MDN compatibility data, and Node 22 throws “Invalid group.”

1// ES2025 inline modifiers. Chrome 154 and current Firefox parse this; Node 22 and Safari do not.2const route = /^(?i:api)-(?-i:v1)$/i;3console.log(route.test("API-v1"));4console.log(route.test("API-V1"));

The fallback below shows why this feature is useful. A plain global i flag can make an entire pattern case-insensitive, but it cannot make only api loose while keeping v1 exact.

1const route = /^api-v1$/i;2console.log(route.test("API-v1"));3console.log(route.test("API-V1")); // cannot keep only v1 case-sensitive

These assertions are not trivia. They separate “find this somewhere” from “this whole value is valid,” keep prefixes out of extracted text, and make replacement patterns land at positions rather than over characters.

Common misconceptions

• “$ always matches before a final newline.” Not in JavaScript without m. Test it before copying advice from another regex flavor.
• “^...$ is always validation.” It validates the whole input only when m is off and your pattern handles every allowed character.
• “\b means human word.” It is based on ASCII-style word characters, so names like café need a Unicode-aware alternative.
• “Lookaround eats the text it checks.” It does not. Consuming tokens after the assertion decide what appears in the match.
• “Unsupported regex syntax is harmless if it is never reached.” Syntax in a regex literal is parsed before code runs. Store new syntax as a string and feature-detect when a runtime may not parse it.

Key takeaways

• Anchors, boundaries, and lookaround are zero-width assertions: they check positions.
• JavaScript $ without m matches the real end, not the spot before a final newline.
• \b is ASCII-oriented; use Unicode property lookaround for international words.
• Lookahead and lookbehind do not consume, but captures inside successful positive lookaround can still capture.
• Inline modifiers are useful ES2025 syntax, but feature-detect because Node 22 and Safari do not parse them yet.

Up next: Regex performance & safety, where backtracking, ReDoS, and the sticky y flag explain why some patterns are safer than others.