LocaleKit Country Format Rules

How it works

Pick a country to get its address form as an ordered field schema (with required flags and local labels like PIN code or Prefecture), the postal-code pattern with examples and validation, the calling code with basic E.164 normalisation, and date/number formatting examples for the country’s likely locale.

• Address rules come from Google’s Address Data Service (the libaddressinput metadata used by Chromium and Android): fmt gives field order and line breaks (%N name, %O organisation, %A street, %D dependent locality, %C city, %S state/province, %Z postal code, %X sorting code), require/upper list required and upper-cased fields; missing keys fall back to the ZZ defaults.
• Field labels use the country’s zip/state/locality/sublocality name types (e.g. PIN code, Eircode, Prefecture). Tokens not documented in the public metadata (e.g. %T, %F, %L for India) are reported as unmapped rather than guessed.
• Postal-code validation trims, upper-cases and collapses whitespace, then tests the full string against the anchored data pattern ^(?:zip)$.
• Phone: calling code, international and national (trunk) prefixes and possible lengths come from libphonenumber’s PhoneNumberMetadata.xml. Normalisation removes punctuation, handles "+" or the international prefix, otherwise strips the trunk prefix only if libphonenumber defines one (so Italy keeps its leading 0) and prepends the calling code. This is basic: carrier codes, national-prefix-for-parsing rules and number-type validation are not applied.
• Locale: the country’s likely locale is derived with Intl.Locale("und-CC").maximize() (CLDR likely subtags) and used with Intl.DateTimeFormat/NumberFormat on the fixed date 2026-12-31 13:45 UTC so day/month order is unambiguous.

Address and phone metadata change; always accept free-form input as a fallback and never reject an order solely because a postal code or phone number fails a pattern.