HTML autocomplete attribute, tested with Chrome autofill

Why does autofill put the wrong thing in a field, or nothing?

You watch a customer fill in your order form on their phone and they type every field by hand, even though their browser knows their address. Or autofill drops their email into the phone field. Or you added autocomplete="off" to stop suggestions on a field and they keep appearing. All three come down to what the browser can work out about each field, and the autocomplete attribute is the one place where you tell it directly.

To see how much it matters, we took Chromium 153 and filled one saved test address for Emma Clarke in Leeds into twelve versions of the same eight-field form, using Chrome's own autofill engine through its developer protocol. Chrome reported for every field whether it was filled because of the attribute or because it guessed. Then we sent two of the filled forms to a local copy of Formgong's form backend.

Does Chrome need the autocomplete attribute to fill a form?

The surprise is how well Chrome guessed. With readable names or proper labels, it filled 8 of 8 without a single token. That fits with the HTML label article: the label is what Chrome reads when the name is meaningless. Take the labels away as well and it filled 0 of 8, and the tokens alone brought that back. So the attribute is insurance for the forms that are hardest to read, such as generated names, fields labelled by a nearby <span>, or text in another language.

Two details showed what a token changes even when Chrome could have guessed. The phone came through as +441134960000 with autocomplete="tel" and as 01134960000 without it, so the token chose the international format. And a token beats Chrome's own reading of the field: the phone field we marked autocomplete="email" got the email address. A wrong token is worse than none.

Does autocomplete="off" stop autofill?

Not for addresses in our test. With off on every field, or once on the <form>, Chromium still filled 8 of 8 from the saved address. Splitforms' autocomplete guide explains why: Chrome treats off as advice on fields it recognises as identity or address fields, because so many sites used it to block autofill people wanted.

A made-up value, autocomplete="nope", is a different story. It stopped 7 of the 8 fields, and only the field we clicked was filled. That trick appears in a lot of answers online. It works today in this one browser, it is not part of any standard, and it makes your form harder to fill for every visitor, so use it only on a field where an old value would do harm, like a one-off booking reference.

Can autofill fill fields people cannot see?

Yes, and they are sent. This matters if you hide fields with CSS, because whatever autofill puts into them goes to your server. We built a newsletter form with one visible email field and five hidden fields carrying address tokens, filled it with the saved address, and posted it.

3 of the 5 hidden fields were filled, and the street, postcode and company name reached Formgong without the visitor ever seeing them. The honeypot from our form generator, off screen with autocomplete="off" and the name botcheck, stayed empty: Chrome did not recognise it as any kind of personal data. Splitforms' autocomplete guide, dated 12 July 2026, says Chrome and Firefox leave out fields with zero dimensions; in Chromium 153 our 0 by 0 field was filled. If a field is not meant to be filled, remove it, use type="hidden", or hide it with display:none. Keep a honeypot spam trap named and labelled like nothing a person would have saved, as the trap in our accessible contact form checklist is.

Which autocomplete values should a form use?

For a contact or order form, a short list covers almost everything: name, email, tel, organization, street-address, address-level2 for the town, postal-code and country-name. Split names use given-name and family-name. Sign-up forms need new-password, sign-in forms current-password, and a code from a text message one-time-code. Pair each with the right input type, which our HTML input types article measured.

For a separate shipping and billing address, the standard adds shipping or billing before the token. In our test that did not change the fill: from the shipping name, Chrome filled the 3 shipping fields and left the 3 billing fields empty, with the prefixes and without them. The prefixes still tell the browser which saved address belongs where, so keep them.

Two things the attribute does not do. It sends nothing: the request Formgong received was the eight values, with no sign of which were typed and which were filled. And it is not shown to screen readers; Chromium's accessibility tree for the email field was identical with and without the token. Firefox and Safari have their own autofill, which Playwright cannot drive, so we did not measure them.

Which form generators add autocomplete for you?

The markup below is the field set we would use, with tokens on everything a person has saved and off only on the one-off reference. It posts to Formgong, a form backend that sends each submission to your email or Telegram, once you add the action and key from the HTML forms docs.

The HTML form generator writes these tokens on its own for name, email, phone, company, first and last name. When we tested the 7 generators on Google's first page that show their code, on 2 November 2026, 0 of 7 set autocomplete on name or email. The guides are a different matter. Splitforms' guide has a full token reference and a complete example, and Static Forms' autofill guide, dated 16 June 2026, has a copy-ready form with tokens too, so the advice is not ours alone; the small advantage is that our generator writes the tokens without you looking them up. It has no address fields yet, so for an address you add the tokens above yourself.

<label for="name">Full name</label>
<input type="text" id="name" name="name" autocomplete="name" required>

<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email" required>

<label for="phone">Phone</label>
<input type="tel" id="phone" name="phone" autocomplete="tel">

<label for="company">Company</label>
<input type="text" id="company" name="company" autocomplete="organization">

<label for="street">Street address</label>
<input type="text" id="street" name="street" autocomplete="street-address">

<label for="postcode">Postcode</label>
<input type="text" id="postcode" name="postcode" autocomplete="postal-code">

<!-- A one-off code nobody should have saved: no token, nothing to fill. -->
<label for="ref">Booking reference</label>
<input type="text" id="ref" name="ref" autocomplete="off">

Did autofill fill your form differently?

If Chrome, Safari or Firefox fills one of these fields differently for you, or a password manager ignores a token, write to support@formgong.com. We will try your form and add the case to the table.