In an original delivery form, a customer sends equipment to a workshop but bills the office. Both blocks contain a street-address input. Calling both fields “address” leaves the page and its submitted data harder to understand; explicit groups describe the intended role without inventing an autofill guarantee.
Describe each address field
<form id="delivery">
<fieldset>
<legend>Shipping address</legend>
<label for="ship-street">Street address</label>
<textarea id="ship-street" name="shippingStreet"
autocomplete="shipping street-address"></textarea>
<label for="ship-city">City</label>
<input id="ship-city" name="shippingCity"
autocomplete="shipping address-level2">
<label for="ship-postal">ZIP or postal code</label>
<input id="ship-postal" name="shippingPostal"
autocomplete="shipping postal-code">
</fieldset>
<fieldset>
<legend>Billing address</legend>
<label for="bill-street">Street address</label>
<textarea id="bill-street" name="billingStreet"
autocomplete="billing street-address"></textarea>
<label for="bill-city">City</label>
<input id="bill-city" name="billingCity"
autocomplete="billing address-level2">
<label for="bill-postal">ZIP or postal code</label>
<input id="bill-postal" name="billingPostal"
autocomplete="billing postal-code">
</fieldset>
<button type="submit">Continue</button>
</form>
This fragment deliberately omits an application submission destination. Integrate it into the real form's authorized handler. Add any country and region fields the delivery process requires; address-level2 commonly represents the city in a US address, while address-level1 represents the state or region.
The autocomplete reference, checked October 24, 2026, specifies the token meanings and ordering. Its browser conditions also matter: autocomplete describes the purpose, while actual suggestions depend on the browser and available user data.
Distinguish repeated recipients with sections
When one form ships separate packages to two people, each shipping block needs its own section. Put a section- token first:
<input name="recipientOneCity"
autocomplete="section-recipient1 shipping address-level2">
<input name="recipientTwoCity"
autocomplete="section-recipient2 shipping address-level2">
Use the same section identifier for all fields belonging to one recipient and a different identifier for the next. Keep the order as section, shipping or billing, then the field meaning. An arbitrary extra word such as office is not a replacement for section-office.
These tokens do not rename the submitted fields. A FormData entry uses name="recipientOneCity", not the autocomplete string. Your backend still needs the expected field names, and each visible label should identify its intended input. The text input guide covers those basic relationships.
Keep validation and suggestions separate
Autocomplete does not make an address valid, required or deliverable. Add the constraints your application actually needs and validate submitted data on the receiving side. Do not make a postal code a numeric quantity merely because a local example contains only digits; postal identifiers may contain leading zeros or letters.
If the task is to suppress unwanted suggestions for a one-off internal code, the no-autocomplete guide addresses that different intent. For address collection, semantic tokens help explain the fields instead of asking the browser to suppress assistance.
Test the grouping with disposable address data
In a development profile with a disposable saved address, focus Shipping street address and inspect the offered fill. Then choose a different billing address and confirm the shipping values remain appropriate. Test repeated recipients separately if those sections exist.
Inspect the eventual form payload as well: shipping and billing must arrive under distinct expected names. A clean isolated profile may offer no saved suggestions, which does not by itself show that the tokens are wrong. Finish the check in the browsers your customers use, with representative test data, before claiming that their autofill behavior works.