Vietnamese Date, Number, and Currency Formatting: CLDR Guide
← Blog
🌏 Localization5 min read

Vietnamese Date, Number, and Currency Formatting: CLDR Guide

💡 Vietnamese uses day-first dates (dd/MM/yyyy), a period as the thousands separator, and a comma as the decimal separator - the reverse of English. VND (₫) has no sub-units, so prices are always whole numbers. Setting the vi-VN locale correctly takes less than an hour and prevents the silent display bugs that cost you Vietnamese conversions.

Key takeaways

  • Date: dd/MM/yyyy (day first) - 11/10/2026 = October 11, never November 10.
  • Numbers: period = thousands, comma = decimal: 1.250.000,75 not 1,250,000.75.
  • VND: always whole numbers - format as 1.250.000 ₫, never 1.250.000,00 ₫.
  • No grammatical plural: use the other CLDR category for all counts in Vietnamese.
  • Use Intl.NumberFormat('vi-VN') and Intl.DateTimeFormat('vi-VN') rather than hardcoding US separators.

What date format does Vietnamese use?

Vietnamese date order is little-endian: day first, then month, then year. The Unicode CLDR short pattern for vi is dd/MM/y. This differs from the US middle-endian format (M/d/y) and matches most of continental Europe. Using four digits for the year avoids ambiguity between centuries.

Written-out dates follow the pattern ngày [day] tháng [month] năm [year]. October 11, 2026 is ngày 11 tháng 10 năm 2026. Days of the week count from Monday: Thứ Hai through Thứ Bảy, with Sunday as Chủ Nhật. CLDR sets Monday as the first day of the week for Vietnam.

Vietnamese official and technical contexts use 24-hour time: 13:45, not 1:45 PM. The JavaScript Intl API handles this automatically when you pass the locale:

new Intl.DateTimeFormat('vi-VN').format(new Date('2026-10-11'));
// "11/10/2026"
new Intl.DateTimeFormat('vi-VN', { dateStyle: 'full' }).format(new Date('2026-10-11'));
// "Chủ Nhật, 11 tháng 10, 2026"

Why do Vietnamese number separators break most checkouts?

The CLDR number symbols for vi-VN invert the English convention. In Vietnamese, the period (.) groups thousands and the comma (,) marks the decimal point. A user who sees 1,250.00 ₫ does not read "one million two hundred fifty thousand." They read a number just above one. That misread is a concrete checkout conversion loss, not a cosmetic issue.

The correct display for 1,250,500.75 (US notation) is 1.250.500,75 in Vietnamese. The ECMA-402 Intl API handles this without any custom code:

new Intl.NumberFormat('vi-VN').format(1250500.75);
// "1.250.500,75"

Never hardcode decimal or thousands separators in currency strings targeted at Vietnamese users. Always delegate to the locale-aware formatter.

How is VND (Vietnamese Dong) formatted in apps?

Vietnamese Dong (VND, ₫) has no sub-units in circulation. All retail prices and invoices use whole numbers. The CLDR standard for VND sets maximumFractionDigits: 0. Some i18n libraries default to two decimal places for all currencies, so you must override this for VND to avoid a confusing trailing ",00".

  • Correct: 1.250.000 ₫
  • Confusing: 1.250.000,00 ₫
new Intl.NumberFormat('vi-VN', {
  style: 'currency',
  currency: 'VND',
  maximumFractionDigits: 0
}).format(1250000);
// "1.250.000 ₫"

CLDR compact short forms used in Vietnamese interfaces: N (nghìn, thousand), Tr (triệu, million), Tỷ (billion). "1,5 Tr ₫" means 1.500.000 ₫. Many Vietnamese e-commerce sites show VND and USD side by side since a share of Vietnamese online shoppers are familiar with dollar pricing from international platforms.

Plural forms, classifiers, and address fields

Vietnamese has no grammatical plural. The same noun form is used whether the count is 1 or one million. CLDR defines two plural categories for vi: "one" (i = 0 or n = 1) and "other". In practice, only "other" is needed for all counts. This simplifies ICU MessageFormat strings considerably:

  • English: {count, plural, one {# item} other {# items}}
  • Vietnamese: {count, plural, other {# sản phẩm}}

One complication: Vietnamese uses classifiers (counter words) that vary by the category of the noun, not by count. For people: "3 người"; for books: "2 cuốn sách"; for flat objects: "5 tờ giấy". Machine translation often picks the wrong classifier for abstract nouns or new product categories.

For address forms, Vietnamese uses small-to-large order: street number and name, then ward (phường or xã), then district (quận or huyện), then city or province. Example: "123 Lê Lợi, Phường Bến Nghé, Quận 1, TP. Hồ Chí Minh". A western two-line address input will not serve Vietnamese users well. Split into four distinct fields: Street, Ward, District, and City or Province.

What you can configure yourself vs when a native reviewer helps

Everything in the sections above - date patterns, number separators, VND fraction digits, plural rules - is mechanical configuration. Your engineering team can handle it entirely with the Intl API or an ICU-compatible library such as Format.js, ICU4J, or Android ResourceBundle. No Vietnamese linguist is required at this layer.

A Vietnamese website localization specialist adds real value at the content layer:

  • Reviewing mixed-format strings where a number appears inside a sentence and the surrounding Vietnamese grammar must match.
  • Checking compact number labels ("N", "Tr", "Tỷ") against the register your target users expect - northern and southern Vietnamese differ in some everyday financial expressions.
  • Catching Tết references, lunar calendar copy, and public holidays that need culturally aware wording rather than simple date conversion.
  • Verifying classifier usage in notification copy and count strings that automated translation routinely gets wrong.

FAQ

Should I use vi or vi-VN as my locale tag?

Both deliver the same CLDR data. The BCP 47 recommendation is to use the shortest tag that identifies your locale, so vi is correct and minimal. Use vi-VN if your framework requires an explicit region or you want to future-proof for potential overseas Vietnamese variants. Either works in the Intl API, next-intl, Format.js, and ICU4J.

Why does my library show a period as the decimal separator when CLDR says comma?

Some older i18n libraries default to the root locale or the operating system locale instead of CLDR data. Verify that you are passing 'vi-VN' explicitly to the formatter and that your library version is backed by current CLDR data. CLDR 48 is the latest stable release as of 2026. Update to the latest library version if needed.

My store allows USD checkout. Do I still need to show VND?

The State Bank of Vietnam requires that goods and services sold in Vietnam be priced in VND. Displaying only USD on a Vietnamese-market store is non-compliant and confuses most local consumers. Show VND as the primary price with the ₫ symbol, and optionally display a USD equivalent in smaller text. Use zero decimal places for VND at all times.

How do I handle the Vietnamese lunar calendar in a scheduling app?

The Gregorian calendar is the official calendar for all legal and business purposes in Vietnam. The lunar calendar (Âm lịch) is used for cultural events and Tết planning. CLDR supports the Buddhist calendar as an approximation of the lunar calendar. For accurate Gregorian-to-lunar conversion, use a dedicated library. Displaying both Gregorian and lunar dates side by side is a standard pattern in Vietnamese calendar applications.

Does setting vi-VN in the Intl API affect translation, or only formatting?

The Intl API controls formatting only: numbers, dates, and currency display. It does not load translated strings. You still need a separate i18n system with a Vietnamese message catalog to translate your UI text. Setting vi-VN in Intl.NumberFormat formats numbers correctly but does not translate "checkout" to "thanh toán".

Official Sources

Written by Dao Huy (Lucas), Vietnamese translator & localization specialist (EN · ZH · FR → Vietnamese). See translation services →

Get QuoteWhatsApp