Intl API Locale Data and Portable Browser Formatting

The JavaScript Intl API helps an application present dates, numbers, currencies, and related language-sensitive information in forms people recognize. It does not decide what a user meant, which country a person belongs to, or which time zone an event occurred in. Portable formatting begins with clear application data and an explicit presentation choice. The browser can then turn a value into a localized string without requiring the application to maintain every punctuation and ordering convention itself.

An application should keep the underlying value separate from the text shown on screen. A number remains a number when one locale groups digits differently from another. An event timestamp remains the same instant when two viewers see different local times. The formatted text is for people; it is not a stable storage format, a reliable parser input, or evidence of the user's identity. This distinction prevents many errors that otherwise appear only after a product reaches another language or region.

Browser locale data can change with runtime updates, and supported presentation details can differ between environments. The right compatibility target is not identical punctuation everywhere. It is that a person can understand the value, choose an appropriate language or region when needed, and complete the task. For the separate question of keeping a browser's language and time-zone settings coherent, see the timezone, locale, and language guide. This page focuses on application output rather than browser identity.

Let the user choose the presentation language

A browser can provide a language preference, but an application should not treat that signal as an irreversible decision. People share devices, travel, work across languages, or prefer different languages for different tasks. The account language may also be more useful than the browser's current preference. Choose an initial presentation using the information available to the application, then provide a visible way to change it when language matters to the task.

Separate interface language from formatting locale where the product needs that distinction. Someone may read English instructions while expecting dates and prices in a regional format. Another person may choose a language for content without wanting the account's billing currency to change. The application should name the choice it offers. A control labeled "Language" should not silently change a financial value's currency or an event's underlying time zone.

An explicit user choice should take precedence over an inferred default. If the user selects a supported language, keep the interface consistent across pages and later visits according to the product's stated preference behavior. Make it possible to change that choice again. If the application remembers the choice in an account or browser store, explain where it applies. A preference chosen for one workspace should not unexpectedly govern an unrelated account.

Fallback behavior should also be predictable. A request may name a language the application has not translated, or a region-specific variant may be unavailable. Select a documented fallback, keep the chosen language visible, and avoid mixing unrelated languages within one task. A fallback can preserve access to the service, but it should not pretend that a translation exists when only part of the interface has been localized.

Language tags identify language and may include script or regional subtags. The ECMA-402 Internationalization API defines how locale identifiers are handled by its formatting services. The application still owns the product decision about which languages it supports and how a preference maps to available content. Supplying a locale identifier to Intl cannot translate labels, instructions, legal text, or user-generated content.

Keep content language and formatting behavior aligned where possible, but do not force a single value to serve every purpose. A message written in Spanish can contain an amount formatted for a billing region and a meeting time shown in the viewer's chosen time zone. State which choice governs each value. This is clearer than treating a browser language preference as a complete profile of a person.

Locale selection affects accessibility as well as visual polish. Correct language metadata helps assistive technology pronounce text appropriately. Controls for changing language need names in a language the user can still recognize after an accidental switch. A page should preserve focus and the current task when the interface language changes. Requiring a full restart or discarding form input can turn a useful preference into a barrier.

Test the first-visit default, an explicit change, a stored preference, an unsupported requested variant, and a return to the previous language. Check the interface text and the formatted values together. A date may be correct while the label around it remains in another language, or a translated label may be correct while a hard-coded number format remains unchanged.

For a broader explanation of how browser, account, site, and network choices interact, read the cross-surface browser privacy guide. A language preference is a presentation input; combining it with unrelated signals for user classification is a different data use and is outside routine formatting.

Use Intl for presentation, not as the source of truth

Intl provides formatters and other language-sensitive services to JavaScript applications. ECMA-402 specifies their behavior and the model for locale-sensitive operations. MDN documents the common formatter interfaces and their application use. The browser supplies the implementation and locale data. The application supplies the value, relevant options, and the context in which the result will be shown.

