Autocomplete Attribute

Element Code: PE-032

What the autocomplete attribute does

The autocomplete attribute is a hint you put on an input, textarea, or select that tells the browser exactly what kind of data the field expects. When it is right, the browser can offer to fill in a saved email, name, address, or card number with one tap. When it is missing or wrong, the browser guesses, and its guesses are often bad: it drops the wrong value in the wrong box, or offers nothing at all.

The values are not free text. There is a defined set of tokens in the WHATWG HTML standard: name, given-name, family-name, email, tel, street-address, postal-code, cc-number, cc-exp, one-time-code, and many more. You can also prefix with a scope like shipping or billing, for example autocomplete="shipping postal-code". Use the real tokens. Made up values do nothing useful.

This check flags fields where autocomplete is used incorrectly: a nonstandard value, the wrong token for the field, or autocomplete disabled where autofill would genuinely help the user.

Why it matters, including for SEO

Autocomplete is not a ranking factor, so let me be honest about the mechanism. It matters because it moves the numbers Google increasingly cares about: real user experience and conversion.

• Speed and friction. Correct autocomplete lets a mobile user fill a checkout in seconds instead of thumb typing an address. Less friction means fewer abandoned forms. On mobile, where typing is painful, this is one of the highest leverage form fixes there is.
• Accessibility and compliance. WCAG 2.1 success criterion 1.3.5, Identify Input Purpose, specifically requires the autocomplete attribute on fields collecting user information. Miss it and you fail an accessibility audit, which is a legal and reputational risk, not just a nice to have.
• Conversion, which feeds everything. Faster, less error prone forms convert better. Better engagement and completion signals are exactly what you want feeding your quality and behavior metrics.

Right token, wrong token

The tokens you will use most

When to turn it off

Sometimes off is the right answer. Use autocomplete="off" on fields where saved data would be wrong or a privacy concern: a shared kiosk, a one time verification field you do not want cached, or a search box where offering the last address makes no sense. Do not blanket disable autocomplete across a whole checkout because you think it looks tidier. That is a self inflicted wound on conversion. Off should be a deliberate exception, not the default.

One real gotcha: browsers increasingly ignore autocomplete="off" on login and password fields because password managers override it for user safety. Do not fight that. Let password managers do their job.

How to detect the problem

1. Manual autofill test. Save an address and card in your browser, then run through your own forms. Anything that does not offer to fill, or fills the wrong box, has a token problem. This five minute test catches most issues.
2. Accessibility audits. Run Lighthouse in Chrome DevTools or axe DevTools. Both flag inputs missing a valid autocomplete under WCAG 1.3.5. Lighthouse has a specific audit for this.
3. Crawl and extract. In Screaming Frog or Sitebulb, use custom extraction to pull every input and its autocomplete value across the site, then scan for missing or nonstandard tokens at scale.
4. DevTools console and validators. The HTML validator and browser console warnings will call out obviously invalid values.
5. Analytics on form fields. If a specific field has high abandonment or correction rates, a bad autocomplete token is a prime suspect.

How to fix it, step by step

1. List every form field that collects user data: contact forms, checkout, signup, account settings.
2. Map each field to its standard token from the WHATWG list. Match by meaning, not by your internal field name.
3. Add scope where a form has both addresses, for example autocomplete="shipping street-address" and autocomplete="billing street-address", so the browser fills the right block.
4. Replace nonstandard values. Swap your-email for email, zip for postal-code, and so on.
5. Set off only where justified, and document why so nobody re-enables it blindly.
6. Retest with real saved data and rerun Lighthouse to confirm the field level warnings are gone and autofill works.

Do this, not that

What good looks like

Every data collecting field carries the correct standard token, address fields are scoped where needed, autofill works in one tap on mobile, off is used only where genuinely warranted, and Lighthouse reports a clean pass on Identify Input Purpose. Users breeze through your forms and your completion rate shows it.

FAQ