International Address Fields in Web Forms

By Luke Wroblewski

Published: June 9, 2008

“The basic structure of an address is so familiar, people don’t need the guidance labels provide.”

As enablers of online conversations between businesses and customers, Web forms are often responsible for gathering critical information—email addresses for continued communications, mailing addresses for product shipments, and billing information for payment processing to name just a few. So it shouldn’t come as much of a surprise that one of the most common questions I get asked about Web form design is: “How do I deal with international addresses?”

But before we get into the nuances of address variations, it’s worth pointing out that addresses have a commonly understood structure. Through years of experience with mailing and postal systems, people have a pretty concrete idea of what constitutes an address block. This common understanding is so definitive that eyetracking data suggests, once people begin filling in a set of input fields that make up an address, they often cease looking at their labels. The basic structure of an address is so familiar, people don’t need the guidance labels provide.

This is an important point to consider when laying out the input fields that make up an address. Figure 1 shows how to lay out the fields commonly included in an address in the United States. The alternative, a divided address structure in which each field appears on a separate line as shown in Figure 2, doesn’t offer the benefit of being understood as a set of related input fields. So people are more likely to consider each input field in relative isolation instead of looking at the address as a whole.

Figure 1—Common address structure for the United States in a Web form

Address structure for US

Figure 2—Divided address structure for the United States

Divided address structure

Luckily there is a fair amount of commonality between the elements that make up an address across the world. In most countries, the destination, or recipient, in an address structure progresses from most to least specific—Russia and Iran are notable exceptions. So when shipping to an individual at a corporation, the individual’s name would come first, then the corporation second. Following the destination is street address, city line, and lastly, the country line, as illustrated in Figure 3. This line structure is a pretty reliable baseline for all international addresses.

Figure 3—International address structure

International address structure

International Variations

“Though names and street addresses can have many variations, a single input field for each of them that provides an adequate amount of room for longer answers is usually all that’s necessary.”

International variations in address fields start with the most specific destination—the person to whom an address belongs. Individuals across the world might have one name, two names, three names, or more. A Formulate Information Design article, “The Name Riddle,” gives a great overview of the possible variations—from Sukarno, Indonesia’s first president, to Fahad bin Abdul Aziz bin Abdul Rahman Al-Sa'ud, the fifth king of Saudi Arabia.

Street addresses can also vary quite radically, even within a single country. The United States Postal Service’s Postal Addressing Standards outline variations in the United States—from 1401 Main St to RR 9 Box 23A to 475 Lanfant PLz SW, Rm 10022.

Though names and street addresses can have many variations, a single input field for each of them that provides an adequate amount of room for longer answers is usually all that’s necessary. Street number comes before street name? No problem. Street number comes after street name? Also, no problem. When it comes to the city line of an address block, however, we’re not as lucky.

In addition to a city name and postal code, the city line can also include a state, region, province, or county. Depending on the country, each of these can have different names, abbreviations, and locations in the address block. There is also a slew of postal code format variations across countries, including the use of spaces, numeric or alphabetic characters, and various lengths. The order of these elements also varies quite drastically. Figure 4 shows a few of the possible variations in the city line of an address block.

Figure 4—A sampling of city line variations

City line variations

To account for these international variations, Web form designers have taken a number of approaches: specific formats, changing formats, and generic formats.

Specific Formats

“The specific format approach works best when you know or can confidently infer a customer’s country.”

The specific format approach works best when you know or can confidently infer a customer’s country. Using this approach, you custom tailor the address block structure for each specific country. Figure 5 shows examples of address blocks for France and Italy. Note the variations in line placement and labels.

Figure 5—French and Italian address blocks

French and Italian address blocks

If you know a customer’s country with a high degree of certainty, the specific formats approach can provide a familiar address structure that supports quick comprehension and, thereby, fast form completion times. Frank da Cruz’s Compulsive Guide to Postal Addresses is a fantastic online resource for learning about unique address structures across the World, so you can deliver country-specific address block layouts.

Changing Formats

“A design that utilizes the changing format approach provides country-specific address blocks. However, the format is based on user selection.”