Keep canonical data in types and fields that express its meaning. A monetary amount needs a numeric value and a separate currency code. A scheduled event needs an instant or a clearly defined local-time rule and an applicable time zone. A measurement needs a value and a unit. A formatted string cannot reliably carry all of those fields back into storage because punctuation, symbols, order, and language can vary.

Formatting is usually the last step before display. A data service can return structured values; the page can apply the viewer's selected presentation choices. This arrangement makes it possible to change the interface language without rewriting the stored record. It also makes export rules explicit: a machine-readable export can keep structured values, while a human-readable report can carry localized labels and formatting.

Do not parse a localized display string to recover the original value. A comma can separate groups in one convention and denote a decimal fraction in another. Currency symbols can refer to more than one currency. Dates with only numbers can be ambiguous when day and month order differ. If the product accepts user input, define an input format and validation behavior separately from the output formatter. Make the accepted format visible at the field.

Choose options based on the domain. A payment receipt may need a currency and a rounding policy owned by the financial workflow. A scientific display may need a unit and a precision rule that preserves useful information. A relative time label may help with orientation but should not replace an exact timestamp where records need to be compared. Intl can express the chosen presentation, but it does not decide the product's legal, accounting, scientific, or scheduling rules.

Keep machine protocols separate from human presentation. APIs, databases, logs, and signatures need stable data contracts. Localized formatting belongs at a human-facing boundary unless a protocol explicitly defines it. A value copied from a localized page should carry enough context to remain understandable elsewhere, especially when a user may paste it into a message, spreadsheet, or support request.

The formatter output is also not a suitable persistent user identifier. Its exact appearance can change when browser locale data, options, or runtime versions change. If an application needs to remember a user preference, store the preference itself, such as a chosen language or time zone, rather than the last formatted result. Avoid turning presentation differences into a device profile.

This separation improves testing. A test can first verify the underlying value and the selected presentation options, then verify that the output communicates the intended meaning. It need not insist that every valid runtime use identical spaces, abbreviations, or punctuation. Exact text assertions remain appropriate where the product explicitly owns a fixed label or a regulated display requirement.

Format numbers, money, and dates with their context

Numbers require more context than a locale tag. A count, percentage, distance, temperature, price, and identifier may all contain digits, yet users interpret them differently. Give the formatter the kind of value the interface is presenting, and place a clear label beside it. A number shown without its unit or role may be visually polished but still ambiguous.

For percentages, distinguish the stored value from the displayed convention. A product that stores a fraction should format it according to the formatter's expected input model. A product that stores percentage points needs a different conversion choice. The application must own that meaning; a locale setting cannot repair a mismatch between the stored quantity and its label.

For money, keep the currency code with the amount. A locale can influence the order of the symbol, spacing, and digit grouping, but it does not determine which currency a transaction used. Changing the viewer's language should not silently convert the amount or relabel it with another currency. Conversion, when offered, is a separate operation with an exchange-rate source and an effective time that the product should explain.

Rounding is another product rule. The formatter can display a chosen number of digits, but it should not become the only place where a financial or scientific rounding policy lives. Values that are stored, compared, or totaled need a defined calculation path. A display rounded for readability should not be mistaken for the exact value used in a transaction or analysis.

Dates need both the value and the time-zone decision. An instant recorded in a system can be displayed in a viewer's time zone, an event's venue time zone, or a fixed reporting zone. Those are different product meanings. A language tag changes the wording and ordering of date parts; it does not by itself choose the right zone for an appointment or legal deadline.

Local calendar dates also need careful handling. A birthday, a hotel check-in date, and a daily reporting period may refer to a calendar day rather than a universal instant. Converting such a value through an arbitrary time zone can move it to a neighboring date. Keep the domain type clear before formatting, and show the applicable zone when a time-specific event could otherwise be misunderstood.

