In JavaScript regular expressions, what do the m and s flags each change, and which one makes . match a newline?

## The default behaviour of the dot In a JavaScript regular expression, `.` is defined as "any character that is not a line terminator". The line terminators are exactly four code points: line feed `\n` (U+000A), carriage return `\r` (U+000D), line separator `
` (U+2028), and paragraph separator `
` (U+2029). Everything else — letters, digits, punctuation, tabs, ordinary spaces, emoji — is matched by `.`. That default exists because regular expressions historically operated line by line. In JavaScript, where you almost always hold the whole text in one string, the exclusion is more often a surprise than a help: ```js /a.b/.test("a\nb"); // false /a.b/.test("a b"); // true (space is not a line terminator) /a.b/.test("a\tb"); // true (tab is not either) ``` ## The s flag: dotAll Adding `s` removes the exception outright, so `.` matches every character including the four terminators. It was introduced in ES2018 and is reflected by the read-only boolean property `dotAll`: ```js const re = /a.b/s; re.dotAll; // true re.flags; // "s" re.test("a\nb"); // true ``` The name is the point: dotAll, dot matches all. It affects nothing else in the pattern — character classes, quantifiers, escapes and anchors behave exactly as before. Before ES2018, the idiomatic workaround was a character class whose two halves cover the whole character set, most commonly `[\s\S]` (whitespace or non-whitespace) or `[^]` (negated empty class, a JavaScript-specific spelling). Both still work today and both are flag-free, which makes them useful when you want *one part* of the pattern to cross lines while `.` elsewhere stays line-bounded: ```js /<pre>[\s\S]*?<\/pre>/.test("<pre>x\ny</pre>"); // true, no flag needed ``` ## The m flag: multiline The `m` flag is about a different mechanism entirely: where the `^` and `$` assertions are permitted to match. Without it, `^` matches only at position 0 of the input and `$` only at the very end. With `m`, they also match immediately after and immediately before any line terminator, so a pattern applies per line: ```js const text = "alpha\nbeta\ngamma"; text.match(/^\w+$/g); // null - no single line spans the whole string text.match(/^\w+$/gm); // ["alpha", "beta", "gamma"] ``` The corresponding property is `re.multiline`. Note what `m` does *not* do: it does not make `.` match newlines, and it does not split the input — the engine still sees one continuous string, it merely gains extra positions where the two anchors succeed. ## Why the confusion is so common The word "multiline" reads like "work across multiple lines", which is what people actually want when a pattern fails on multi-line input. The name describes the anchor behaviour, not the dot. Several other languages call the dot-matching flag DOTALL or `(?s)`, and JavaScript's single-letter `s` follows that tradition. The reliable mental model is: - `s` widens **`.`** - `m` widens **`^` and `$`** They compose freely. `/^.+$/gms` matches the entire string as one greedy run because `.` now crosses lines; `/^.+$/gm` matches each line separately. That pair is worth being able to predict out loud, because it demonstrates you understand both flags rather than having memorised one sentence. ## Practical notes Every flag is queryable: `re.flags` returns the flag string in a fixed canonical order, and `re.source` returns the pattern text without delimiters. Flags cannot be changed on an existing regex — the properties are read-only accessors — so to add one you build a new regex from the old one's source or pass the regex itself to `new RegExp(re, "ms")`. A note on `\r\n` input: with `m`, `$` matches before the `\r` and `^` after the `\n`, so a pattern such as `/^\w+$/gm` over Windows-style text leaves a stray `\r` outside the match rather than failing — a classic source of trailing-carriage-return bugs when the results are compared against clean strings. Normalising line endings before matching is usually cheaper than encoding them in the pattern.