# HTML autocomplete attribute, tested with Chrome autofill

What the autocomplete attribute tells browser autofill, which values to use, why autocomplete=off did not stop Chrome, and what hidden fields leak.

Author: Formgong
Published: 2026-11-03
Language: en
Canonical: https://formgong.com/en/blog/html-autocomplete-attribute/

The autocomplete attribute tells the browser what a field is for, such as name, email, tel or postal-code, so autofill can put the right saved value in it. It changes nothing in what the form sends. In our Chromium test on 3 November 2026, a form with tokens got 8 of 8 fields right, and with autocomplete="off" on every field Chrome still filled 8 of 8.

## 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?

One saved address filled by Chromium 153's autofill engine into each form variant, 3 November 2026. “Right” means the field got the saved value it was meant for.
Form variantFields filled correctly
Tokens on every field, readable names, labels8 of 8 right, filled “by autocomplete attribute”
No tokens, readable names (`email`, `postcode`) and labels8 of 8 right, inferred
No tokens, names `f1` to `f8`, labels8 of 8 right, inferred from the labels
No tokens, names `f1` to `f8`, no labels0 of 8
Tokens, names `f1` to `f8`, no labels8 of 8 right, filled “by autocomplete attribute”
`autocomplete="off"` on every field8 of 8 filled anyway
`autocomplete="off"` on the form element8 of 8 filled anyway
`autocomplete="nope"` on every field1 of 8: only the field that was clicked
Phone field marked `autocomplete="email"`The phone field got the email address
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](/en/blog/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.

Hidden fields in the same form as a visible email field, Chromium 153, 3 November 2026.
How the field was hiddenWhat happened
`display:none`Not filled
`visibility:hidden`Not filled
`opacity:0`Filled with the street, and sent
Moved off screen, `left:-9999px`Filled with the postcode, and sent
Zero size, 0 by 0 pixelsFilled with the company name, and sent
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](/en/blog/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](/en/blog/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](/en/docs/html/).

The [HTML form generator](/en/tools/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.

```html
<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](mailto:support@formgong.com). We will try your form and add the case to the table.

## Frequently asked questions

### What does the HTML autocomplete attribute do?

It tells the browser what a field is for, such as email or postal-code, so autofill can offer the right saved value. It does not change what the form sends.

### Why doesn't autocomplete="off" work?

Chrome treats it as a hint on fields it recognises as names, addresses or contact details. In our test it filled 8 of 8 such fields anyway.

### Which autocomplete value should I use for a phone number?

Use tel on an input with type="tel". In our test it also made Chrome fill the number in international format.

### Can autofill fill hidden fields?

Yes. Fields hidden with opacity, off-screen positioning or zero size were filled and sent. display:none and visibility:hidden were not.

## Sources and documentation

- [Formgong: Accessible contact form checklist for WCAG 2.2](https://formgong.com/en/blog/accessible-contact-form/)
- [Formgong: HTML input types and what each one sends](https://formgong.com/en/blog/html-input-types/)
- [HTML forms](https://formgong.com/en/docs/html/)

[Get a form key](https://formgong.com/en/#top)