Daylight-saving changes make casual assumptions particularly fragile. A local wall time may repeat or not occur on a transition day. An application that schedules events must resolve that according to a documented rule; formatting a timestamp is only the presentation step. For routine display, include a zone name or offset when people need to compare times across places. Avoid making a person infer the zone from language or location.

The API boundary is specific: Intl.Locale handles locale identifiers, Intl.NumberFormat presents numbers and currencies, and Intl.DateTimeFormat presents date-time values. Those APIs do not choose a transaction currency, define a calendar-day value, or resolve an application's scheduling rule.

Time-zone correctness deserves focused application tests, especially for travel, recurring events, and daylight-saving boundaries. Keep that domain logic separate from the general formatting layer. The JavaScript Math consistency article addresses numeric computation and portability; it is not a substitute for deciding the meaning of a date, currency, or unit before display.

Use examples that match real tasks during review. A receipt should show the right amount and currency; a calendar should show the correct event day in the chosen zone; a measurement should show its unit; a count should remain legible at large values. These checks catch meaning errors that a generic snapshot of formatted punctuation would miss.

Account for locale-data and runtime differences

Intl behavior depends on both the ECMA-402 contract and the locale data available in the runtime. The specification defines algorithms and required behavior, but it does not freeze every word, abbreviation, or typographic detail in every language for all future browser releases. Locale conventions evolve. A browser or operating system update can bring new data even when application code has not changed.

Treat locale support as a product requirement with observable outcomes. List the languages and regional variants the application promises, the formatter features it uses, and the fallback it offers when support is unavailable. Test those promises on the browsers the product supports. Do not infer support merely from a version number or from one successful format in another locale.

The application should be resilient when a preferred locale or option cannot produce the requested presentation. A fallback should preserve the value and make the result understandable. A missing regional convention should not turn a payment amount into an unlabeled number or a scheduling deadline into a date with no zone. In high-stakes workflows, explain the fallback and give the user a way to inspect the underlying context.

Expect harmless variation in typography. Spacing, grouping marks, punctuation, and abbreviations may differ across valid implementations. A string may contain spaces that look alike but are represented differently. Hard-coded string equality can make a test brittle when the user-visible meaning is still correct. Compare structured values and product outcomes where possible, and reserve exact text checks for text the product truly controls.

Locale data is not a source of identity truth. The fact that one runtime chooses a particular abbreviation does not establish where a person lives or what language they speak. The application should not classify users from formatter output. Use explicit preferences and task data for presentation decisions, and keep any compatibility diagnostics bounded to the relevant product result.

Review fonts and layout with real localized strings. Formatted dates and prices can be longer than the English examples used in a design. A currency symbol may require a font fallback; a date label may wrap; a right-to-left language can change surrounding layout needs. These are interface issues that the formatter cannot solve alone. Allocate space, allow wrapping, and verify reading order in the supported languages.

Consider copied and exported content. A number that is clear inside a labeled table can become ambiguous when pasted without its heading. Include the unit, currency, date zone, or other necessary context in exports and share actions. For machine-readable exports, use an explicit schema and leave localization to the receiving interface rather than exporting only display text.

When a browser update changes an output, investigate the user-facing consequence before calling it a regression. Did the amount's meaning change, did a label become unreadable, or did only spacing change? Did the application rely on a fixed string that the platform never promised? A bounded fixture set tied to actual tasks makes this distinction clearer than collecting every formatter variation.

Document which application revision, browser release, selected locale, and input value produced a reported display issue. These facts can help reproduce a problem without collecting unrelated browser characteristics. Retain support diagnostics only as long as the issue needs them, and avoid turning a formatting complaint into a general environment inventory.

Make formatting understandable and accessible

A localized string has to be understandable in context. A date displayed as a short sequence of digits may be compact but ambiguous. A number with grouping and decimal marks still needs a label. Currency, unit, and time-zone context should be visible where a person makes a decision, not hidden in a tooltip that may be unavailable to assistive technology.

