{"id":10416,"date":"2026-09-16T07:20:00","date_gmt":"2026-09-16T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10416"},"modified":"2026-09-09T17:08:21","modified_gmt":"2026-09-09T15:08:21","slug":"regular-expressions-the-greedy-dot-missing-anchors-and-nested-repetition","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/web-development\/regular-expressions-the-greedy-dot-missing-anchors-and-nested-repetition\/","title":{"rendered":"Regular Expressions: The Greedy Dot, Missing Anchors and Nested Repetition"},"content":{"rendered":"

A regular expression is tested against the case it was written for, it matches, and it goes into production. What it does with the second case is a separate question, and the answer is often that it matches that one too – just not the part anyone intended.<\/p>\n

The three mistakes below are the ones that survive review, because none of them fails. They return something, the something looks plausible in a spot check, and the difference shows up as data that is subtly wrong rather than as an error.<\/p>\n

\n\"The
Four patterns, one line. The highlighted part is the match; the darker part inside it is the captured group.<\/figcaption><\/figure>\n

The Dot Is Greedy and the Dot Is Not a Character<\/h2>\n

.*<\/code> takes everything it can and only gives back what it must. In a line with two links, href=\"(.*)\"<\/code> starts at the first href<\/code>, runs to the end of the line, then backs up to the last quote it can find – and returns one match containing both links and the markup between them.<\/p>\n

Two things fix it. The lazy quantifier .*?<\/code> stops at the first quote that lets the rest of the pattern succeed. The negated class [^\"]*<\/code> cannot cross a quote at all, which says the same thing without any backtracking – and is the version worth writing, because it states the constraint instead of relying on how the engine unwinds.<\/p>\n

A Negated Class Includes the Line Break<\/h2>\n

The dot does not match a newline unless the s<\/code> flag is set. A negated character class does – [^&]<\/code> means anything that is not an ampersand, and a line break is not an ampersand.<\/p>\n

text     utm_source=newsletter\n         utm_medium=email\n\n^utm_([a-z_]+)=([^&]+)$      with the m flag: 2 matches\n^utm_([a-z_]+)=([^&]+)       without it: 1 match spanning both lines\n^utm_([a-z_]+)=([^&\\s]+)     the fix: whitespace excluded as well<\/code><\/pre>\n
This is the failure that looks like a data problem. A pattern extracting parameters from a multi-line input returns one value that happens to contain everything after it, the value is written to a field, and the field looks like a very long campaign name rather than like a bug.<\/p>\n
Anchors Say Where, Not Whether<\/h2>\n
Without anchors a pattern matches anywhere in the input, which is usually what is wanted for extraction and almost never what is wanted for validation. A check that a field contains only digits with [0-9]+<\/code> passes for abc123def<\/code>, because the pattern was never asked about the rest.<\/p>\n
Validation needs ^<\/code> and $<\/code> on both ends, and it needs to know what those mean in the flavour being used: without the multiline flag they mark the start and end of the whole input, with it every line. Which of the two is correct depends entirely on whether the input is one value or a list of them, and that is a question worth answering explicitly rather than by whichever default the library came with.<\/p>\n
Nested Repetition Is a Different Class of Problem<\/h2>\n
The three mistakes above return the wrong answer. This one returns no answer at all. When a repeated group contains something that is itself repeatable – (a+)+<\/code>, (\\s*\\w+)*<\/code>, (.*,)*<\/code> – the engine has exponentially many ways to divide the input among the repetitions, and it tries all of them before concluding that there is no match.<\/p>\n\n\n\n\n\n\n\n\n
Pattern<\/th>\nAgainst a non-matching input of length n<\/th>\n<\/tr>\n<\/thead>\n
(a+)+$<\/code><\/td>\nexponential – thirty characters is already seconds<\/td>\n<\/tr>\n
(\\s*\\w+)*$<\/code><\/td>\nthe same shape, hidden behind two harmless-looking classes<\/td>\n<\/tr>\n
^(\\w+\\s?)+$<\/code><\/td>\na common name-validation pattern, and a denial of service<\/td>\n<\/tr>\n
a+$<\/code><\/td>\nlinear – the outer repetition was the whole problem<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The dangerous property is that these patterns are fast on every input that matches. The blow-up only happens on inputs that fail, which means a validation pattern behaves perfectly for years and then meets one malformed submission and occupies a worker until it is killed.<\/p>\n
The rule that avoids it is mechanical: no quantifier directly around a group whose contents are themselves quantified. Where that is unavoidable, a negated class usually expresses the same intent – [^,]+,<\/code> instead of (.*,)<\/code> – and removes the ambiguity that the backtracking was exploring.<\/p>\n
What to Test Before Trusting a Pattern<\/h2>\n
Three inputs answer most of it. The case it was written for, to confirm it matches. A case with two occurrences, which is where greediness shows itself and a single-example test never will. And a case that must not match, which is where anchors and nested repetition both reveal themselves – one by matching anyway, the other by not finishing.<\/p>\n
The third is the one that gets skipped, and it is the one that catches both of the problems that cannot be seen by reading the pattern. A test suite for a regular expression is three lines long, and it is the difference between an expression that works and an expression that has not yet been contradicted.<\/p>\n
\n
Sources<\/h2>\n