Chrome now fills more of your checkout than your form is built to accept

Browser autofill has quietly become one of the largest conversion levers in checkout, and almost nobody owns it. It is not a design decision, not a copy decision and not something an A/B testing tool can fix. It is a property of your form markup, which means it is usually nobody’s job, which is why roughly a third of checkouts still leave it on the floor.

Why this is worth an afternoon

Start with what the browser vendor measures, because it is the largest dataset available and it is not being sold to you by a CRO tool.

• Chrome’s own research across heavily visited US sites reports that forms completed with autofill saw roughly a 75% reduction in abandonment and a 35% reduction in completion time.
• Data from Shopify, published by Google’s Chrome team, shows guest checkouts where autofill was used converting about 45% better than guest checkouts where it was not.
• Roughly one in three guest checkouts — sessions that open on an empty form — use autofill at all.

Now the caveat that almost every article quoting those numbers omits. These are correlations, not measured lifts. A shopper with a saved address and card in their browser is, on average, a more experienced online buyer who is further along in intent than one without. Some of that 45% is the autofill; some of it is the kind of person who has autofill set up. Nobody has published a clean randomised split, because you cannot randomly assign people to have saved addresses.

That caveat does not weaken the recommendation, and this is the useful part. Autofill compatibility is not an experiment with an opportunity cost. It costs a few hours of developer time, adds nothing to page weight, changes nothing visually, and removes typing on the slowest part of the funnel. You do not need a 45% lift to justify it. You need it to be free, which it approximately is.

What the browser reads, in order

Both major autofill engines classify each field by looking for signals in a rough order of confidence:

1. The autocomplete attribute. When present with a recognised token, this is the strongest signal and effectively ends the guessing.
2. The name and id attributes, pattern-matched against conventional strings: fname, email_address, zip, cc-num.
3. The associated <label>, read as human-language description of the field.
4. The placeholder, the weakest of the four and the one most likely to be a marketing phrase rather than a field description.

Because levels 2 to 4 work often enough, most checkouts appear to support autofill without anyone having designed for it. That is the trap: the fallbacks are heuristics, they vary by browser and version, and they break the moment a build tool renames billing_postcode to field_a7f3c1. A checkout that autofilled correctly in March can quietly stop after a framework upgrade, and nothing in your analytics will say so.

The checkout field map

This is the reference table. Set the token on every field; do not rely on level 2 through 4 for anything.

Two structural rules go with the table. Use the shipping and billing prefixes on every address field even when only one address is collected, because the second address block is usually added later by someone who does not know this article exists. And when a page contains more than two addresses — a multi-recipient gift flow, for instance — group each with a section-* prefix so the browser keeps them separate.

Six things that break autofill in a modern checkout

Every one of these is something we have found on a live store in the last year, and every one is invisible in a design review.

The fifth row deserves particular attention because it is the one that produces angry support tickets rather than silent loss. A customer taps autofill, watches six fields populate, and then watches three of them clear as a validation re-render runs. That reads as a broken site, and it converts worse than never offering autofill at all.

Chrome now fills documents and loyalty data, and there are no tokens for them

Chrome’s autofill has expanded well beyond addresses and cards. Passport numbers, driving licence details and vehicle information arrived on desktop in November 2025; loyalty card details and flight bookings followed in December 2025; and from 23 June 2026 the same categories came to Android and iOS, pulled from Google Wallet behind biometric verification, with device integrity requirements on Android and a passcode plus two-factor Apple ID on iOS.

Here is the part that affects your build. The HTML autocomplete specification has no tokens for these categories. There is no passport-number token, no loyalty-number, no known-traveler-number. Which means for exactly these fields, the browser is back to level 2 through 4 — names, labels and placeholders. Your label text is the signal.

If you run a travel, car rental, ticketing or age-verified checkout, these are usually the slowest and most abandoned fields in the entire flow, because they require the shopper to go and find a physical document. Being fillable is worth far more here than on an address line. The whole optimisation is: name the field the way a human would name it, and pair it with a matching name attribute.

Size the opportunity with your own numbers

Do not present the 45% figure internally. Present this, which takes ten minutes in your analytics and is defensible in a way a borrowed benchmark is not.

1. Guest share. What proportion of checkouts start from an empty form rather than a logged-in account? This is the population autofill can help.
2. Current autofill usage. Instrument it: on each checkout field, compare the time between first focus and a complete value against a typing threshold, or watch for multi-field population within the same tick. Chrome’s benchmark is about one in three guest checkouts. Well below that is itself the finding.
3. Completion rate by group. Checkout completion for autofill sessions versus non-autofill sessions, mobile and desktop separately.
4. Size the gap, conservatively. Take the difference in completion rate, halve it to allow for the correlation problem above, and apply it to the share of guest sessions that are currently failing to autofill.
5. Then measure the fix. Ship the markup changes and watch autofill usage as the primary metric, not revenue. Usage moves first, is attributable to your change, and is not drowned in seasonality.