Use semantic page elements for the text around a formatted value. A table heading can name the amount or date; a form label can state the accepted input format; a status message can explain a changed preference. This structure helps screen readers and other tools associate the value with its meaning. Formatting alone cannot supply relationships that the page markup omits.

The document language should reflect the actual language of its text. When a page includes a passage in another language, mark that passage appropriately so assistive technology can pronounce it. A language selector should remain discoverable when the current selection is unfamiliar to the user. Do not rely only on flags to represent languages; one language can be used in multiple countries, and one country can contain many languages.

Give users control when an automatic default is wrong. A visible language or regional-format choice is especially important in shared-device, travel, and multilingual workflows. Keep the choice separate from location permission and from unrelated account data. Someone should not have to disclose a precise location merely to read a date or amount in a familiar format.

Changes in presentation should not alter the underlying record. If a user changes language while editing a form, preserve the entered value and explain any change in its display. If a scheduled event appears in a different time zone, keep the original event identity and show the zone used for the new display. These transitions should be reversible and should not silently commit a new transaction or appointment.

Test with assistive technology and with the text sizes the audience uses. Check that long localized values wrap without obscuring adjacent controls, that reading order remains sensible, and that a copied value includes the context needed outside the page. Where a value is abbreviated visually, provide an accessible full form when that improves clarity. Avoid duplicating announcements that make the page noisy.

Error messages need localization and context too. If the application rejects a number or date, state which input format it accepts and show an example appropriate to the selected language. Do not simply echo the user's input back in a different format and call it invalid. Distinguish a parsing error from a value that is valid but outside a domain limit.

The best acceptance test is a real task. Can a user understand a price and its currency before confirming payment? Can a participant tell when an event begins and which time zone applies? Can someone switch languages without losing work? These outcomes matter more than reproducing every character emitted by one runtime.

Review formatting as a product contract

Define which values are formatted by the browser, which are returned already localized by a service, and which must stay machine-readable. Duplicate formatting ownership can produce mixed languages or double conversion. A clear boundary lets the application change presentation without changing the underlying data and keeps service contracts stable.

Keep a small set of representative fixtures for each supported workflow. Include at least one ordinary date, a time near a zone transition where scheduling matters, a large or fractional number, and a currency with an explicit code if the product handles money. Each fixture should prove a named user outcome. Add a case when a real failure reveals a new risk; avoid building a catalog of arbitrary locale strings with no product decision behind it.

For a synthetic money fixture, format the value 1234.5 as EUR with en-GB presentation, an explicit currency code, and two fractional digits. The user should read an amount equivalent to 1234.50 euros with EUR identified; locale-data changes in spacing do not fail this test, but a changed amount or missing currency label does. If the application supports only English and French and receives a Spanish preference, its declared English fallback must show the same amount and currency and identify the current language.

For a scheduling fixture, keep the instant 2026-01-01T01:30:00Z fixed: UTC presentation represents 1 January 2026 at 01:30, while America/New_York represents 31 December 2025 at 20:30. Both views must identify their time-zone context and refer to the same stored instant; punctuation may vary, but a changed instant or an unexplained date change fails the task.

Review the fallback path with the same care as the preferred one. An unsupported requested locale, missing translation, or failed formatter should still leave the value and task understandable. The interface should say which language or format it is using rather than silently mixing variants. Preserve the user's ability to return to a supported choice.

Check privacy data flow when adding localization tools or third-party components. A formatter running in the browser does not require the application to send a detailed browser inventory to another service. If a service receives language or regional preferences for a legitimate task, document why it needs them and how long it retains them. Do not reuse presentation preferences as a hidden targeting signal.

Internationalization is an ongoing application responsibility. Intl removes the need to hand-build many language-specific formatting rules, but it does not translate product content, define the meaning of stored values, choose a user's identity, or guarantee identical strings on every runtime. Treat values, presentation preferences, and formatted output as separate layers. Users can then read familiar text without losing control of the underlying task.

Public sources

• ECMA-402 Internationalization API
• MDN: Intl