Why You Should Use a Text Area for Address Form Fields

Have you ever filled out a form and froze on the address field? A research study found that users come to a confusing stop when they encounter the “address line 2” field.


Not only that, but the second address field also caused them to split their input incorrectly in the address fields. This led to confusion and frustration among users.

Labeling the second address field “Apartment/Suite/Other” did not resolve the issue. Users still came to a confusing stop and wondered whether the field was relevant for them.

Familiarity Principle

Having two address fields violates the principle of Familiarity that states the system should match the user’s real world expectations. When there’s a match, users can interpret the interface based on conventions they’re already familiar with.

The second address field forces the user to type their address in the system’s preferred format, not the user’s. In the real world, users think of addresses as a single entity. Two text fields causes them to perceive their address as separate entities. Users don’t expect to see this which is why they get confused.

Use a Text Area

By using a single text area instead of two text fields, you’ll help users fill out the address field quicker. This allows them to think about their address as a single entity instead of two separate entities when they see the field.

Text areas allow users to press ‘enter’ to skip to a new line so they can type their address in the real world format they’re used to seeing. Text areas also don’t limit addresses to two lines, allowing it to support international formats.

City, State and Zip Code

Use separate fields for city, state and zip code because these input need to be parsed to ensure a unique geographic location. There’s a tool called Parserator that allow you to parse an entire address from a text area, but it doesn’t have perfect accuracy and only works for U.S. addresses. It’s a novel solution worth trying and testing if you have the time.

Real World Expectations

It’s important to design your form based on the user’s real world expectations. If you force users to rethink conventions in order to match the system, you’ll confuse and frustrate them. Don’t force the user to follow the system, force the system to follow the user.

UI Design Kit


elegant wordpress themes

