Google Sheets quietly deletes the umlaut from Müller

Here is a formula that appears in a lot of spreadsheets. It removes punctuation from a name:

=REGEXREPLACE("Müller", "[^\w]", "")

Delete everything that is not a word character. Run it in a real Google Sheet, which we did, and the cell returns:

Mller

No error. No warning. The umlaut is gone, and so is the person’s name.

What we ran

Twenty-four formulas, in a live Google Sheet, against names and places that exist: Müller, José Álvarez, Zürich, İstanbul, 김재성, naïve, Straße. The kind of data that shows up the first time a customer list crosses a border.

Google’s documentation says the spreadsheet runs RE2, “except Unicode character class matching.” One clause, no examples. We went to find out what it costs.

The answer is stranger and more specific than “Sheets is bad at Unicode.”

The engine understands characters perfectly well

Three measurements, all TRUE, all surprising if you expected a broken engine:

=REGEXMATCH("é", "^.$")                →  TRUE
=REGEXEXTRACT("Straße", "^.{3}")       →  Str
=REGEXMATCH("MÜLLER", "(?i)müller")    →  TRUE

A dot matches é — one character, not the two bytes it occupies. ^.{3} on Straße returns Str, counting characters, not bytes. And case-insensitive matching folds Ü to ü correctly, which is a genuinely Unicode-aware operation.

This engine reads text. It knows what a character is.

And then it will not admit that ü is a letter

=REGEXMATCH("Müller", "^\w+$")     →  FALSE
=REGEXMATCH("김재성", "^\w+$")      →  FALSE
=REGEXMATCH("naïve", "^[a-z]+$")   →  FALSE
=REGEXMATCH("café au lait", "\bcafé\b")  →  FALSE

\w means word character, and in Google Sheets it means [A-Za-z0-9_] and nothing else. Not ü. Not é. Not a single Korean syllable. \b, the word boundary, is built out of the same definition, so it finds a boundary in the middle of café.

The same holds for digits. These are both FALSE:

=REGEXMATCH("１２３", "^\d+$")   →  FALSE     (full-width, from a Japanese or Korean keyboard)
=REGEXMATCH("١٢٣", "^\d+$")    →  FALSE     (Arabic-Indic)

If a colleague pastes a column of full-width numbers out of an exported Excel file — which happens — every validation formula built on \d will say those cells contain no digits, and every one of them will say it politely.

The extraction that returns one letter

Put those two facts together and you get the failure that will actually reach a report.

=REGEXEXTRACT("Zürich, CH", "^([A-Za-z]+)")

This is a formula somebody wrote to pull the city out of a location column, and it works. On Boston. On Leeds. On Zurich, if the list came from a system that had already thrown the umlaut away.

On Zürich, CH it returns:

Z

Not #N/A. Not #REF!. The letter Z, in a city column, in a row that will be summed and filtered and sent on. ^(\w+) behaves identically, for the same reason. And on a name:

=REGEXEXTRACT("José Álvarez", "^\w+")   →   Jos

The pattern matched. There was a run of ASCII letters at the start of the string. The engine returned it, correctly, and stopped where the accent began.

The correct fix is the one thing that fails loudly

Every regex engine written this century has an answer for this. It is \p{L} — any character that Unicode calls a letter. It is what you are supposed to write.

=REGEXMATCH("Müller", "^\p{L}+$")   →   #REF!
=REGEXMATCH("김재성", "^\p{L}+$")    →   #REF!

This is what Google’s sentence means. Unicode character classes are the thing that is missing, and \p{L} is the construct that names them.

So the position is this. The correct tool throws an error. The incorrect tool returns a wrong answer in silence. A person who reaches for \p{L}, sees #REF!, and retreats to \w has been led, step by step, from a formula that would have worked to one that quietly mangles names.

#REF!, incidentally, is the same error Sheets gives you for a deleted cell reference, which is not a hint that your pattern is unsupported. We measured that separately, in the RE2 limits run.

Why the tester you used did not warn you

Almost every regex tester on the web runs the browser’s own engine, which is JavaScript. And in JavaScript, \w is also [A-Za-z0-9_]. So when you tried ^\w+$ against Müller in a tester, it said false — and it was right, and you probably concluded you had made a typo rather than that the shorthand does not mean what its name says.

Then you looked up the fix, found \p{L}, and tried it. JavaScript supports \p{L} when the pattern carries the u flag, which testers set for you. It matched. Green tick.

You pasted it into Google Sheets and got #REF!.

The tester was not lying about JavaScript. It was answering a question about a different program. That gap — between the engine in your browser and the engine inside your spreadsheet — is the whole reason this site exists, and it is widest exactly here, at the one construct that would have solved your problem.

What does work

One thing we tested does work, and we did not expect it to:

=REGEXMATCH("naïve", "^[a-zà-ÿ]+$")   →   TRUE

An explicit range across the Latin-1 block. The engine reads à-ÿ as a range of characters, not bytes, and ï falls inside it. This is the workaround, and it is ugly, and it is what you have.

It does not cover Korean, Greek, Cyrillic, Polish ł, or Turkish ğ. For a European customer list it covers most of what you will meet.

Case folding has a limit too:

=REGEXMATCH("İSTANBUL", "(?i)istanbul")   →   FALSE

Turkish İ is a capital I with a dot, and it does not fold to a plain i. The engine is doing simple case folding, which is correct behaviour by the letter of the standard and wrong by the expectation of anyone who has a Turkish office.

What to do on Monday

Never use \w on a column of names. Not on customers, not on cities, not on product titles typed by a human. \w is a promise about ASCII wearing the word “word”.

Put one accented row in your test data. Add Müller to the sheet where you are building the formula. If the formula still works, it works. This costs one row and catches every failure on this page.

Never write [^\w] or [^A-Za-z] in a REGEXREPLACE that touches names. Those two patterns do not clean data. They delete letters, from real names, permanently, on save.

If you see #REF!, do not assume you made a typo. It may be the only honest thing Sheets has said to you all afternoon.

You can paste any of these into our tester, which now flags \w, \d, and \b as ASCII-only when it sees them, alongside the constructs Sheets cannot parse at all. The two lists are different, and the quiet one is longer.

Every formula quoted here was executed in a live Google Sheet before this was published, and the values above are the values the cells returned. The full run, with timestamps and the environment, is on the evidence page.