As with the specific format approach, a design that utilizes the changing format approach provides country-specific address blocks. However, the format is based on user selection instead of a known or inferred location. The registration form on eBay, shown in Figure 6, is an example of a form that utilizes a changing format. If someone changes the selected country from the default—which is based on the eBay site a user has accessed—the form displays the address block input fields the selected country requires in place of the address fields that are present by default.

Figure 6—eBay lets users’ selections change the address formats in its registration form

Users' selections change address formats

In this case, when someone selects Canada instead of Australia in the Country or region drop-down list, State/Territory changes to Province and Postcode changes to Postal Code. It’s important to note that, if a user has filled in any information in form fields that are common to both address structures—such as First name or Street address—you should preserve that information when changing countries. Removing information people have already provided is highly likely to upset customers.

Generic Formats

“The generic format lets you manage variations in name and street address by providing a single input field for each element of an address.”

The generic international address format offers an alternative to maintaining multiple address block variations to support country-specific solutions. The generic format lets you manage variations in name and street address by providing a single input field for each element of an address. To accommodate variations in the address block layout and city line, you can use a set of generic input fields. The form in Figure 7 does just that.

Figure 7—This address form from supports addresses from many countries through a generic format generic address format
“By distributing address elements across multiple lines, you can manage the ordering of postal codes, regions, and towns without implying any specific address structure.”

Instead of displaying different drop-down lists according to the selected country, a single input field with an all-inclusive label, State / Province / Region, lets users provide their state, province, or region. Likewise, the broad label ZIP/Postal Code—which could also have included Postcode—accounts for postal code variations in an input field that allows alphanumeric characters, spaces, and various lengths. By distributing address elements across multiple lines, you can manage the ordering of postal codes, regions, and towns without implying any specific address structure.

While this kind of generic format can provide a flexible set of input fields for international addresses, error checking may be harder, because several fields can have many valid formats. Also, by virtue of its flexibility, the generic format isn’t really optimized for any country or culture, so it’s likely to be functional, but not ideal.

I’ve covered considerations for several international address field design solutions, but there may be other options or issues out there. If you’ve got additional insights, I encourage you to speak up in the comments!

For more information about form design, check out Luke’s book—Web Form Design: Filling in the Blanks—a Rosenfeld Media publication that covers Web form usability, visual design, and interaction design considerations.

Editor’s note: Tony Meyn asked me to post these screen shots of an interesting design solution he found for international address forms. See his comment below.

Figure 1—Address in India

Address in India

Figure 2—Address in Canada

Address in Canada

Figure 3—Address in the United States

Address in the United States


You might want to have a look at the UPU international address standard work.

Wow, Luke, an excellent article. I really had not considered a lot of these issues to this level of internationalization. And, of course, it’s essential knowledge. Great stuff.

A couple of pleas from an international Web developer / Web browser:

1. Don’t make the postcode/ZIP a required field. Most countries just don’t have these codes, and if you make it mandatory, your visitor has to spend time guessing how many digits he has to stuff into the field to get past your validation routine.

2. Sensible use of IP address geolocation tools can help take the pain out of dealing with state and country fields. Do not wait for the user to pick a non-default country before deciding whether to offer a list of states. The post-back in the middle of filling out a form is confusing. (“Did I just accidentally post the form? Am I going to lose what I’ve already typed in?”)

This also disrupts the flow of data entry—if you spend time trying to figure out how to game the state field, only to have that field change once you change the country.

It is a real pain to scroll through a list of the US states, wondering if they have an item for Other or Non-US or International and guessing whether the list is in alphabetical order or if you’re going to have to scroll down to the bottom of the list to find it.

What are your thoughts about using a single textarea to encompass everything except the country? On our new site—yet to be launched—we adopted that approach, because our address requirements are for (1) billing address rather than delivery address and (2) contracts.

We came to this conclusion, because in light of the many differences between countries—most of which we knew little of—many fields ended up becoming optional to accommodate.

Nice to hear what you think.


Thanks for the insightful information provided above. This was very useful in building our product.

Regards, Harish

The Specific Format form seems the ideal way to go and determining the user’s country via a set of cascading rules that includes IP address detection seems reasonable. However, if you get their country wrong, then things seem to fall apart at that point. If I’ve filled out a form and the last thing I change is country and then the whole form changes, I’m going to find that disconcerting, even if my data is still there.

