Skip to content

Formatting an Address Correctly for a Given Country

9 min read · updated August 11, 2026

An address is not a set of fields that different countries print in a different order. Some of the fields do not exist in some countries, one country reverses the whole sequence, and the difference between 12 Hauptstraße and Hauptstraße 12 is not cosmetic.

The default the model applies

Asked to write an address for anywhere, a model produces something with this shape: recipient, then street number and street name, then city, then a region abbreviation, then a postal code, then the country. That is the US format, and it is the default for the same reason discussed in date format confusion — the mass of addresses in an English-language corpus are American, so the prior is American.

What makes address formatting harder than dates is that it is not one decision. It is a field order, a set of which fields are present, a per-line composition rule, and a capitalisation convention, and a model can get three of those right and still produce something that a postal sorting machine will reject or that a human will read as obviously foreign. The examples below are chosen because each breaks a different one of those assumptions.

United States

Jane Doe
1600 Amphitheatre Parkway
Mountain View, CA 94043
UNITED STATES

The properties worth naming, because two of them are unusual rather than default. The house number precedes the street name. The state is a two-letter USPS abbreviation and it is required, because city names are not unique across states — there are Springfields in more than half the states. City, state and ZIP share one line, with a comma after the city and no comma before the ZIP. The ZIP is five digits, optionally extended to 94043-1351.

The US Postal Service’s own preference, published in its addressing standards, is for the whole address in uppercase with no punctuation, because that is what its optical readers were specified against. That is a machine-readability preference rather than a correctness requirement, and mixed case is universally accepted; it is worth knowing only because an address rendered that way in a source document is not a formatting error to be corrected.

Japan

Japanese addresses run from largest unit to smallest, which is the reverse of the Western sequence, and the last element is therefore the recipient rather than the first. Written in Japanese:

〒100-8994
東京都中央区八重洲一丁目5番3号
山田太郎 様

Read outward-in: the postal code marked by the 〒 symbol; then Tōkyō-to (the metropolis), Chūō-ku (the ward), the district name, and then a numeric triple. That triple is the part with no Western equivalent and it is where generated addresses fail. It is not a street number, because most Japanese streets have no names. It is chōme — a district subdivision — then banchi, a block within it, then , a building within the block. Written numerically it collapses to 1-5-3. There is no street name in the address because there is no street name in the addressing system.

Romanised for international mail, the order conventionally inverts to smallest-first so that foreign postal systems can route it, giving something like:

Taro Yamada
1-5-3 Yaesu, Chuo-ku
Tokyo 100-8994
JAPAN

Both forms are correct for their purpose, and a model will frequently produce a hybrid: Japanese-language components in Western order, or a romanised address that keeps the largest-first sequence. Either is wrong in a way that is obvious to a Japanese reader and invisible to the person who generated it. Note also the honorific 様 (sama) after the name in the Japanese form, which is part of correctly addressing an envelope — see honorifics and titles.

Germany

Frau Anna Schmidt
Hauptstraße 12
10115 Berlin
GERMANY

Two divergences, both small and both reliably wrong in generated output. First, the house number follows the street name, not the other way round — Hauptstraße 12, never 12 Hauptstraße. Second, the postal code precedes the city on the same line, with a space and no comma: 10115 Berlin. The German postal code is five digits and leading zeros are significant, so Dresden’s 01067 must be stored as a string; parsed as an integer it becomes 1067 and stops being a postal code, which is a real and common data bug rather than a theoretical one.

Germany has no region field in a postal address. The Bundesland is not written, because the postal code determines the destination unambiguously. A generated German address containing a state line is not merely unidiomatic; it has a field that does not belong to the format at all, which is the clearest possible signal that a US template was filled in with German values.

Also note that -straße is commonly abbreviated to -str. and that the ß may appear as ss in some datasets — the normalisation question covered in German umlaut and eszett normalisation. For matching an address against a database, that decision has to be made deliberately and applied on both sides.

A field model that survives all three

The lesson from those three is that you cannot store an address as a US-shaped record and re-order it at render time, because Japan has no street name and Germany has no state. The working approach, and the one used by the address metadata that browsers and checkout forms are built on, is a small set of generic field slots plus a per-country format string that says which slots are used, in what order, and on which lines. Google’s libaddressinput publishes exactly that dataset, and the Universal Postal Union publishes its members’ official postal addressing systems.

  1. Extract or generate the components separately — recipient, street or equivalent, dependent locality, locality, administrative area, postal code, country — and never as a formatted blob.
  2. Look up the country’s format string. It tells you which slots are required, which are absent, and the line layout.
  3. Render by substituting into that format string in code. This is the step that must not be done by the model.
  4. Validate the postal code against the country’s pattern before you accept it, remembering that some countries have no postal code at all — see postal code validation by country.

If you must have a model produce a formatted address — for a document it is drafting, say — give it the target country’s format explicitly as a worked example in the prompt rather than naming the country and hoping. One correct example of the destination format is worth more than any amount of instruction, because it pins the field order, the punctuation and the line breaks in a single unambiguous artefact.