Form Usability: Getting ‘Address Line 2’ Right

While ‘Address Line 2’ may seem like an insignificant aspect of an e-commerce design or overall form design, we have observed this form field to be the cause of bewilderment and uncertainty for users during both our checkout usability and mobile e-commerce research studies.

Now, it should be noted that the ‘Address line 2’ form field was never observed to be the direct cause of checkout abandonments during any test sessions. Poor ‘Address line 2’ designs did however contribute to a sub-par form filling experience during both studies, as the test subjects spent excessive time filling out forms or typed correct input in a wrong field, resulting in needless validation errors and warnings.

Given how easy it is to design a user-friendly and unambiguous ‘Address line 2’ field, it’s worth taking a moment to fix it – it really is one of those low-hanging fruits in checkout and form design. In this article we’ll therefore go over 5 tips to get the ‘Address line 2’ right.

1) Understand Current Usage

The first step is to query your order history and figure out how much the ‘Address Line 2’ field is currently being used, who is using it, and the type of information they are filling into the field. Understanding the field’s current usage and utilization rate will be important when we turn to the field design options later on (tip #3).

The first step to getting the ‘Address Line 2’ right is understanding its current usage: which customer types are using it and what type of information are they entering into it? This data can easily be extracted from your order database for analysis.

Figuring out how much the field is currently being used should be fairly a straight-forward matter of querying your database and can therefore be determined with little manual effort. Understanding who is using the field and the type of information these users are entering into it, on the other hand, requires some data analysis. Things to look for are specific user types, customer demographics, and order types (business address deliveries, international orders, metropolitan areas, etc).

All of this can prove valuable insights when it comes to optimizing the field context (tip #2) with precise labelling and useful instructions and placeholder text. It may also help you better predict any edge use-cases (and by virtue thereof, better support those).

2) ‘What Goes Where?’

The most commonly observed issue with the ‘Address Line 2’ field during our usability test sessions are field ambiguity, with users often wondering “should I enter company name, PO box, military address, or a C/O address in line 1 or 2?”

Even something as common as an apartment address, where it’s clear that street name and number should go in the first address field, we time and again see test subjects turn doubtful as they have to type a floor level or room number.

Is floor level or room number supposed to go in address line 1 or 2? (Microsoft’s checkout)

While one could argue that users are free to type this information in whatever field they prefer, we have repeatedly observed how users will go to great lengths to try and preempt validation errors during the checkout process. Most users feel very uncomfortable when presented with validation errors during checkout as they are entering highly sensitive information (their identity, often home address, and credit card details), and they therefore strongly prefer to follow a “safe example” and proceed successfully the first time around rather than guess by trial and error.

Thus to avoid making the user at unease during checkout, it’s a good idea to give them examples that are “safe to follow” (since they otherwise have no idea if you require a special sequence or formatting).

With additional label descriptions below the two address fields it’s easy for the user to know what goes where. (Amazon’s checkout)

The “best practice” implementation of this is to provide an additional label description and input examples either in direct conjunction with the field label or below the ‘Address Line 2’ field itself. Typically in a secondary smaller and greyed out font, specifying that this is the place for “Apartment no., C/O addresses, floor level, Att., PO box, etc”. Meanwhile the placeholder text can be used to provide actual input examples (e.g. “Chestnut Street 2125”).

(Note that this advice isn’t exclusive to the ‘Address’ fields but goes for most form fields during the checkout process – form fields almost always benefit from additional label descriptions and examples.)

3) Labelling: Avoid ‘Address 2’

‘Address 1’ and ‘Address 2’ is open to being misinterpreted as two different addresses – in fact, being strict it wouldn’t even be a misinterpretation as that labelling actually suggest two different addresses if read out of context (commonly observed on mobile checkouts).

While misinterpreting the two fields as two separate addresses is not the most frequently observed issue, it does happen. Mostly for users who’ve been perplexed earlier in the checkout experience, and especially when testing users not native in english, or on sites which by their nature often require multiple addresses (e.g. gift and flower sites which often have both a ‘giver’ and a ‘receiver’, or orders with different billing and shipping addresses).

The ‘Address 1’ and ‘Address 2’ labels on Target could potentially be misinterpreted as fields for entering two separate addresses.

So while this sub-issue of misinterpreting the address fields as two different addresses is low in frequency, the severity of it when it does occur is very high. Indeed, we’ve observed it to result in completely shattered checkout experiences and lead to orders being completed with invalid shipping data.

Therefore to avoid this potential ambiguity, be sure to label the fields ‘Address Line 1’ and ‘Address Line 2’ respectively. (This once again underscores the importance of microcopy).

4) Explicitly Denote ‘Line 2’ As Optional

During our usability research studies we continue to observe just how singularly focused users can be. This is particularly true of form fields where users often focus only on the field they are currently filling out, largely ignoring the other fields in the form.

