Vietnamese Typography, Unicode and Punctuation for Digital Products

Last reviewed: 4 October 2026

Short answer

Vietnamese text needs more than a font that displays a few accented letters. Preserve the intended Unicode text through input, storage and export; define a normalization policy; verify the actual font files and weights; and test punctuation, spacing and wrapping in context. A string can look correct in one screenshot while failing search, truncation or a PDF export. Separate data correctness from visual rendering and test both.

Key takeaways

• Preserve Vietnamese diacritics in authoritative content and customer names.
• Distinguish normalization from removing accents or changing spelling.
• Define whether a limit counts bytes, code units or grapheme clusters.
• Check every font weight and the fallback path used by the product.
• Keep punctuation rules appropriate to prose, UI labels and technical values.
• Test complete input-to-export flows, including copied and pasted text.

Why do Vietnamese diacritics need deliberate testing?

Vietnamese uses letters and tone marks that carry linguistic meaning. Removing a mark can change a word or make a customer's name inaccurate. Do not treat accents as decorative details that can be dropped to simplify rendering. Fix the encoding, font or component that is causing the problem.

Create a test specimen containing lower- and uppercase forms, multiple tone marks, ordinary sentences, numbers and punctuation. Include letters such as “ă”, “â”, “ê”, “ô”, “ơ”, “ư”, “đ” and representative combinations such as “ắ”, “ệ”, “Ỡ” and “Ự”. This is a starting specimen, not proof of complete coverage. Add actual approved product text and names from non-sensitive test data.

Inspect headings, dense tables, buttons, hints and multiline messages. A font can work in regular paragraphs while a bold heading uses a different file with missing glyphs. Check marks above and below the baseline, including lines with several marked characters next to one another. Do not infer that every variant works because one regular-weight screen looks acceptable.

What is the difference between NFC and NFD?

NFC and NFD are canonical normalization forms described in Unicode Annex #15 [1]. A displayed character may be represented by a precomposed code point or by a base character with combining marks. Canonically equivalent forms can therefore have different encoded lengths without being different words. Normalization does not mean stripping Vietnamese accents.

The following measurements were executed on Node.js v24.18.0 with ICU 78.3 and Unicode data 17.0. The selected strings use established characters; the table reports this runtime's output rather than claiming a full conformance test of the latest Unicode version. UTF-16 counts use JavaScript string length; UTF-8 byte counts use TextEncoder. Grapheme counts include spaces and punctuation.

“Đ” does not become plain “D” through canonical decomposition. Do not build a search or transliteration rule on the assumption that every Vietnamese letter decomposes into an ASCII letter and removable marks. An accent-insensitive search index, if required, needs a separately specified policy and should not overwrite the displayed original.

How can developers reproduce a normalization check?

Compare the same sample in both forms and record the metric. This code was run for the table above. It checks text lengths, not glyph quality, browser line height or database behavior. The output should be combined with integration tests rather than treated as a complete typography audit.

const segmenter = new Intl.Segmenter('vi', {
  granularity: 'grapheme'
});
const encoder = new TextEncoder();
function inspect(value) {
  return ['NFC', 'NFD'].map(form => {
    const text = value.normalize(form);
    return {
      form,
      utf16Units: text.length,
      graphemes: [...segmenter.segment(text)].length,
      utf8Bytes: encoder.encode(text).length
    };
  });
}
console.log(inspect('ắ'));
// NFC: 1 unit, 1 grapheme, 3 bytes
// NFD: 3 units, 1 grapheme, 5 bytes

Apply normalization only at a documented boundary with a clear purpose, such as a comparison or approved storage policy. Keep original inputs where the business process needs them. Do not silently normalize signed payloads, opaque identifiers or values whose exact representation is part of a protocol. Canonical normalization and compatibility normalization have different implications; choose deliberately rather than applying a broad cleanup to every field.

How should fonts and line height be checked?

Verify the exact font assets loaded in production, including subsets, weights, italics and fallbacks. A font family name in a design file is not evidence that the delivered web font contains the needed characters. Review the rendered Vietnamese specimen at the actual sizes and contrast used by the interface.

Test before and after font loading, and simulate a failed font request. Mixed fallback glyphs can alter appearance and line dimensions. Inspect combining marks in both NFC and NFD samples so that a data path producing decomposed text does not become a hidden rendering defect. Also check PDF generation, where the export engine and embedded fonts can differ from the browser.

Choose line height through testing rather than prescribing one universal number. Look for clipped upper marks, clipped lower marks, overlap between adjacent lines and text hidden by a fixed-height container. Increasing spacing may help one component but should be reviewed with the layout, especially in compact navigation and table rows.

Which punctuation and capitalization rules should be documented?

