The autocomplete attributes that let a checkout form fill itself in

Most people don't type their address into a checkout form. Their browser or password manager does it for them, in one tap, if the form lets it.

Whether that tap works comes down to a handful of HTML attributes that are easy to skip. When they're missing, autofill guesses. Sometimes it guesses right. Sometimes it puts the street name in the city field and the customer has to clean it up on a phone keyboard.

Here's what I'd put on every field of a typical checkout.

The basic set

<form method="post" action="/checkout"> <label for="name">Full name</label> <input id="name" name="name" autocomplete="name"> <label for="email">Email</label> <input id="email" name="email" type="email" autocomplete="email"> <label for="tel">Phone</label> <input id="tel" name="tel" type="tel" autocomplete="tel"> <label for="street">Street and number</label> <input id="street" name="street" autocomplete="shipping street-address"> <label for="city">City</label> <input id="city" name="city" autocomplete="shipping address-level2"> <label for="zip">Postal code</label> <input id="zip" name="zip" autocomplete="shipping postal-code" inputmode="numeric"> <label for="country">Country</label> <select id="country" name="country" autocomplete="shipping country"> <option value="IL">Israel</option> <!-- ... --> </select> </form> 

A few things worth calling out:

• address-level2 is the city. The names are not obvious. address-level1 is the state/region, address-level2 is the city or town. I've seen these swapped more than once.
• The shipping prefix. If you also collect a billing address, prefix those fields with billing. Browsers can then fill two different addresses without mixing them up.
• street-address vs address-line1. If you have one street field, use street-address. If you split it into two lines, use address-line1 and address-line2. Don't use street-address on a single-line <input> and expect line 2 to appear somewhere.

type and inputmode are separate jobs

autocomplete tells the browser what the value is. type and inputmode decide which keyboard shows up on a phone.

• type="email" gives the keyboard with @ on it.
• type="tel" gives a number pad with +.
• For a postal code, type="number" is a trap: it adds spinner arrows, strips leading zeros in some cases and lets the scroll wheel change the value. Use a text input with inputmode="numeric" instead.

Names are messier than forms assume

A single "Full name" field with autocomplete="name" works for almost everyone. Splitting into first and last name (given-name and family-name) is fine if you really need it, but plenty of people have names that don't fit that shape. If the only reason for the split is "Dear {firstName}" in emails, one field is the kinder option.

Payment fields, if they're yours

If the card fields are on your page and not inside a payment provider's iframe:

<input autocomplete="cc-name"> <input autocomplete="cc-number" inputmode="numeric"> <input autocomplete="cc-exp" placeholder="MM / YY"> <input autocomplete="cc-csc" inputmode="numeric"> 

If you use a hosted iframe, the provider handles this, and there's nothing to add on your side.

Things that quietly break autofill

• autocomplete="off" on the whole form. Usually added years ago to stop something unrelated. Browsers often ignore it for addresses anyway, but when they do respect it, customers lose the fastest way to finish.
• Fields without a real <label>. A placeholder isn't a label. Autofill heuristics, screen readers and voice control all lean on the label.
• Random name attributes like field_17. With a proper autocomplete value it mostly doesn't matter, but without one, the name is one of the few hints the browser has.
• Fields rendered after a delay. If the address fields only appear after the user picks a delivery option, autofill may have already run on the visible ones. Test that flow specifically.
• Custom dropdowns for country or city. A styled <div> that pretends to be a select won't receive autofill. If you need a searchable list, keep a real input underneath it.

How to check yours in five minutes

1. Save an address in your browser's autofill settings.
2. Open the checkout on a phone, tap the first field and pick the saved address.
3. Look at every field. Is the city in the city field? Did the postal code land? Did the phone number keep its country code?
4. Repeat in one other browser, because they don't all read the attributes the same way.
5. Tab through it with the keyboard and confirm each field announces a sensible label.

None of this is new or clever. It's just one of those parts of a form that nobody owns, so it drifts. I went through the checkout fields at RAMO with this list, and it's a good reminder that someone ordering pipe fittings in the middle of a plumbing job wants to type as little as possible.