So is there a good way with high usability to allow users to select their country before filling out any of the form? Put the country first before displaying the rest of the form? Inquiring minds want to know!

I second the pleas from Strange Pants!

I think most sites—especially American sites—don’t realize how many international users there really might be on their site.

On the same kind of topic, it would be great to list very soon in any ordering process where you deliver. It’s a real pain to look all over, not find any info on delivery locations, fill out all the checkout forms only for a message to appear telling you “sorry, we don’t deliver anywhere except USA and Canada…”

I had to implement a form like this for my company—with a twist: phone numbers! We used a generic form with Country at the top and with an Ajax-populating list of regions depending on country. (It would disappear if we didn’t have regions for the chosen country, which I’m sure happened sometimes, but we had a lot—Chile, for example.) For the telephone number, we had a database of acceptable phone formats we could regex against, with the missing behavior to allow anything.

I think the most Google-esque thing to do would be a textarea with a crazy amount of parsing on the backend to separate it all out into fields. The downside is you lose auto-complete.

Nitpick: In the Italian example, it should be CAP, not CPA. See Wikipedia.

The biggest problem I would have with the examples shown is when the City field is made compulsory. Like a lot of other people, I don’t live in or near a city, so I leave that field blank, which then prevents me from submitting the form. Even putting the name of the nearest town in the city field often doesn’t work, because I get the error ‘Not a valid city’.

May I suggest that the field should be labeled City/town and that it shouldn’t be compulsory.

Great article. To add a little to Strange Pants theme… Be aware that enforcing adherence to US state name lists, ZIP code lists, and telephone number input masks will disenfranchise and frustrate the 95% of the world’s population to whom this information does not apply. This still happens way too often.

Good point “Strange Pants.” I hate that too: scrolling through US States looking for None or Other. It’s acceptable when that option is at the top, but when it’s included in the main A-Z list? Fail.

Preferably the drop-down list would disappear when a non-US country is selected.

Which brings me to my next point: Do we really need drop-down lists for everything? It might be good from a data validation point of view, but it’s virtually impossible to validate the entire address data, so why bother with just state and country. Is it faster to manually type in state/province and country? Well, it is for me. Or just clicking the drop-down list and pressing a 6 times to get Australia. :-)

As always, a great article, Luke. I was thinking there was a need for one on this topic—you just beat me to the punch. ;-) But more than just great writing, I think your solution is elegant and widely applicable.

I actually wanted to comment on Fahed’s question about a single address field. He and other readers might be interested to know that there was an interesting post and resulting discussion on Jeff Atwood’s Coding Horror site, in 2007, about why not have just one box.

It’s probably worth reading all the comments, but I can summarize that the main problem with a single box is that you may need parts of the address to go into different fields in a database, different parts of the organization, and so on. This isn’t impossible with a single box, but it is considerably more difficult, as it relies on how well you can parse the address.

The other big downside is you can’t make some parts of the address mandatory, and make sure that people don’t forget to enter key details. In Australia, for example, people often leave off the postcode if they don’t feel it’s needed.

Strange Pants: I think you are right, because the main reason is to make forms as easy as possible. So I like the idea of opening the IP regarding the country.

Fahed: The reason you separate the address is because you might use it in the future in mailing to your customer, so you will automate a printing job using mail merge or whatever program so you can print your letters easily.


I guess it should be mentioned that it is a good idea first to decide if a separation of fields is necessary at all. For the user—and the Programmer—it is easiest to have only one field.

Your generic format example, on the other side, doesn’t separate between family-name and the other potential parts of a name. In my experience, the most important thing is the possibility to search and sort by family-name later on. Consequently, this would be my first point of splitting.

Hi all, thanks for the great comments. To answer some of the questions.

Single textarea to encompass everything: The issues underlying this approach are listed out here: Web Forms: Death By a Thousand Textboxes.

“If I’ve filled out a form and the last thing I change is country and then the whole form changes.” As I mentioned in the article, the whole form does not need to change, only two fields: State / Province / Region and ZIP / Postal code / Postcode. If you look over the eBay registration example, you can see this is not that disorienting.

