Postal codes are not universal in presence, length, or format

What it is

Country-specific postal code rules reflect that postcodes do not exist everywhere and share no global character set, length, grouping, prefix, or placement. A code may be numeric, alphanumeric, contain spaces or hyphens, or apply only to some areas or address types. Treat it as a string. Whether it appears, is required, and what forms are acceptable must come from current destination-country or territory postal data, not one worldwide regular expression.

Why it happens

A postal code is created by a postal network for sorting or delivery areas; it is neither a coordinate nor a universal address identifier. Current UPU resources distinguish destinations with and without postcode systems and document each destination's structure and placement. Rules evolve with postal reforms, boundaries, and operations. Unicode CLDR's former postalCodeData has been deprecated, illustrating why a static regex is difficult to keep authoritative. Numeric storage strips leading zeroes and rejects letters, while premature removal of spaces or hyphens can destroy familiar local form and useful error signals.

Studying it

For every served destination, record postcode availability, examples, accepted characters, placement, source, and update date from its designated postal operator or UPU material. Test de-identified valid samples and systematic variants involving case, internal spaces, hyphens, leading zeroes, pasted text, legacy codes, and boundary regions. Distinguish “parseable,” “syntactically plausible,” “consistent with the administrative area,” and “confirmed deliverable”; a regex establishes none of the latter claims alone. Correction rates and carrier return reasons can reveal stale metadata or over-rejection.

Where it stops holding

A format match does not prove that a code is allocated, current, consistent with the street, or deliverable. Autocomplete and third-party verification have coverage, freshness, and licensing limits, so people need a route to continue or correct the result. For a destination without a postcode system, or an address type that does not require one, blank is valid and no placeholder should be demanded. Normalization may support comparison, but retain the original or a reversible representation for display and audit.

Applying it

• Store postcodes as Unicode strings, never numbers, preserving leading zeroes. Localize the field label to the destination's familiar term such as postcode, postal code, or ZIP code.
• Read applicability, requiredness, examples, and validation hints from versioned country or territory metadata with a named source. When reliable rules are absent, use permissive safety checks for length and characters.
• Accept reasonable case and separator variants, then echo the destination format after blur or submission. Explain failures with an expected example, preserve the original input, and never invent a dummy code.
• Maintain regressions for country switching, leading zeroes, alphanumerics, internal spaces, no-postcode destinations, and metadata updates. Verify that front end, API, database, CSV, and spreadsheet export do not mutate the code.

Related

• Same group: S2.06.1 Address hierarchy depth and order vary by country · S2.06.3 A state or province field is not universally applicable · S2.06.4 Address forms should rearrange dynamically by country
• Adjacent: S2.02.4 Numeric input must accept local formats · S2.09.1 Regular-expression validation usually embeds a single-region assumption
• Search terms: postal code validation · UPU addressing systems · postcode metadata