Document the rules by content type. A readable editorial convention for prose should not automatically alter source code, API keys, file paths or machine-readable values. Smart quotation marks may suit an article; straight ASCII characters may be required in technical syntax. Preserve the supplied syntax when reproducing a command or identifier.

For interface copy, use consistent sentence punctuation and capitalization. A short button often does not need a full stop, while a complete explanatory sentence can. Decide how headings, list items, abbreviations and product names are written. Avoid an automatic title-case transformation that capitalizes every Vietnamese word without editorial review.

Differentiate an ellipsis from a promise. A truncated label needs a way to access the meaningful text where the workflow requires it. An ellipsis after a command can also be a product convention indicating another dialog, so do not insert it merely for decoration. Document the intended meaning rather than mixing truncation and action states.

Specify how hyphens and longer dashes are used in your prose. Keep minus signs, version strings and technical separators intact when they carry a defined meaning. Review spaces around punctuation and numbers, but do not replace every space with a nonbreaking space: that can create overflow in narrow components.

How should line breaking and truncation work?

Test the actual browser and CSS configuration instead of treating a whitespace-delimited Vietnamese syllable as a complete lexical word. Unicode's line-breaking guidance identifies break opportunities, while actual line selection depends on available width and layout [2]. CSS text rules also affect wrapping and word breaking [3].

Do not split a base character from its combining marks when implementing a custom text limit. A string slice based only on an arbitrary code-unit position can damage displayed text. Decide whether the limit concerns storage or a user-facing count, and use the relevant boundary rules. Browser-generated visual truncation still needs a review of whether the hidden content is essential.

For long filenames, URLs or identifiers, provide a wrapping or disclosure strategy appropriate to the component. Avoid a global break-everywhere rule for all prose just to fix one pathological value. Test long values beside normal Vietnamese sentences and ensure the action remains attached to the right object.

How should encoding be verified across the data flow?

Use an explicitly understood encoding across documents, requests, storage and exports. The WHATWG Encoding Standard defines encoding behavior including UTF-8 processing [4]. A readable source file alone does not establish that every step decodes the bytes correctly. Check headers, import settings and export behavior in the systems actually used.

Run a round trip: type or paste a specimen, save it, retrieve it, edit it, export it and import it into the receiving tool. Compare the intended text at every stage. Avoid repeatedly decoding already decoded strings or treating a changed byte sequence as a change in linguistic meaning without checking normalization.

Treat replacement characters, garbled accents and missing glyph boxes as different symptoms. The cause may be decoding, an unsupported font, a subset omission or truncation. Record where the defect first appears so engineering can repair the correct stage rather than manually rewriting affected words.

What belongs in a practical QA matrix?

Use a matrix that covers both representation and display. The cases below are proposed checks, not claims that a particular product passed them. Keep screenshots and the runtime or export environment with the result.

LocalizeZone recommendation

When requesting software localization, include font information, screenshots, export formats and any text-length restrictions. LocalizeZone recommends reviewing language and typography together, with engineering owning encoding and rendering fixes. A clear brief distinguishes translation errors from technical defects and helps define the checks needed for a release in Vietnamese.

FAQ

Does normalization remove Vietnamese accents?

No. Canonical normalization concerns equivalent representations. Accent removal is a different transformation and needs a separate purpose.

Is a regular-weight font test enough?

No. Test the files and variants the product actually delivers, including fallback and export paths.

Should all UI text use smart quotes?

Choose by content type. Preserve straight characters when technical syntax requires them.

Can character count be used as a byte limit?

Not without defining the metric. The table shows different counts for graphemes, UTF-16 units and UTF-8 bytes.

Does UTF-8 guarantee correct typography?

No. Correct encoding is one layer; font coverage, shaping and component layout still need testing.

Should names be stored without accents for search?

Preserve authoritative names. A separate search index may implement an approved matching policy without replacing the original.

Sources and methodology

Primary Unicode, W3C and WHATWG documents were checked on 4 October 2026. Five original sample strings were measured locally with the stated runtime. The guide proposes font and integration checks; it does not report browser measurements, complete Unicode conformance or accessibility certification. Editorial punctuation recommendations are contextual choices, not a universal Vietnamese publishing standard.

References

[1] Unicode Consortium. Unicode Standard Annex #15: Unicode Normalization Forms.

[2] Unicode Consortium. Unicode Standard Annex #14: Unicode Line Breaking Algorithm.

[3] W3C. CSS Text Module Level 3.

[4] WHATWG. Encoding Standard.

Related guides

• Vietnamese Localization Style Guide for Software and SaaS
• Vietnamese Personal Names: A Guide for Forms, Databases and User Interfaces
• Vietnamese Text Expansion in Software Localization: What Developers Should Expect
• Vietnamese Date, Time, Number and Currency Formatting Guide
• Vietnamese Address Format: A Guide for Forms, Ecommerce and Databases
• Vietnamese Phone Number Formatting for Websites and Apps