As a number of people pointed out, getting the right default country can come from IP address sniffing, but it is not 100% reliable.

City / town” is a good a way to mitigate issues where people may be concerned they don’t live in a city.

Drop-down lists for states should be avoided in my opinion. It is often easier for people to input a 2-letter abbreviation than select from a list of 50+ items. Not sure if that holds true for regions or provinces where there are no short abbreviations and spelling mistakes could be present?

Great article, Luke.

As an Australian living in a rural town, filling in forms on global Web sites is a pain point for me. Most of my experiences have been with US Web sites, so I’ll use them in my examples.

For example:

  • Default country set to United States. As others observed, this can alienate potential buyers. If IP sniffing can be used, it should be. In the absence of reliable IP sniffing, then why not Select a country as the default? If the Web site sells only to US citizens, then say so up front.
  • Inability to select a state, province, or region when you’ve selected a country other than the US. Even though some drop-down lists have Other for country, often designers and developers forget to add something similar to the list of states. So I select Australia as my country and then I can’t select a valid state. And without selecting a state, I cannot complete the form as they’ve made the state mandatory. Guess what I do? I leave the Web site and do not consider purchasing from there again. Lost sale.
  • Inability to recognize that other states in the world may use the same two letter codes. I live in Western Australia, commonly abbreviated to WA, which is also the abbreviation for Washington state in the US. Some selection lists only list the US state abbreviations, and I cannot choose WA. Otherwise my purchase will go to Washington state where it will get lost. So that’s another missed sale.
  • Insistence on City when people in your country refer to only really large metro area as city. Here, we live in towns or suburbs and refer to a city only when we’re being generic, not specific, about our address. If city is taken literally by users, I could see a lot of deliveries going astray—for example, to 1234 Main St, Perth, WA instead of 1234 Main St, Subiaco, Western Australia.
  • Not telling me up front whether they take international orders and ship to international addresses. Did I mention that I hate this? With so many sites, you have to go through the entire ordering process—sometimes many screens—only to find out that they don’t sell or ship overseas. Let me know right at the beginning. BTW, Expedia used to be really bad at this. You’d fill in all the forms and even enter your credit card number before they told you that they couldn’t take your booking! I think, in that case, they validated on a credit card number. If they saw that the credit card didn’t originate in the US, they wouldn’t complete the transaction. After a few bad experiences with Expedia and an obfuscating response from them some years ago, I’ve never tried to use them again. Of course, validation on a credit card to eliminate purchasers seems to be a bad idea. Perhaps there’s a legitimate reason for it, but I can’t see it.
  • Assumption that my country’s phone number matches the originating Web site’s phone number pattern. Some forms have validations on the number of characters entered, others don’t allow ( ), and even more don’t allow international phone number designations such as +61 x xxxx xxxx. You get an Invalid phone number or Invalid character message because you put in the plus sign.
  • Allowing me to enter all my details before telling me that only people with a US street address can purchase. Adobe was notorious for this. (I haven’t try to buy anything from them for a while as my experiences were so bad.) I wanted to download an upgrade, so I filled in all the details, then they said I had to enter a US street address before I could download the software. They offered to take me to their partner sites in Australia, but these were just links to non-Adobe sites where I couldn’t find what I was looking for. (None of my purchase details carried across to the reseller’s site—another issue.) Fortunately, I have relatives in the US, so used one of their addresses. I could then download their software. But I was very angry. I’ve since found that there’s a service based in Singapore that provides Australians with a US address for such situations, and the goods are then sent on from there. (See my December 2007 newsletter for details.)
  • (And yes, I’m the Rhonda you sat next to at lunch at the WritersUA conference in March. You can see I get passionate about this stuff!)

Well, perhaps the decision of using drop-down lists to ensure valid data or whether to allow free text—which can be faster—could be based on what the address is.

If it’s for a user’s own residential address, then hopefully they should know how to spell the name of their own suburb, city, and province.

However if it’s for a mailing address—especially where the mailing address is likely to be different from the user’s own address as on a gift site—then you might want to have the drop-down lists.

Canada has provinces and territories, a fact it seems impossible to explain to Americans, even Americans who claim expertise in internationalization. The “correct” Canadian form you display here is, in fact, incorrect.