This Post Has 18 Comments

  1. Mike Earley Reply

    This is an interesting split between data sanity and real world expectations. The burden here is on the system to recognize, or be able to parse, the more useful and less useful address information here. For example, map coordinates do not care about apartment 312, or suite 301a, and this additional information may prevent them or limit them in finding the legitimate address. But to the user, that information is absolutely critical and necessary to finding them correctly. If the user types the information in reverse, i.e. Suite 912a, 100 Commerce St, the logic on the system is even greater, as the system not only has to correctly parse the separation but also interpret correctly which is the street address.
    Meeting real world expectations in this case expects that the user will input data to meet system expectations, or that the data the user inputs is easily parsable into system sane data.
    So, allowing for the scenario above, the user can potentially enter:
    100 Commerce St.
    Suite 912a
    || or ||
    Suite 912a 100 Commerce St.
    || or ||
    100 Commerce St. Suite 912a
    || or ||
    Suite 912a
    100 Commerce St.

    Add to this the fact that, last time I was in a business supporting address fields, the 2nd line of street address information was considered ‘informational’ and ‘not necessary to print’ on an envelope for successful delivery. At the time we were advising consumers to include necessary delivery information on the 1st address line so it wouldn’t get lost.
    All this to say, I don’t know the right answer, but this isn’t simply a problem of “the customer is always right”.

    • anthony Reply

      Typing the input in the correct order applies to any other field not just addresses. Saying users might type the suite number before the street address is like saying users might type the area code last in a phone number. Most know what the common convention is.

      There’s no reason for the system to parse the suite/apartment number. The suite/apartment number alone is unusable without the street address.

      • Dean Reply

        As an Australian, I would type the suite first.

        Sometimes it can be difficult to know how *all* of your users will complete a form – especially when they have the freedom of a textarea. That’s why I think a textarea is a bad way to handle addresses.

        Why not just provide a clearly-labelled individual input for each of the necessary fields? And hide the usually-unnecessary fields (eg: 2nd line of street address) behind a link which will be found by those who need it. For example, the anchor text could say, ‘Need a 2nd line?’ just below the first line. This will be easily discovered & understood by the people who need it, but it won’t confuse the people who don’t need it. And the data you receive will generally be much easier to work with.

  2. Jshell Reply

    What about the city, state, zip?

    If I saw a single TextArea for address, I’d naturally type in my city, state and zip.

  3. Jens Grochtdreis Reply

    This may be correct in the USA but in most cities of Germany it would be no point. The only exception may be Berlin. Same is with “First Name” and “Second First Name” which may be a thing in the US but not outside. And there is an outside world, you know? 🙂

    • Derek Watson Reply

      I just had to comment… born and raised in the US but I’ve never heard of a “Second First Name.” Have I been missing part of my name my entire life?

      I do agree with what you’re getting at here, though.

  4. George Leonardo Reply

    Interesting approach. I imagine in this case the “Address” would be just for street / number / complement, right? So would you first ask the other data like country and city? I’ve seen users getting confusing with the label “Address” and inputting everything there and only seeing the other fields after, but maybe a placeholder would be enough in this case. I’ll definitely user test this thing. Thanks for sharing!

    • anthony Reply

      City, state and zip need to be separate fields. If you place those fields before the address text area, users will fill them out first and won’t make that mistake.

      • Stefan Vermeulen Reply

        It’s an interesting approach.

        My immediate reaction was: “this will hurt my data quality”. Then again: we are living in an AI world, nowadays we should just be able to fill out a text area, and the system should find out what data belongs to what..

        Then you stated “City, state and zip need to be separate fields. If you place those fields before the address text area, users will fill them out first and won’t make that mistake.” Isn’t this “against” the natural flow of users? Shouldn’t the rule be to follow as much as possible the order as the user is familiar with?

        Generally speaking I would state that labeled fields are pro usability, so maybe just the label is wrong? Or a different label applies for different geographical areas?

        • anthony Reply

          The general rule is to present fields that are easiest to fill out first to decrease form abandonment. City and state are easier to fill out than addresses.

      • Phread Reply

        City, state and zip do NOT need to be separate fields. Some Company’s applications may prefer (or require) to have all the address components entered separately, and some don’t care. It depends upon the reason for gathering the address information, what the Company is allowed to do with the address, and what the Company is willing to do with the address. There is a cost for each solution (time/money), just depends upon the needs.

  5. RGL Reply

    i agree with Jshell. the whole point of using 2 input fields is for data integrity. if you open up a text field to the user, you’re most likely to get crap data that is hard if not impossible to query.

  6. FFS Reply

    Another issue with using a textarea is that I have seen exactly zero website forms that ask for addresses as a textarea. So assuming this is not a person’s first form they’ve ever filled out (the vast majority of people nowadays will have completed at least a few online forms) they will likely be more confused by a textarea. If people are slowed down by “Address 2” how much will they be slowed down by a generic “Address” textarea where the contents are ambiguous? Also as people have noted, people may not enter all of the necessary information in the box which may result in more work for the customer and the company in the future to collect the info or deal with the problems that may occur.

  7. Isabel Holdsworth Reply

    Definitely an interesting and thought-provoking read. But IMO providing exactly one field per chunk of data to be entered by the user is the least confusing approach. If you consider an address to be a single entity, then perhaps capture the whole thing in a single textarea. If you consider it to be a number of discrete elements, then expecting the user to enter two elements in one field, then one element in the other fields is likely to lead to more confusion.

  8. Steve Reply

    Have you tested this? What were the results?

  9. Will Reply

    Having dealt with addresses in systems in the past, i’m thinking in future of this exact approach – just a textarea for an address so that the individual quirks across countries are just taken care of. Typing an address in a textarea is a lot quicker for the user too. I think we can take some burden off the users just by thinking things through pragmatically. To address some concerns about data integrity:

    Validation: This is possible by splitting the rows of the textarea and validating the last one against a specific postal code regex, the penultimate line against a regional list and the first you throw at an address validation API. Just because it’s inputted as a block of text, it doesn’t mean you have to store it in a text field in the database – a JSON type would naturally lend itself to an unknown number of lines.

    Some typical use cases:
    For mapping purposes – the postal code is the valuable bit of data, but you can just throw the entire address text at the Google Maps API and it’ll parse and find the location itself

    For printing labels – the address has been typed in exactly as required by the user, so just print as is

    To visit the location IRL – you navigate to the postal code geographic location and use the rest of the text to find the street and building name/number, as you would with any address stored in a database…

  10. Bożena Czech Reply

    I think the main problem is with the numbers recognition in one input field. People can input them interchangeably, depending on the country.
    In my country for example the street name might or might not contain numbers. Then we have the building number and sometimes apartment number. Which all can be from 1 number up to 3 numbers. People might or might not use punctuation to distinguish them. There is just too much risk for address getting mixed up. Couple of times it happened to me, because they taken the apartment number as building number.

  11. Lucas Reply

    For me, it just look bad, I wouldn’t use it. Two separate fields with only 1 label is a poor option.

Leave a Reply

Your email address will not be published. Required fields are marked *