When you sell globally, you quickly bump into a frustrating reality: some carriers and postal systems still reject non-Latin, or non-Roman, characters (anything outside A–Z, 0–9 and common punctuation) in names and addresses. If your buyers type in “Łódź,” “München,” “東京,” or “محمد,” your label can fail, print with “????,” or even trigger a return.

This post explains why that happens, which rules are actually in play, the technical constraints behind the scenes, and the practical steps you can take to prevent delays—without hurting delivery success in countries that rely on local scripts.

1 - The rulebook: international mail standards favor Latin letters

The Universal Postal Union (UPU)—the treaty body that defines the worldwide postal system—has long required that international addresses be written legibly in Roman (Latin) letters and Arabic numerals. The UPU’s addressing guidance explicitly cites this rule (Letter Post Regulations RL 123.3.3), and encourages adding the destination country’s native script in addition to the required Latin version.

National posts embed that same rule in their own manuals. For example, the U.S. Postal Service says the recipient and return addresses must appear in Roman letters and Arabic numerals on international mail; if an address is written in another script (e.g., Cyrillic, Arabic, Chinese, Japanese), USPS requires an interline English/Roman translation. Customs forms also must be completed in Roman letters and Arabic numerals.

Why this matters to you: even if the destination country ultimately delivers with local characters, the international leg (acceptance, outbound sorting, airline handover, inbound exchange office, etc.) is built around Latin-script routing.

2 - Carrier & platform realities: legacy encodings and hard limits

Beyond policy, many carrier IT systems were built decades ago around single-byte character sets (ASCII, ISO-8859-1/“Latin-1”). Those systems still power label generation, routing messages, EDI, billing, and compliance workflows—so they often reject or mangle Unicode.

• UPS states plainly in its Developer Kit FAQ that backend and shipping systems (including the Shipping API) do not support double-byte/Unicode (UTF-8); only Latin characters are accepted. Some UPS file-submission portals also publish strict “valid characters” tables. Practically, invalid characters are removed or replaced, which can break addresses.
• FedEx developer documentation instructs shippers to “ensure all values are escaped and not feed non ASCII characters.” Labels and documents are generated from those ASCII-only values.

Third-party shipping tools see the fallout: when you pass non-Latin characters to a Latin-only pipeline, you’ll often get label errors or “?” substitutions.

3 - The print pipeline: label printers, fonts, and device languages

Even if your app and carrier API can technically carry Unicode, the last mile of label rendering can fail:

• Many warehouses still print via Zebra (ZPL) or EPL. Historically, those used code pages rather than Unicode. ZPL gained UTF-8 support with ^CI28, but that requires newer firmware, correct font packs, and proper configuration across systems—conditions not guaranteed in carrier depots or merchant warehouses. If any hop in the pipeline lacks compatible fonts/encoding, non-Latin characters print as boxes or question marks.

Bottom line: carriers minimize risk by enforcing Latin characters so labels remain machine-readable across thousands of mixed devices and versions worldwide.

4 - Automation & OCR: machines expect Latin

High-speed sorters and OCR systems in many origin countries are tuned for Latin scripts, especially on the international dispatch leg. The UPU’s own addressing guidance emphasizes formatting addresses to facilitate automatic reading, which is easiest when addresses use Roman characters in consistent layouts. When non-Latin text appears without a Latin counterpart, pieces are more likely to be kicked to manual handling, slowing things down.

5 - Customs and data exchange: Roman letters required

It’s not just the label face. Customs data (CN22/CN23, commercial invoices, electronic pre-advice) must be readable by border agencies worldwide. USPS incorporates this into its International Mail Manual: all information on customs forms must appear in Roman letters and Arabic numerals. Carriers feed that same data to brokers and government systems—another reason they normalize to Latin.

6 - Field lengths & “forbidden” characters

International labels also have strict line lengths and character whitelists. For instance, DHL freight label specs show 35-character line limits and standardized encoding constraints, and UPS documentation lists allowed characters for transmitted files—anything else can error out or be replaced. These constraints make addresses with diacritics or non-Latin scripts especially brittle.

7 - “But local delivery needs the native script!” — the nuance

In some countries, last-mile carriers deliver more reliably if the address appears in the local script. The UPU anticipated this and recommends supplementing the Latin version with local characters—in addition to, not instead of—the Latin address. That way, the international pipeline can route on Latin, and the local carrier can verify on the native script. USPS echoes this approach: if an address is written in a non-Latin script, add an interline translation in English/Roman characters. For parcels, USPS even recommends enclosing a duplicate address slip inside the package.

8 - Practical playbook for merchants

Here’s how to stay compliant and maximize successful delivery:

1. Collect Latin by default, allow local script as a helper — Store a Latin (transliterated) version in the official shipping fields. Provide an optional “Local script for delivery note” field if helpful.
2. Respect line lengths & allowed characters — Enforce per-line limits (e.g., 35 characters) and strip unsupported punctuation.
3. Keep the country name in an internationally recognized language — Many specs require English or internationally recognized country names.
4. Mind the customs side — Ensure product descriptions and names on customs forms are Latin-only and legible; avoid emoji/quotes/special punctuation.
5. Upgrade printers carefully — If printing labels in-house, ensure UTF-8 support and correct fonts, but don’t assume carriers accept Unicode through APIs.

9 - How an address-validation app helps

Tools like LatinLock, for Shopify stores, enforce Latin-only characters at checkout, ensuring that buyers enter addresses in a format carriers will accept. Merchants can configure the app to allow select non-Latin characters if needed, giving flexibility for certain markets. While the app doesn’t currently handle transliteration (for example, automatically converting “東京” to “Tokyo”), it does prevent inadmissible characters from being included in shipping addresses. This proactive step helps merchants avoid failed label generation, order cancellations, costly returns, and unhappy customers.

It’s also worth noting that automatic transliteration at Shopify checkout isn’t straightforward: Shopify doesn’t natively expose transliteration logic in its checkout fields, and transliterating names and addresses in real time can introduce errors or confusion for buyers (e.g., multiple possible Latin spellings for the same character). Instead, blocking unsupported characters up front provides a clear, reliable safeguard without altering customer input in unpredictable ways.

Key Takeaways

• Latin characters are required for international shipping labels and customs compliance.
• Carrier IT systems and label printers often reject Unicode; Latin-only addresses avoid errors.
• LatinLock ensures compliance at checkout, blocking unsupported characters and giving merchants confidence that orders will flow smoothly through carriers and postal systems.
• Supplementary local-script fields are optional but recommended for last-mile delivery.