Same thing in Australia, Joe—states and territories. But here in the Australian Capital Territory, we’re okay with being a “State”. Heck, we’re even happy when lumped in with the surrounding state that land-locks us, NSW, as NSW/ACT—although, occasionally, we don’t even get a mention and just have to settle for being part of NSW.

We don’t feel particularly loved, though, when Australia isn’t in a country selection drop-down list’s popular countries quick list at the top, alongside the US, Canada, and the UK, but instead have to go and scrounge around amongst Afghanistan and Albania :-)

Joe, I want to follow up on your statement that this mailing address format is incorrect for Canada. If you look over the Canadian postal service’s overview of mailing addresses in Canada:

The province should always be presented, using the recognized two-letter symbol. See Table 4: Canadian Provinces and Territories Names and Abbreviations for a complete list. Mailers may wish to have the province written in full and placed in parentheses. For example: (Quebec)

The province and/or territory are covered by the input fields in Figure 6. Are you instead pointing out that the drop-down menu should be titled: Select Province/Territory?

We haven’t encountered this being a point of confusion for users when we supply this list in the menu.

Great article, great comments.

My pet hate is forms that require state / province / region. In the Netherlands, the country is the state, and while we do have provinces, they play no role at all in postal addressing. So then I have to game the form—try a space, try a dash, try N/A, in that order.

In fact, a completely qualified postal address here consists of postal code plus street number. Street name and city/town are redundant—that is, already encoded in the postal code.

My second pet hate is not explaining what format something is expected in. Do I need to enter a space or not in the postal code. (Officially, it’s needed, but many sites don’t want to see it. Why can’t they throw it away themselves?) What format do you want for a phone number? Don’t let me try all the international variations. If you know my country, do you also need the country number for the phone number or should I leave it off? Should I enter a plus for international dialing? Don’t keep me guessing and say something’s wrong. But if you are going to say it’s wrong—too late—at least tell me what’s “right”.

Don’t ask me for first name, middle initial, and last name when the name I use is my middle name. Don’t ask for first name and last name for a credit card when what I have on there is first initial, middle name, and last name. Just Name on card will do—and always work.

And when it comes to names: Some names don’t have a middle initial, because a name consists of three full parts, as is the case in many Asian countries. In some cultures, people don’t have a last name, but instead, have only a single name—as in some other Asian cultures. How are you going to split a name that consists of one part? I think the best solution really is to have just a single Full name field and split it on the back end when you must, and there actually is something to split.

How does Google do it with their Google Maps? It seems to be able to parse anything thrown at it.

Love ya, Luke, but I think I learned more from the comments on this article than the article itself!

Stacia, hence the last line of my article: “I’ve covered considerations for several international address field design solutions, but there may be other options or issues out there. If you’ve got additional insights, I encourage you to speak up in the comments!”

Who better to speak up on the nuances of international addresses than people across the world?

It’s worth pointing out that the labels to the left of the fields—as in the Amazon example—are better for accessibility reasons than placing them atop the fields in tables.

Good luck trying to avoid drop-down menus for US states, if the majority of your visitors are in the US like for my site. Since the vast majority of sites have these, people are used to them, and the last thing they want is to type it. Try explaining to your non-IT bosses that they shouldn’t get what they want when 95% of sites have it, and you will be looking for another job soon! :-)

Tom Schneider wrote:

“It’s worth pointing out that the labels to the left of the fields—as in the Amazon example—are better for accessibility reasons than placing them atop the fields in tables.

You’re probably thinking of WCAG 1.0 Guideline 10.2, which states—my emphasis:

10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.

However, do not forget that WCAG 1.0 dates from 1999—that’s more than a generation in Internet time. The “until user agents” criterion has been met by now, so this positioning is no longer needed. User agents do properly associate labels with form elements—provided they are properly marked up, of course. In fact, in WCAG 2.0—a candidate recommendation, only one step away from a full standard—there is no such guideline any more—see this handy comparison (PDF). There is a technique though: H44: Using label elements to associate text labels with form controls, which outlines a number of possible approaches to identifying form controls and outlines what user agents are capable of. Positioning is not a part of these techniques—and techniques are informative, not normative.