On a store with 10,000 monthly guest checkouts, a 55% completion rate and autofill usage at 12% instead of 33%, that arithmetic typically surfaces a few hundred recoverable orders a year. Not transformative. Also not something you should be paying a CRO retainer to find, which is rather the point.

The twenty-minute test

1. Fresh profile, real phone. A new browser profile with exactly one saved address and one saved test card, on an actual handset. Desktop emulation misses mobile-specific behaviour entirely.
2. Fill from the first field and let the browser do everything it offers. Do not help it.
3. Write down three columns: fields left empty, fields filled with the wrong value, and fields that emptied themselves afterwards. The third column is the urgent one.
4. Repeat with both addresses if you collect shipping and billing separately. Cross-filling only shows up here.
5. Open the DevTools autofill panel on the same form to see how the browser classified each field, and whether labels are properly associated.
6. Retest after every checkout deploy. Add it to the release checklist, because a framework upgrade is all it takes to undo the whole thing.

Where this sits against the rest of your checkout work

Autofill sits in the same family as wallets and passkeys: mechanisms that let a returning human prove who they are and where they live without typing it again. Wallet buttons skip the form entirely and should be there too, as should Apple Pay and Google Pay. But wallets only help shoppers who use them, and the form underneath still handles everyone else, including nearly all B2B buyers and anyone whose order needs a delivery instruction or a purchase order number.

The reason autofill is worth prioritising over most other checkout work is its risk profile. Reducing fields might lose data you need. Adding a payment method costs fees. Redesigning the flow needs a test cycle you may not have time for before peak. Declaring what your fields contain has no downside at all, and it happens to be the same work that makes the form usable with a screen reader — the overlap described in why accessibility is a conversion problem. Two outcomes, one pass over the markup, and a page that finally accepts everything the browser was already trying to give it. If you want that pass run properly, it is part of how we approach conversion optimisation.

Frequently asked questions

How does browser autofill decide what a field is for?

In order of confidence. First the autocomplete attribute, and if it carries a token the browser recognises that is the strongest possible signal. If it is absent, the browser falls back to heuristics: pattern matching on the name and id attributes, then the associated label, then the placeholder. Those fallbacks work often enough that many teams never realise they are relying on them, and they break silently whenever a framework generates random field names.

Does autofill really improve checkout conversion?

The published data is strong but correlational. Chrome's own research reports about a 75% reduction in form abandonment and 35% faster completion for autofilled forms, and Shopify data published by Google's Chrome team shows guest checkouts using autofill converting roughly 45% better. Neither is a randomised lift measurement, and people who have saved addresses are also more likely to be experienced online shoppers. The direction is not in dispute; the magnitude for your store is unknown until you measure it.

What is the single most common mistake?

Fields with no autocomplete attribute and framework-generated name attributes, so both the primary signal and the fallback are missing. The second most common is shipping and billing address fields that share identical names without shipping or billing prefixes, which is how a customer's shipping address ends up in the billing block. Both are markup problems, invisible in analytics and invisible in a design review.

Should I use autocomplete=off on checkout fields?

No. Chrome does not reliably honour it on address and payment fields, so it is neither a privacy control nor a dependable way to suppress the dropdown. What it does do reliably is remove the strongest signal you can give the browser. The narrow legitimate uses are one-time codes, which should use one-time-code instead, and fields where a saved value would be actively wrong, such as a gift recipient's name.

Chrome can now fill passports and loyalty numbers. Does that need new markup?

There are no standard autocomplete tokens for passport numbers, driving licences, known traveller numbers, loyalty numbers or flight details, so the browser leans on your field labels and names instead. That makes plain, conventional label text the signal: Passport number rather than Document ID, Loyalty number rather than Member reference. It matters for travel, car rental, ticketing and age-restricted checkouts, where these fields are the slowest part of the form.

How do I test whether autofill works on my checkout?

Use a fresh browser profile with one saved address and one saved card, on a real phone rather than a desktop emulator, and fill the form from the first field. Note every field the browser leaves empty or fills wrongly, then open Chrome DevTools' autofill panel on the same form to see how each field was classified. Twenty minutes gives you the whole defect list, and most of it is a one-line fix per field.

The takeaway

Autofill is the rare checkout improvement with no trade-off: nothing gets uglier, no test needs to reach significance, no third-party script gets added. It is one attribute per field, real labels and field names that do not change between renders. Run the fresh-profile test on a phone today, write down every field the browser could not fill, and fix them in one pass. Then measure your own autofill usage and completion rates rather than quoting anyone else's percentage, including the ones in this article.