Regex Match Beginning of Line: Anchors and Multiline Mode

Default behaviour

Without flags, ^ matches only at the very start of the input and $ only at the very end. On multi-line input, ^Error will not match a line in the middle.

Anchors are zero-width: they assert a position and consume nothing, which is why ^^ is legal and pointless, and why ^ can appear inside alternations.

The multiline flag

With m (re.MULTILINE, RegexOptions.Multiline, Pattern.MULTILINE), ^ and $ match at every line boundary:

/^Error/    on "ok\nError: x"    -> no match
/^Error/m   on "ok\nError: x"    -> matches line 2

This is what you want for log scanning and what you must avoid in validation — a multiline validator accepts input where only one line matches, which is a real bypass. ^\d{4}$ with m accepts "abc\n1234".

The trailing newline

In JavaScript, Python, Java and PCRE, $ also matches immediately before a final newline. So /^\d+$/ accepts "123\n" — surprising when validating input from a textarea or a file read.

Use \z where available (Python, Java, .NET, PCRE) to mean the absolute end, or \Z for "end, allowing one trailing newline". JavaScript has neither: trim the input, or match /^\d+$(?![\s\S])/.

Similarly \A means the absolute start regardless of the multiline flag — safer than ^ in a validator that might later gain the flag.

Word boundaries are different

\b matches between a word character and a non-word character, so \bcat\b finds "cat" in "the cat sat" but not in "concatenate". It is a position, not a character.

Because \b is defined in terms of \w, it treats the underscore as a word character and every accented letter as a non-word character in ASCII mode — so \bcafé\b behaves unexpectedly without Unicode support enabled.