In conclusion, as long as you properly mark up your labels so they are explicitly or implicitly associated with the form controls they relate to, how they are visually positioned relative to each other doesn’t really matter. Style as you like visualy for usability. Having labels above fields can, in fact, be excellent when several related fields are presented horizontally, because their corresponding data elements are normally written in a single line, and there is no accessibility penalty here at all.

What about:

Full name: [field]

Address line 1: [field]

Address line 2: [field]

City/Town: [field]

Country: [Default country] - [United States] - Select Country [in an alphabetical drop-down list]

State/Province/Region: [field]

ZIP/Postal Code: [field]


  • If this is for shipping internationally, tell users before if you ship only in your country
  • Full name divided into LastName, FirstName, and so on
  • In the Country drop-down list, display: [Default] country name United States —————————— Alphabetical list of countries


  • Populate and validate based on country address rules
  • For State: Cannot make mandatory for some countries.
  • For ZIP: Cannot make mandatory for some countries.

There is so much international posting nowadays, that the generic format should be used. It is important that each field has enough space to type in information made compulsory by any peculiarities of the address standards of individual countries.

Hey, Luke—You have a Slavic name. Did you know about it? An English translation is Sparrows. By the way, very good article!

Tom Schneider, I’m not an accessibility expert, but from my understanding, top-aligned labels provide the most direct accessibility, because they follow a direct flow of label / input in sequential order. There is no separation of these elements in markup to achieve a left-aligned layout using tables or CSS. Also, users who rely on screen magnifiers need the labels butted up close to the fields. Top-aligned labels support this best.

More about the pros and cons of label alignments: Top, Right or Left-Aligned Form Labels

And a whole chapter in my book: Web Form Design: Filling in the Blanks

mins, drop-down menus require the most dexterity to manipulate: move mouse to trigger, hold down, scroll list to find selection, release exactly on selection. Typing two letters is much easier and obvious, in terms of usability. Just because lots of people are doing things does not make them inherently easier!


Regarding the drop-down list for state / province /etc., the problem I have seen is that, when a drop-down list is not used, people in the U.S. actually will mistype their two-letter abbreviation—or they will abbreviate it some other way or spell the whole thing out. In fact, I have seen people mistype their names and, once they receive their email confirmation, they realize it and email us back to spell their names correctly. I don’t understand why, in the U.S., city and state are needed, since the ZIP code provides the post office all of that information, but the post office requires the two-character state abbreviation.

I would love to see some sort of plug-in that we could all use that first requests the country name, then bases the fields upon that selection, but instead we all have to come up with a hodge podge of solutions.

Johnny, Hence the inclusion of ZIP code and city/state. Many users enter one of the components wrong. This is why the post office hasn’t eliminated the redundancy on the envelope. It’s not unusual for someone to get a digit wrong in the ZIP or to get the name of the town or state wrong. (People regularly confuse MS and MA or MA and MD, for example.)

By having both the ZIP & the city/state, both the system—with a decent address verification system—and the post office can do error correction.

Great discussion, folks. I�m particularly gratified to hear perspectives from a variety of countries.

RE: The single address input area

Has anyone encountered any information, discussions, or conclusions regarding combining Address Line 1 and Address Line 2 into a single text area? I have even read articles that subscribe to 3 address lines for localization purposes, because the claim was that some countries use 3 lines, at least in some cases. Although I agree that one text area for the entire address presents a variety of potential problems, perhaps a single dwelling address text area makes sense, particularly if one is using the generic address format. The label of this field would need to be discussed. Perhaps, for English versions, just Address, although not precisely accurate, is sufficient, although it�s no less accurate than Address Line X.

Also, in the Amazon example, they provide hints below Address Line 1 and Address Line 2, such as Street address, c/o, and Suite. I believe these hints are helpful; however, if the customer had the need for all 3 of these, more lines makes sense. Here�s an example:

c/o June Harrison 123 Pine Lane Suite 456

What if 4 of these items are needed, such as in this example?

ABC Corporation c/o June Harrison 123 Pine Lane Suite 456

If a single text area were used for this portion of the overall address, it scales to all these cases.