It’s therefore important to good form usability that each field can be understood in isolation, and for this exact reason it’s insufficient to simply mark all required fields with an asterisk. Any optional fields should be explicitly denoted as such too, so that users can read the field label and understand its context and conditions without having to infer them from surrounding fields.

Nike doesn’t indicate which fields are required and which are optional, making it unclear if both address fields must be filled out.

Thus the proviso for both address fields should be explicitly denoted: the ‘Address line 1’ field must be marked as required and ‘Address line 2’ as optional. It may seem like a small detail, but it’s actually especially important to get right for the address fields because they are related, and some users may therefore assume that if ‘line 1’ is required then ‘line 2’ is as well.

(See all our test findings on explicitly marking both required and optional fields)

5) Consider Merging or Hiding ‘Line 2’

If you’ve found there’s a low utilization rate for the ‘Address Line 2’ field, you can consider removing or hiding it entirely. There are two dominant approaches.

Crutchfield does away with the address field ambiguity issues altogether by having just a single ‘Address’ field.

If you don’t need to distinguish what data belongs to each address line, the most simple solution is to consider just having a single ‘address’ field. Depending on address standards and the postal service companies available where you operate, it may not be necessary to distinguish between address line 1 and 2.

Alternatively, the address field could also be made into a multi-line field, allowing the user to enter multiple lines while keeping the form design to a single (slightly larger) ‘Address’ field.

The new VISA Checkout displays a single ‘Address’ field by default to keep the form design simple, but with an embedded ‘+’ icon allowing the user to add a second address line if they need to. (Do however note that icons can be ambiguous so if option for this solution make sure to provide a clear tooltip / hover text description.)

Update: In our latest Checkout Usability study we’ve during our large-scale eye-tracking tests confirmed that the ‘Address Line 2’ field can safely be collapsed behind a clearly marked text link, such as seen here at REI.

If you do need to be able to distinguish between address line 1 and 2 – whether the reason be for address validation mechanisms, shipping partners, or something entirely else – yet don’t want to put too much attention on the field, you may consider a dynamic approach where the user adds the second address line themselves. This way the edge case users who are looking for the feature will be able to provide their address in multiple lines whereas the average users only has to deal with a single ‘Address’ field. (That said, some users won’t notice this feature and simply fill all information in address line 1, so be prepared to handle those cases gracefully.)

Getting ‘Address Line 2’ Right

The ‘Address Line 2’ field certainly isn’t that one single thing that will make or break your entire checkout experience. It is, however, one of those 10-20 smaller improvements that it takes to lift a checkout experience from good to great.

You should of course always start by getting the basics right. But once you’ve got that solid foundation in place, it’s time to focus on the details. The ‘Address Line 2’ is one of those details. So make sure you:

  1. Understand the field’s current usage: which customer types are using it and what are they entering into the field?
  2. Use additional label descriptions and examples to clarify what data goes into address line 1 and 2 respectively.
  3. Clearly label the fields ‘Address Line 1’ and ‘Address Line 2’ (rather than the potentially ambiguous ‘Address 1’ and ‘Address 2’).
  4. Explicitly mark ‘Address Line 1’ as required and denote ‘Address Line 2’ as optional.
  5. Consider merging the two fields or hiding ‘Address Line 2’ if the distinction is only necessary in a few edge cases.

Tip: If you want to browse 49 different address forms from top retailers, you can do so in our Checkout Usability Benchmark sorted by Checkout Step Type.

This article presents the research findings from just 1 of the 642 UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.

Post a comment or Share:

User experience research, delivered twice a month

Join 17,000+ readers and get Baymard’s research articles by RSS feed or e-mail:

Due to spam, you need JavaScript to do that.

(1-click unsubscribe at any time)

Related Articles

See all 49 ‘Cart & Checkout’ articles

More E-Commerce Research

Free Research Content:

Products & Services:

Comments (16 so far)

Elizabeth Buie November 4, 2014

Great post, and useful. There’s just one thing that bothers me: I don’t see the benefit of labelling these “line 1” and “line 2”, as it seems to me that that labelling comes from programmers. I would try labelling the first one “Address” and the second one “Address (cont.)”, and see how that tests. I haven’t had the opportunity to test it myself, but next time I get a chance I will do so (unless someone else comes up with the results first).

Due to spam, you need JavaScript to do that.

Jamie, Baymard Institute November 4, 2014

Hi Elizabeth,

I like your idea of trying to name the labels something more plain. The ‘line 1’ and ‘line 2’ are references to physical (print) forms where the address is often filled out across multiple ‘lines’, although that suffers from being an increasingly less obvious metaphor (as paper forms become less and less common) and of course taps into the inherent limitations of the printed medium. Would definitely be interesting to test out a wide range of labellings and see which users find the most natural.

Due to spam, you need JavaScript to do that.

James November 7, 2014

