An address form may look clear to a person while giving the browser weak clues about each field. The HTML autocomplete attribute can describe the kind of information a control expects, making saved-address entry more predictable.
Keep visible labels and sensible field names. Autocomplete metadata complements those features; it does not replace them or guarantee that every browser will fill the form.
Describe the field’s actual purpose
The MDN autocomplete reference documents tokens such as address-line1, postal-code and country. It also explains billing and shipping groups. A shipping postcode can use autocomplete="shipping postal-code", while the billing equivalent uses autocomplete="billing postal-code".
Use the token that matches the data you collect. An address line is not a substitute for the city, postal code and country together. If the form uses a multiline street-address field, follow the documented pattern rather than also treating separate address-line fields as the same information.
Repeated address sections may need distinct section identifiers. Plan those groups before copying markup, so that two recipients’ details are not accidentally described as one shared address.
Test the populated result
Use fictional saved addresses in test profiles. Try billing and shipping addresses that differ, an address with a second line, and an international format relevant to the audience. Inspect the submitted data as well as the visible fields.
Check whether autofill leaves an old value in a hidden or collapsed section. Confirm that labels remain understandable after values appear and that keyboard users can review and correct them. Never use real customer details as convenient test data.
Autofill is assistance, not verification. The application still needs appropriate server-side validation, clear error messages and a way to edit the address. A well-described form reduces repetitive typing while leaving the person in control of what is submitted.