I am building a ecommerce checkout flow and am looking for best practices for the billing/shipping entries. Every site I use and every one I've looked at for inspiration has the address entries as a separate field for each part of the address. I don't understand why I don't see any sites that allow the user to enter their address in a single free-form textarea box? I'd imagine a single textarea would be much quicker and simpler to use.

I'm seriously considering using the single textarea for my checkout flow but a concern is that it will be different to the common multi-box approach and possibly confuse the customer or at the very least make them stop and think?

  • A lot of them are the way they are because of back-end restictions - they need to parse the correct elements of the addresses into the correct fields in the database. As a result that does impact the UX side of things.
    – JonW
    Nov 4, 2014 at 13:44
  • Thanks Jon, I have no such restrictions on the server-side, in fact, if I did make it separate fields then I'd end up joining them into one field in the DB anyway. Nov 4, 2014 at 13:46
  • 3
    Believe it or not, but after selling a big part of private ballast on a popular selling platform, I came to realise that a lot of ppl are not even capable of writing their address correctly. Some write their name all-uppercase, just to write the remainder of the address all lower-case. Some flip the order of City and Street, some skip the Postal Code. And allmost noone gets their hyphens correctly. That being said: You can trust your shipping companies to account for user errors correctly, because they often have decades of experience on this.
    – phresnel
    Nov 4, 2014 at 16:22
  • @phresnel One wonders why such experience would not have resulted in reliable algorithms for address parsing being made available to the public, implemented in standard libraries.
    – Crissov
    Nov 4, 2014 at 20:09
  • @Crissov Knowledge is powerful, and valuable. The shipping companies would simply say "Pay up"
    – MonkeyZeus
    Nov 4, 2014 at 20:40

4 Answers 4


TL;DR: Use a single text field, store as a single string, show an address label preview.

Separate fields have served limited purpose, such as safely identifying the country, town or zip code area someone lives in. They also allowed to enforce some constraints, such as providing a fixed list of countries. They also - in theory - allowed to "reduce the number of changes made" if a customer record changes. On the more esoteric end, it could help determining left side of the road from right side, by looking at even / odd numbers1.

This is wrong today for two reasons:

  • The world
    for reference, see "Falsehoods programmers believe about adresses"2)

  • Google
    Online map services do a continuously better job at understanding a plaintext address, and can answer all the queries you might want to (such as which country, which town, which is our closest delivery center factoring in typical thursday afternoon traffic conditions)

Note that these are actually two issues:

  • Should data entry offer a single multiline field, or multiple fields?
  • Shoud the backend store address as a single field, or as multiple fields?

However, I'd argue both benefit or at least are not harmed by a single field.


One perceived benefit of multi-field is validation.
Indeed it may protect you against missing significant parts (Chechov's "Wanka" comes to mind). Yet with all the adressing schemes out there, only a human can decide whether any part of the address has meaning individually. For automated processing, address has significance only as a whole.

In my contrieved opinion, showing an address label preview with the usual formating, style and background ("this is how we would address a package to you. Does this look right?") should be enough to prime users to verify the address is correct.

Another option would be using an online map service to show the location you understand from the address entered.

Single field advantages

A single field looks more approachable than half-a-dozen individual fields. Multi-field might border indimidating if you want to cover all possibilities (Now what do I enter in building extension?)

While "address" is rarely requested in first signup, the appearance of a complex form may affect conversion and finish rates.

Input can be expected to be faster, as many users still switch between mouse and keyboard when selecting a new field (casual observation).

A single field allows copy & paste of the address as a whole for advanced users.

@phresnel brings up common errors in data entry, that are usually corrected by the delivery company - further making quesitonable the quality of the data entered.

On the backend, a single field reduces complexity, even if marginal. Moreover, it drives home the point that the address should be handled as a whole, should be considered opaque unless you really do know what you are doing.

Slowing down overzealous developers from attempting validation that almost always will turn out incorrect might be considered a tangible benefit, too.


We did have good reasons for separate fields. Early automated processing tools might expect fixed locations for certain fields. We did not have powerful and easily accessible "address to location" conversions, and had to rely on individual field when querying e.g. for sales by country.

Good reasons for multi-field:

You might not have access to internet servives, you might need to be compatible with restrictive processing equipment, your users might rely on aut-form-fill tools that have problems with single-field-adresses. You might be catious and and want to be prepared for a future need of separate fields.

1) this actually was suggested to me some 15 years ago as a good reason why a street number should be a separate field. I don't know if this ever had practical use.