In terms of server-side parsing, this design doesn�t present more problems than separate Address Line 1, Address Line 2, Address 3, and so on, text fields, except, perhaps, for the handling of newline and carriage return characters.

Generally speaking, I�m not a fan of text areas, except for free-form text such as notes and comments, but I think they might have a reasonable use here.


If I live somewhere and order something online that needs to be shipped, why doesn’t the Web site trust me that I know what my address looks like? I hate it if it tells me in bold, red type that whatever I wrote as my address is wrong.

Excuse me, I’ve ordered things before, and they usually teach you in primary school how addresses work in your place, so if I leave the state/province field blank, maybe that is because it is unimportant wherever I live? If I don’t provide a street number, that is maybe because there is none? If my postal code has letters in it, why reject it? Yes, it might indeed have letters and spaces in it. If I want to add an apartment number or another specification such as Hinterhaus—German for house behind the house, sometimes found in large cities—maybe that is because I know from experience that, this way, the deliveryman will be able to find my place more easily?

Maybe I want to add a proximity thing, as some countries don’t really have addresses? For example, I used to live at the house of the father of so and so, next to this and that mosque, around the corner of that well known hotel, in a certain quarter, in a town without a postal code. Additionally, I wanted to include my telephone number on the address label, because sometimes they were too lazy to deliver—or still couldn’t find it—but just called and told you to pick it up. Always worked, albeit sometimes in mysterious ways.

Now to make it even more tricky: Maybe I want to include a non-Latin script—say Arabic or Japanese—because I know that my Syrian or Tokyo deliveryman isn’t too firm with English? As long as the country is in Latin script, this works just fine.

I might want to leave instructions such as: “If I’m not home, simply put the package behind the shed.” In some locations, this works, is usual practice, and prevents you from chasing your package in some post office miles away.

Okay, here’s my dilemma. I’m designing Web software that is used to enter information from a lease or some other document. Inside our application, we group these documents by country, state/region, city. Most of the time, the information is entered by those in charge of the documents and is entered directly from the documents themselves, which usually have the native format for addresses. What does everybody suggest for the best layout of the entry form? Currently our entry form looks American, but we are now expanding internationally, so it needs to be modified to handle any address.

Current setup: [address line 1] - required [address line 2] - optional [city][state][zip] - all 3 required and the state field is a dropdown [country] - required [county/province] - optional (I’m not even sure what it is used for or if it is needed.)

Again, the address is used to group documents in a tree format by country, state, city or country, city, since it appears as if state/province/region is not always required.

I’m currently working on a Web application that groups documents by country/state/city. What are some recommendations for setting up the entry form?

The majority of the documents are based in the US, but we are expanding internationally. Does it make the most sense to go with the generic layout above?

The potential issues I see with the generic layout are errors typing in the data and thus being grouped improperly.

Does anybody know of a reliable service that we could perhaps subscribe to that lists all countries, states, provinces, regions, territories, and so on?

It appears that most of this discussion assumes Latin script. Does anyone have thoughts or suggestions on creating address entry forms for Latin versus non-Latin scripts? Is this covered in some other article or discussion?

Just as Australia has states and territories and Canada has provinces and territories, the United States has states, districts, commonwealths, and territories.

In some countries, the numeric portion of the address might be null. In some countries, it might be multiple numbers separated by dashes or slashes or some dashes and some slashes.

In some countries, the street name might be null. In some countries, the street name might be followed by a more important street name. In some countries, there might be two street names of equal importance.

In some countries, the city might be null—or sometimes null. In some countries, the village name might be followed by a major city name, except when the village name really is already a major city. In some countries, the ward name might be followed by the city name or the ward name might be followed by the prefecture name, because the city is null, depending on which prefecture and which ward.

In some countries, the state / province / territory / prefecture name might be null—or might be optionally null if the city is famous enough—but had better be included if the city isn’t famous enough. You got Japan wrong this way.

Addresses are big endian not only in Russia and Iran, which you mentioned. In China, Japan, and some other countries, the normal mode of addressing is big endian. Little endian is used only when writing in Latin letters.

Your article was very useful to me. I was dealing with the same problem. While you’ve considered general form design, that don’t handle the particularities of any country. You’ve forgotten to consider that county is commonly used in England and, in countries like New Zealand, they use islands. In England, there’s city, county, and country. I hope this information can be useful.

