Global gifting teams do not lose parcels because a country name is missing from a dropdown. They lose control when one universal address form flattens postal components, changes recipient-written text, or treats a syntactically valid postcode as proof that a carrier can deliver. This 2026 dataset gives operations, product, and engineering teams a practical starting point for twenty-five markets while keeping the final decision with the recipient, postal operator, and selected carrier.
Hero: international address components are organized for validation without pretending that one layout fits every market.
Download the versioned dataset and understand its limits
Download the localized Excel workbook or download the UTF-8 CSV file. Version 2026.09.20-v1 covers twenty-five markets and records an official source for every row. The workbook contains Read Me, Address Fields, Validation Notes, Source Register, and QA worksheets. Its formulas were scanned for errors, all five worksheets were rendered and visually inspected, and the downloadable files were verified against their recorded SHA-256 checksums after upload.
The asset is a design and delivery-readiness reference, not a promise of postal acceptance. A route can change after this article is verified; a carrier may require a phone number or reject a serviceable postal address for customs, sanctions, restricted goods, remote-area, or account-contract reasons. Before dispatch, confirm the actual carrier, service, destination, recipient input, and product restrictions. Keep the downloaded version and the decision timestamp so a later investigation can reproduce the rule set that was used.
The compact table below is the usable public preview. It deliberately stores components and order, not one formatted free-text string. “Required” describes the dataset’s form recommendation, not a legal conclusion. Where current official evidence was not reachable during the final live check, the dataset keeps the recorded source and directs the production path to recipient and carrier confirmation.
Table: twenty-five-market address component and evidence preview, version 2026.09.20-v1.
| ISO | Market | Recommended field or line order | Postal-code rule | Operational warning | Official source |
|---|---|---|---|---|---|
| US | United States | Recipient; organization; street; locality; state; ZIP | Yes | Confirm unit and state abbreviation | Official source |
| CA | Canada | Recipient; organization; street; municipality; province; postal code | Yes | Postal code uses letters and numbers | Official source |
| MX | Mexico | Recipient; street; neighborhood; postal code/locality; state | Yes | Neighborhood may be operationally important | Official source |
| BR | Brazil | Recipient; street/number; complement; district; locality-state; postal code | Yes | Keep number and complement separate | Official source |
| GB | United Kingdom | Recipient; organization; premise; street; post town; postcode | Yes | Post town and postcode drive routing | Official source |
| IE | Ireland | Recipient; premise/street; locality; county; Eircode | Conditional | Do not infer missing Eircode | Official source |
| FR | France | Recipient; organization; premise/street; postal code/locality | Yes | Preserve accents where supported | Official source |
| DE | Germany | Recipient; organization; street/house number; postal code/locality | Yes | House number follows street | Official source |
| NL | Netherlands | Recipient; street/house number; postal code/locality | Yes | Postcode includes letters and numbers | Official source |
| IT | Italy | Recipient; street/type/number; postal code/locality/province | Yes | Province code may aid operations | Official source |
| ES | Spain | Recipient; street/type/number; postal code/locality; province | Yes | Keep province distinct from locality | Official source |
| CH | Switzerland | Recipient; street/number; postal code/locality | Yes | Use official locality spelling | Official source |
| SE | Sweden | Recipient; street/number; postal code/locality | Yes | Preserve spacing in postal code | Official source |
| NO | Norway | Recipient; street/number; postal code/locality | Yes | Use four-digit postal code as text | Official source |
| DK | Denmark | Recipient; street/number; postal code/locality | Yes | Apartment details may need separate line | Official source |
| PL | Poland | Recipient; street/number; postal code/locality | Yes | Preserve hyphenated postal code | Official source |
| AU | Australia | Recipient; organization; street; locality/state/postcode | Yes | State abbreviation and postcode share line | Official source |
| NZ | New Zealand | Recipient; street; suburb; city/postcode | Recommended | Suburb can improve delivery readiness | Official source |
| JP | Japan | Postal code; prefecture; locality; street; building; recipient | Yes | Do not reverse or romanize without recipient choice | Official source |
| KR | South Korea | Postal code; province/city; road address; building/unit; recipient | Yes | Keep road-name and unit fields distinct | Official source |
| CN | China | Postal code; province/city/district; street; building/unit; recipient | Recommended | Use recipient-confirmed Chinese address where possible | Official source |
| TW | Taiwan | Postal code; city/county; district/township; road/section/lane/alley/number/floor; recipient | Yes | Preserve Traditional Chinese and detailed street components | Official source |
| HK | Hong Kong | Recipient; room/floor/block; building; street; district; territory | No | Do not invent a postal code | Official source |
| SG | Singapore | Recipient; block/street; unit; building; Singapore/postal code | Yes | Unit and postal code are critical | Official source |
| IN | India | Recipient; premise/street; locality; city/district; state; PIN | Yes | State, district and PIN should be separate fields | Official source |
Why a single global address form fails
An address is both structured data and a human-readable delivery instruction. The structured side helps a system search, validate, deduplicate, and map to a carrier request. The human-readable side preserves local sequence, script, building details, and the recipient’s own understanding of where the parcel should go. A reliable product keeps both. It never assumes that the database’s canonical fields are the only acceptable printed form.
Common failure begins with a form designed around street, city, state, and ZIP. That model is familiar in the United States, but it cannot cleanly represent a Japanese address that begins with a postal code and prefecture, a Hong Kong address with no postcode, a Brazilian complement and district, or a Singapore block and unit. The predictable workaround is an overloaded “address line 2.” Once several concepts share that line, validation cannot explain what is missing and operations cannot safely correct it.
The second failure is destructive normalization. Uppercasing, removing accents, collapsing spaces, translating locality names, or forcing romanization may make a record look consistent while making it less faithful. Normalize a separate comparison key for search and deduplication; preserve the recipient-confirmed display value. If a carrier requires a transliterated copy, store it as a derived field with provenance rather than overwriting the original.
The third failure is false certainty. A postcode pattern can reject obvious syntax errors, but it cannot prove that a building exists, that the unit is complete, or that the selected service reaches that destination. Label validation outcomes honestly: syntax accepted, recipient confirmed, official lookup matched, carrier accepted, or delivery completed. Those states are not interchangeable.
Model components, presentation order, and evidence separately
Use one address object with explicit components: recipient, organization, country code, administrative areas, locality, dependent locality, street name, building number, premise, unit, postal code, and delivery instructions. Add original-script and transliterated representations only when the program genuinely needs both. Every field should have a definition, maximum length, allowed character policy, sensitivity classification, retention rule, and source.
Presentation order belongs in a market profile rather than in the storage schema. The same stored components can then produce a local review view, a carrier payload, and a printable label without rearranging the underlying truth. The renderer should know whether the country line is added for international mail, whether the unit precedes the building, and whether the recipient line appears first or last. Version the renderer independently from the recipient record.
Evidence also needs its own object. Record the market, rule version, official source URL, verification date, verifier, evidence gap, and next review date. The USPS Publication 28, Canada Post addressing guidelines, Royal Mail country guides, Japan Post guidance, Australia Post addressing guidelines, and Chunghwa Post postal guidance illustrate why teams should cite market-specific primary material rather than a generic blog summary.
The Universal Postal Union addressing page was retained as a methodological starting point, but its live page timed out in the final check on September 20, 2026. Hongkong Post’s preparation page also returned a research-client error. These are explicit evidence gaps, not permission to infer a rule. The safe production response is to preserve the last recorded source, require recipient confirmation, and obtain carrier acceptance before money or inventory is committed.
Build validation as a sequence of claims
Validation should return a result the operator can understand. Begin with presence: are the fields required by this market profile supplied? Then test type and syntax without deleting characters. Next test cross-field consistency, such as country, administrative area, and postcode relationships. If an official lookup or carrier validation service is available, store its response and timestamp. Finally, ask the recipient to confirm the formatted address that will be used.
Do not turn a third-party correction into silent truth. Show suggested changes, distinguish formatting from substantive edits, and let the recipient accept or reject them. A change from a recognized locality abbreviation may be low risk; a different unit, street number, or district is not. High-impact changes should pause dispatch and create an exception owned by operations.
Use stable result codes rather than prose alone: accepted, needs recipient confirmation, needs operations review, unsupported market, service unavailable, and carrier rejected. Each result should include the rule version, failed fields, evidence used, and permitted next actions. A retry must reuse the same request identifier so a slow validation response does not create a second gift order.
Validation is evidence about one step in the route. It is not a guarantee that every later step will succeed.
What should happen when the validator is unavailable?
Do not replace an outage with a green check. Mark the result as unavailable, retain the recipient-confirmed address, and apply a documented fallback based on program risk. Low-value domestic mail may proceed with manual review; high-value or cross-border shipments may pause until the carrier confirms service. Record the fallback owner, reason, timestamp, and expiry so temporary behavior does not become an invisible permanent rule.
Worked case: a United States and Europe recognition campaign
Assume a people team is sending 420 recognition gifts: 260 to the United States, 60 to Canada, 45 to the United Kingdom, and 55 across France, Germany, the Netherlands, Ireland, Spain, and Switzerland. The intake file contains names, work email, country, and several unstructured address lines. The deadline is three weeks away and the gifts have different customs classifications.
The program owner first freezes eligibility and budget. The data owner maps each record to a market profile without changing the original text. United States records are split into unit, street, city, state, and ZIP; Canadian records retain alphanumeric postal codes; United Kingdom records preserve post town and postcode; Ireland records do not invent a missing Eircode. European accents and house-number placement remain in the recipient-confirmed view.
The validator produces 382 syntax-accepted records, 24 recipient-confirmation requests, nine operations-review cases, and five unsupported combinations. The team does not claim that 382 parcels are deliverable. It asks recipients to review the final label view and sends the resulting service request to the chosen carrier. Fourteen responses correct unit or building details, which are material changes and therefore retain the old value, new value, approver, and timestamp.
Acceptance evidence is measurable: every dispatched record has a stable recipient reference, market profile version, original input, rendered label, recipient confirmation or approved exception, carrier service response, and idempotent dispatch key. Finance receives a reconciliation file keyed to the same event. If a parcel fails, operations can identify whether the failure occurred at form design, recipient confirmation, carrier acceptance, customs, or last-mile delivery.
Worked case: Japan, Korea, Taiwan, and Hong Kong
Now assume a customer program has 160 recipients across Japan, South Korea, Taiwan, and Hong Kong. The CRM holds romanized fragments for some people, local-script text for others, and one global “postal code required” rule. Applying that rule would force the Hong Kong recipients to enter invented data and would encourage the team to replace local-script addresses with approximations.
The owner changes the form by market. Japan preserves postal code, prefecture, locality, street, building, and recipient in recipient-confirmed order. Korea keeps postcode, road-name address, building, and unit distinct. Taiwan retains Traditional Chinese and separates county or city, district or township, and detailed road elements. Hong Kong removes the postcode requirement and provides room, floor, block, building, street, district, and territory fields.
The display renderer shows local script first and adds a transliterated representation only when the selected carrier requests it and the recipient confirms it. A search key may remove spacing for comparison, but it never replaces the display value. Records with missing unit or building details are returned to the recipient; they are not “fixed” by an operator guessing from a map.
The acceptance test samples each market and compares three views: recipient confirmation, carrier request, and final label. No view may lose a component, reverse an order without a documented carrier need, or substitute punctuation from another writing system. The test also confirms that the Hong Kong path can proceed with an empty postcode field and that no default value leaks into the label.
Design the failure and recovery path before dispatch
A useful address system expects failure. Separate validation failure, carrier rejection, invitation expiry, recipient correction, return to sender, damaged parcel, and confirmed nondelivery. Each state needs one owner, allowed actions, a service target, and closure evidence. “Failed” without a reason code is not an operational state.
When a recipient changes an address before dispatch, invalidate the prior confirmation and re-run the market profile. When a carrier rejects a request, store the carrier code and payload hash, correct only the affected fields, and retry with the same event identity. When a parcel is returned, do not automatically ship again. Confirm eligibility, address, inventory, customs status, and budget before creating a replacement event linked to the original.
Never overwrite an unsuccessful attempt. Append events so an investigator can see what the system knew at each decision. Protect personal data by limiting who can view raw addresses, retaining only what the program needs, and deleting according to the documented schedule. Operational evidence can often retain hashes, timestamps, rule versions, and status codes longer than the address itself.
Recovery acceptance evidence includes the original event, failure code, accountable owner, communication timestamp, corrected input provenance, new validation result, replacement authorization, and final disposition. That record lets procurement, finance, privacy, and support answer the same question without copying the address into tickets and chat threads.
Assign owners and release in controlled stages
The program owner defines eligibility, value, timing, and exception policy. Product owns field behavior and accessible recipient review. Data or privacy owners define purpose, access, retention, and deletion. Engineering owns schema versions, validation codes, idempotency, and observability. Fulfillment operations own carrier mapping, serviceability, labeling, and exception closure. Support owns recipient communication, while finance reconciles authorized, dispatched, returned, replaced, and refunded events.
Release the form to internal test addresses first, then to a small set of consenting recipients in representative markets. Include right-to-left or CJK rendering only where applicable, long locality names, missing optional fields, alphanumeric postcodes, apartment units, and intentional validator outages. Compare the stored components, recipient review, carrier request, printed label, and tracking event.
-
Each market has a versioned field profile and official source.
-
Original script and normalized search values are stored separately.
-
The recipient can review and correct the final delivery view.
-
Validation outcomes identify what was and was not proven.
-
Carrier acceptance is stored separately from syntax validation.
-
Retries reuse a stable event identifier.
-
Failure, correction, return, and replacement have named owners.
-
Raw addresses have role-based access and a deletion schedule.
-
The release sample covers every materially different form pattern.
The release decision should be evidence-based: zero lost components in the test set, no unauthorized transformation, no duplicate dispatch in retry tests, complete owner routing for every failure, and reproducible source and rule versions. A launch with unresolved gaps must state the affected markets and manual control rather than hiding them behind a general approval.
Maintain the dataset as a product, not a one-time spreadsheet
Assign a version owner and a scheduled review date. A change request should identify the market, existing rule, proposed rule, primary evidence, impact on stored records, migration need, and test cases. Review the highest-volume and highest-failure markets first, but keep a path for support to flag a new issue immediately. Every accepted change should also name its accountable reviewer and effective date.
Track useful metrics: recipient correction rate, carrier rejection rate, return rate, missing-unit rate, time to resolve exceptions, duplicate dispatch attempts blocked, and records using an expired market profile. Compare changes by market and form version. A lower correction rate is only good if support contacts and returns also remain stable; otherwise the form may simply be preventing recipients from reporting problems.
Publish a changelog with the dataset version and verification date. When a source is unavailable, record the outage and next check rather than silently carrying a rule forward. When evidence changes, determine whether existing confirmed addresses must be reviewed again. Keep the downloadable workbook and CSV immutable for each release so an investigation can reproduce the exact version used.
Turn accurate address data into accountable delivery
The practical goal is not a perfect universal format. It is a controlled chain in which recipients preserve their own address meaning, systems make limited and explainable checks, carriers decide service acceptance, and operators can recover without guessing. Start with the downloadable dataset, adapt it to your actual service and risk, test representative routes, and preserve the evidence behind every dispatch decision.
Giftpack can serve as the execution layer after eligibility, privacy, address, customs, and carrier decisions are made: it can help invite recipients, capture delivery choices, orchestrate fulfillment, and expose delivery states for reconciliation. It does not replace postal operators, carriers, customs advisers, privacy teams, or employer policy owners, and it should not be presented as guaranteeing that an address is legally sufficient or deliverable.