2) While you are at it, also see the equally excellent "Falsehoods ... about names". The conclusions from that would be even further reaching.

  • Thank you for addressing the falsehoods - those cannot be stressed enough! Nov 4, 2014 at 15:15
  • Interestingly, even though this obviously started as a pretty UK-centric list, that part already destroys any multi-field form of sane size.
    – peterchen
    Nov 4, 2014 at 15:29
  • Thanks peterchen, this backs up my feeling that the multi-field entry didn't make sense and the ideas of showing a label or interactive map are both superb. Nov 4, 2014 at 15:39
  • Do you know of any existing websites that are using these methods? Nov 4, 2014 at 15:39
  • 1
    If you're looking at examples for this; I have a similar thing: My bank offers a text field besides the form when I create a bank transfer. So I can paste the information from an email, and hit the "Parse" button (well, not actually labelled such) to let the system try to understand it. It's not good at filling in the reason for payment, though... Nov 5, 2014 at 9:44

This is an interesting question. Thanks for asking.

I had the exact same idea last year, and after some research and even an A/B test, I chose to stick with the field-set approach. This is based on my own experience with an online shop that actually ships fashion items. So this is about shipping address; not the billing address.

  1. Users who place online orders are used to the address formats. They know street address 2 field is usually not a required field, and they can use their UK 6-char alpha numeric postal code even if the US "ZIP code" field with space for 5 digit input field. Giving them a text area can sometimes confuse them whether they should write precise instructions or just their city name. Large text areas can sometimes lead to significant conversion losses.

  2. In a developer point of view, it's not hard to give a country-specific address field (set). See the xNAL standard. We put the country select list on the top (with geoIP resolving and some guess work), and create a precise address field below the country field. Most of our customers filled the form correctly, and our reports and delivery work is much easier. You could figure out the exact city, state and other information using Google Maps API or such reverse geocoding service, but that's extra work and accuracy is not guaranteed.

  3. Browser autocompletion. Just double click the "City" free text box next time you see an address field. Chances are, your browser has history for that field so you can quickly select it. Now double click a text area: No autocomplete suggestions. Safari and some others (probably with addons) can store the addresses in a structural format.

  4. Correct tab navigation. Following the xNAL, we have correct tab navigation to allow advanced (?) users to jump to the next address field. Street, city, state, and then postal code.

  5. Verification purposes: If you can't ship to some area, you can instantly verify the address input upon submission. Besides, IMO, users would feel you are serious about shipping when they see an address field-set.


From a UX standpoint, the most important question is whether the user's presaved "auto-fill" will fill in your form. You really need to check whether your single text area will work with such features. If it won't, you've potentially lost a user/customer/petition-signer/whatever. Especially with the prevalence of phone/tablet based users, entering an address manually is a huge hassle, and I've quite often rethought my choice to buy/sign/whatever and just hit the back button when auto-fill doesn't work.

  • 2
    You may be able to hide these form fields and use JavaScript to copy their content into a text field.
    – Keavon
    Nov 5, 2014 at 1:04
  • This caveat is really bipartite: 1. Does address autofill work for single-field addresses when such have never been encountered before? 2. Does it work after having entered the full address manually once? Although Yes-Yes would be ideal, No-Yes may be acceptable.
    – Crissov
    Nov 6, 2014 at 10:49
  • @Crissov: The Android auto-fill (at least in versions I've used) for addresses is not based on entering it once on a site, but configuring an address in your settings that you later use. Nov 6, 2014 at 16:22

I'd imagine address separation boils down to the following:

  • Backend storage, useful for a variety of reasons like reporting
  • Validation of individual elements of the address to ensure correctness (without, imagine the parsing you would have to do)
  • Label printing

The last thing you want is someone's credit card information on file, processed, with no way to ship them their product. This alone may be a reason to separate the fields - so shipping and billing match.

Also note that many forms now can be built to leverage some form of auto complete, so your proposed approach would likely not trigger any of this form auto-completion, which would be a detriment to your users' experience. That, and as you said, the out-of-left-field nature of your practice, may make a shopper look elsewhere.

Not the answer you're looking for? Browse other questions tagged or ask your own question.