Address form engineering guide
Address Line 1 vs Address Line 2: What Goes Where?
The labels look simple, but line 2 is where duplicate cities, dropped apartment numbers, and mismatched API payloads tend to begin. This guide treats the two lines as a data contract, not just a visual layout.
The field contract
- Address Line 1
- Primary street delivery data: house number and street name, for example
2731 Olympic Blvd - Address Line 2
- Optional secondary-unit data:
APT 4B,STE 210,UNIT 12, orRM 305 - Not line 2
- City, state, postal code, country, or a duplicate of line 1
If a record has no apartment, suite, room, or unit, line 2 should remain empty and the form should still submit.
The test record I used
On July 30, 2026, I selected California in the English US Address Generator and generated one record. The resulting address was 2731 Olympic Blvd, Los Angeles, CA 90012, United States. I ignored the generated name, phone, and inbox because this test was limited to address fields.

The result exposes 2731 Olympic Blvd as Street. That value maps cleanly to line 1. AddressLab does not generate a separate unit value, so line 2 is empty unless the test case deliberately adds one.

HTML autocomplete should describe the same model
WHATWG defines address-line1 as the first free-form address line and address-line2 as the second. When a form exposes separate one-line controls, the autocomplete tokens should match those controls:
<input name="address_line1" autocomplete="address-line1">
<input name="address_line2" autocomplete="address-line2">
<input name="city" autocomplete="address-level2">
<input name="state" autocomplete="address-level1">
<input name="postal_code" autocomplete="postal-code">If the UI uses one multiline textarea instead, street-address is the more appropriate token. Mixing street-address with separate line controls can make browser autofill behavior harder to predict.
Keep line 2 optional all the way through the stack
A common implementation bug is making the browser field optional but requiring it in the API schema. Another is accepting it, then dropping it from the confirmation card or CSV export. I use this payload shape because the optionality is visible:
{
"addressLine1": "2731 Olympic Blvd",
"addressLine2": "APT 4B",
"city": "Los Angeles",
"region": "CA",
"postalCode": "90012",
"country": "US"
}Normalize an empty string and a missing value deliberately. Do not silently replace a blank line 2 with the city, and do not concatenate both lines without a separator when generating a mailing label.
A small test matrix catches most failures
| Case | Line 1 | Line 2 | Expected result |
|---|---|---|---|
| No unit | 2731 Olympic Blvd | blank | Submits and displays one street line |
| Apartment | 2731 Olympic Blvd | APT 4B | Unit survives save, reload, and export |
| Suite | 2731 Olympic Blvd | STE 210 | Type and number remain intact |
| Long secondary value | 2731 Olympic Blvd | BLDG 2 FL 4 RM 405 | No clipping or horizontal overflow |
| Wrong semantic value | 2731 Olympic Blvd | Los Angeles CA | Validation or review flags duplication |
USPS output can be one line even when storage uses two
USPS Publication 28 places secondary-unit information at the end of the delivery address line when it fits:
2731 OLYMPIC BLVD APT 4B
LOS ANGELES CA 90012If the secondary information cannot fit, USPS allows it immediately above the delivery address line. This is a presentation rule. It does not require an application to collapse addressLine1 and addressLine2 into one database field.
Where AddressLab fits into the test
AddressLab supplies separate Street, City, State, Postal Code, and Country values. I use Street as line 1, then add a controlled APT or STE value when the scenario needs line 2. This avoids depending on a randomly present apartment number.
The limit is important: these are synthetic test records. A coherent field set does not prove that the generated house number exists or receives mail. It is not a deliverability validation and should not be used for shipping, identity, or financial workflows. The boundary is documented in the data methodology and editorial standards.