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, or RM 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.

California selected in the English AddressLab address generator before generating a test record
A fixed state gives the test an expected region before the dependent fields are inspected.

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.

Generated AddressLab record with separate Street, City, State, Postal Code, and Full Address fields
The generated Street belongs in line 1; City, State, and Postal Code already have separate destinations in the form model.

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

CaseLine 1Line 2Expected result
No unit2731 Olympic BlvdblankSubmits and displays one street line
Apartment2731 Olympic BlvdAPT 4BUnit survives save, reload, and export
Suite2731 Olympic BlvdSTE 210Type and number remain intact
Long secondary value2731 Olympic BlvdBLDG 2 FL 4 RM 405No clipping or horizontal overflow
Wrong semantic value2731 Olympic BlvdLos Angeles CAValidation 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  90012

If 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.

Primary references