What Vietnamese diacritics actually mark
Vietnamese uses two separate layers of marks on top of the Latin alphabet: vowel modifiers that create entirely different letters (ă, â, ê, ô, ơ, ư, and đ), and tone marks (dấu) that indicate one of six tones — sắc, huyền, hỏi, ngã, nặng, and the unmarked flat tone — which change a word's meaning as fundamentally as a different vowel would in English. "Ma", "má", "mà", "mả", "mã", and "mạ" are six different words, distinguished entirely by tone mark. That's exactly why simply deleting diacritics changes what a word means, even though it's sometimes the practical, necessary choice.
Strip diacritics now
The systems that still can't handle them
Modern browsers, phones, and apps handle Vietnamese Unicode without issue, but a real, still-common set of systems don't: older government, banking, and enterprise databases built before Unicode was standard practice, legacy point-of-sale and inventory systems, some SMS gateways with strict character-set limits, and any system that auto-generates a username, employee ID, or email alias from a person's name using an ASCII-only assumption. Rather than let one of these systems mangle accented input unpredictably — sometimes replacing it with question marks or garbled bytes — converting to plain ASCII ahead of time keeps the result readable and under your control.
The most common real use case: URL slugs
By far the most frequent reason to strip Vietnamese diacritics is generating a URL slug from a title or name — a blog post titled "Cách Nấu Phở Bò" needs to become something like cach-nau-pho-bo for a clean, shareable URL, since accented characters in a URL are technically legal but inconsistently handled across browsers, social sharing previews, and older tools. Lowercasing and hyphenating after removing diacritics, in one step, is what turns a title into a URL-ready slug rather than requiring two separate manual passes.
What gets lost, and why that's sometimes fine
Removing diacritics is a one-way, lossy conversion — "ma," "má," and "mã" all collapse to the same plain "ma," and there's no reliable way to reconstruct which one was intended afterward. For anything a human will read as the primary content — an article, a message, a document — keeping the diacritics is almost always the right call, since the tone information genuinely carries meaning. Diacritic removal earns its place specifically for machine-facing identifiers (slugs, filenames, usernames, database keys) where exact pronunciation and tone don't matter and consistent, predictable ASCII does.