I’ve always wanted to test changing the address line 1 & address line 2 to a textfield of just address (and then keep postcode as normal).

Does that test well do you know?

Due to spam, you need JavaScript to do that.

Laura Moraiti November 7, 2014

This is a very insightful post, and I like how you break down the pitfalls from specific examples… BUT, is that second line really necessary?

I usually write my whole address in the first line because (simplest reason of all), mailmans in my country they tend to not deliver if the address is a tad off (if you miss-typed one letter they won’t deliver, even knowing the correct address). So, when presented with two lines I always wonder how it will be printed in the package. Will both lines be printed? Will one of them be ommitted? I can’t take any risks!!

My suggested approach, stop wasting time deveoloping ‘adders’ to add a new line and instead use a simple textarea with a length limit. You don’t want the Bible written in the address field, but you want to let the user complete the whole info without feeling pressured to think about what will be printed / how it will be interpreted /etc.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute November 7, 2014

Hi Laura, if there’s a low utilization rate one can do like shown in the Crutchfield example in point #5 (simply having one address field).

Due to spam, you need JavaScript to do that.

Laura Moraiti November 7, 2014

Yes, but, it’s not comfortable. Imagine your address is not long enough to occupy two inputs, but it’s long enough to not been seen completely while filling the input.

I feel the low utilization rate could simply be obsoleted by using a textarea with a limited amount of chars (80, 100, whatever) and styling it to look like a double tiered input (to not disrupt the design flow). Adding the huge plus of seeing the entire writing without the need to move with the cursor back and forth.

I’m curious to know what’s the drawback you find to a small textarea, I’m perhaps missing something.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute November 11, 2014

Hi Laura, we don’t disagree here, we mention a multi-line field in the article as well (e.g. it can depend on the sites specific field width and input font styling). In fact our mobile usability testing find that masking part of the users input can cause severe issues – see this article

Due to spam, you need JavaScript to do that.

Tomas Kapler November 7, 2014

And what about simple 2 rows textarea?

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute November 11, 2014

Hi Tomas, yes as mentioned in point #5 in the article on can also consider a multi-line address field. We don’t have any particular test observations on this implementation, but the size of the field will allow it to display most inputs in full (without partly masking the data – as Laura also mention as an issue with a single line address field).

Just to cover all variations: Two separate fields with only 1 label is however a poor option, see example here , as the second line will be labelless and thereby not address issue #2 and #4

Due to spam, you need JavaScript to do that.

Eric Scheid March 9, 2015

Please do note that what goes into line 1 vs line 2 is also country specific.

For example, in Australia, the building name goes into line 1, with the street number and name in line 2.

This is pretty comprehensive:

Due to spam, you need JavaScript to do that.

james turner March 2, 2016

technically, that is how you are supposed to do it in the united states too. unfortunately, no one seems to be familiar with usps regulation 213.3. so, most people do it wrong (including amazon apparently).

Due to spam, you need JavaScript to do that.

Charlie D June 12, 2015

What if you put the same address on both lines? I recently did that, then I edited my address. Yet, it still has both address lines on my order history….Should I be worried at all?

Due to spam, you need JavaScript to do that.

Jessie June 24, 2015

If you got feedback that “Address 2” was confusing, then it seems that “Address Line 2” would still be a little bit confusing.

Is there a reason to not label it: “Apartment, Suite, Unit, Etc.”?

Due to spam, you need JavaScript to do that.

james turner March 2, 2016

because sometimes the apartment number goes on line 1 and sometimes it goes on line 2.

apt 203
123 main st

c/o nancy thurman
123 main st apt 203

Due to spam, you need JavaScript to do that.

Jonathan January 13, 2017

I think the problem is not that people do not understand how to use address line 2, but that companies do not and this makes people (myself included) try to cheat the system to make an address print correctly.
As others have commented, it should be Addressee, apartment, floor, building, street (or as I was recently trying to achieve, Addressee, Building name, Care home complex, Street) and insisting that address line 1 is for street, as Amazon do, means that if you use both lines the address is printed incorrectly.
Possibly if a website designer truly does want to capture the street on address line 1, they should show how the address will be printed if address line 2 is utilised so that people know they do not have to defeat the system (or know that they have to try to defeat the system, and the web designer is an idiot as it is impossible to enter the address so that it will print correctly using the options he/she has provided)

Due to spam, you need JavaScript to do that.

John Brandenburg January 24, 2018

A site I’m working on is getting an abnormal number of users adding their country in “Address Line 2.” This seems to be coming from their browser’s auto-fill functionality. Testing it myself, sure enough, “United States” is pre-populating in line 2. However, this form has a dedicated country field already.

Is this a common issue? The “name” attribute is address2, but this should be coming from whatever the user’s auto-fill profile dictates. Maybe this is a more recent trend?

Due to spam, you need JavaScript to do that.

Post a comment!

Due to spam, you need JavaScript to do that.