Alexandre, take a look at figures 4 and 6. County is part of the equation!

We all agree that each country has its unique address structure, a solution in the uasability would be to choose your country, then based on the selection, be asked the right questions to get vaild addresses.

Well, this involves a tricky database design. Has such an approch ever been implemented?

I was trying to get more light on the database design for such a solution, when I came across a link to an article on Experts Exchange: Database Design for Contacts & Addresses.

It seems they want me to pay for the solution anyone here can discuss for free.

I wonder whether, for sites that have multilingual support, maybe the correct entry point for determining the address block format would be on the main page, where the user would select which language they would like to see the site displayed in. You could set your defaults from that, then still allow the option to change via the country drop-down list in the address block. I’ve seen several people comment about putting the country drop-down list first, and that would seem reasonable, but I cannot say I’ve ever seen it done that way. I wonder if it’s been tried and it turned out that people just skip over it anyway. Perhaps a progressive disclosure mode would be better, where you have to select your country before you are allowed to enter your address.

Luke and all,

Thank you for excellent information!

So, if I understand correctly, it is not common with a drop-down selection to present correct address fields? Did I miss something?

My suggestion in a project is to have a default country in drop down. If another country is selected, present the fields suitable for that country (a few other countries) and at last a generic presentation of fields for the selection “others” (country). Would that be new???

Thanks, Luke and all, for this useful discussion.

There has been a lot of talk about inputs here, but not so much about the end purpose and outputs. I would think the most common output for address information is mailing addresses—that is, mail merges. The truth is you can build a generic international address input form fairly easily, but then spend weeks writing the rules for pushing that data into the respective address format for each country, as described in “Frank’s Compulsive Guide to Postal Addresses.”

Any suggestions on an overall process solution for international address input to output?

Great post.

One note: Your example form for France includes a drop-down for R�gion. That doesn’t appear to be a required field for French addresses—according to both Frank’s list and PayPal.

Including it might be nice for French users, or it might strike them as odd, because they don’t usually need to provide such info.

It’s solved. I saw an amazing solution on this Web site for capturing addresses.

The form captures addresses in a fascinating way. It asks for your address based on your country, then it lets you select the address details. So you just have to select rather than type. You can see some screen shots above that show the form for three different countries.

Please let me know if anyone knows a better form for the same purpose.

Graham Rhind has a free, online ebook that discusses this challenging topic: “Better Data Quality from Your Web Form: Effective International Name and Address Internet Data Collection.”

There’s one further point that you need to consider—just to make life a bit more complicated. The postal authority’s view of an address may not be the same as the address preferred by users. For example, users may know it helps to include extra information in the address for the delivery person. Or users may have a strong political objection to the official name for part of the address.

And a bit of address geekery: in the UK, County is liked by many users, but is deprecated by the Post Office.

I have studied international addressing and data collection for 15 years, and Caroline Jarrett kindly mentioned my free e-Book exactly about this topic: “Better Data Quality from Your Web Form: Effective International Name and Address Internet Data Collection,,” which you can download free—without having to fill in a form!!

I shall forebear to comment on most aspects of the article or the responses, as you can get my opinions in my e-Book; but Luke, you are absolutely wrong when you say: “the whole form does not need to change, only two fields: State / Province / Region and ZIP / Postal code / Postcode.” There are currently around 130 address formats used in the world, and that’s not just due to those two fields! How you order the form must depend on how you are collecting the data, of course, but if you collect the building number separately from the thoroughfare name, you’re looking at 50 formats, as against 36 formats if you don’t. Add to that mailing address formats—for example, post office boxes, and in many areas of the world this is the only available delivery option, as there are no street addresses—you can add a further 46 formats.

You’re assuming that addresses “have a commonly understood structure,” but this is not universally the case. The only real solution is to ask the country—and language—first and base the form design on these answers. It’s the only way to get good-quality data from the form.

This information, including form layouts by country, is all contained in The Global Sourcebook for Address Data Management—not free, but hey, I have to earn a crust somehow! :-)

Join the Discussion

Asterisks (*) indicate required information.