HTML Autocomplete Attribute: Controlling Browser Autofill

The autocomplete attribute in HTML tells the browser whether it can offer to autofill a form field, and what type of data belongs there. Set it to on or a specific value like email to help browsers pre-fill saved data, or set it to off to stop autofill entirely on fields where saved suggestions would be wrong or unsafe.

It sounds simple, but the difference between a smooth checkout and a frustrated user often comes down to whether you gave the browser the right autocomplete value. Let's break down exactly how it works and when to use each setting.

How the autocomplete attribute works

Browsers keep a stash of data users have entered before: names, addresses, credit cards, and login details saved in a password manager. The autocomplete attribute is your instruction to the browser about whether it may tap into that stash for a given input and, more usefully, which piece of saved data fits.

You attach it directly to an <input>, <textarea>, or <select> element:

<input type="email" name="email" autocomplete="email">
<input type="text" name="fname" autocomplete="given-name">
<input type="password" name="pw" autocomplete="current-password">

When you use a named token like given-name, the browser matches the field to the correct saved value instead of guessing from the field's name or id. That's the whole point: precise tokens produce accurate autofill, and vague or missing ones lead to browsers dumping the wrong value into the wrong box.

Common autocomplete values

The HTML specification defines a long list of named tokens. Here are the ones you'll reach for most often:

Two of these deserve special attention. Use current-password on login forms so password managers offer the saved credential, and new-password on signup and password-change forms so the browser suggests a fresh, strong password instead of pasting the old one. Mixing these up is one of the most common reasons password autofill misbehaves.

When to use autocomplete off

Setting autocomplete="off" tells the browser to stop offering suggestions for a field. It's the right call in a few specific situations:

• One-time or sensitive codes that should never be stored, though one-time-code is often better here.
• Fields with dynamic or search-driven values where a saved suggestion would clutter the UI. A datalist-driven suggestion list is usually the smarter choice than fighting native autofill.
• Data unique to each entry, like a coupon code or a captcha answer, where autofilling a past value is meaningless.

Form-level vs field-level control

You can set autocomplete on the <form> element itself to establish a default for every field inside it, then override individual inputs as needed:

<form autocomplete="off">
  <input type="text" name="search">
  <input type="email" name="email" autocomplete="email">
</form>

Here the form defaults to off, but the email field opts back in. Field-level values always win over the form-level setting. This pairs well with other form structure decisions, like grouping related inputs inside a fieldset with a legend for clearer semantics and accessibility.

The attribute controls autofill behavior only. It has nothing to do with where the form submits, which is handled by the form action attribute, or with validation rules you might set with the pattern attribute.

Autofill and security concerns

Autofill security cuts both ways. Password managers make strong, unique passwords practical, which is a big win. But careless markup can leak data:

• Hidden field harvesting. Attackers have used off-screen fields with autofill-friendly names to silently pull a user's saved address or email. Avoid hidden inputs that request personal data tokens.
• Wrong-field fills. Vague field names can cause a browser to drop a credit card number into a visible, loggable field. Explicit tokens like cc-number reduce this risk.
• Always use HTTPS. Some browsers refuse to autofill credentials on non-secure pages, and for good reason.

Common gotchas and browser quirks

• Chrome ignores autocomplete="off" on login forms. If you truly need to prevent a specific suggestion, a non-standard token value is sometimes used, but expect inconsistent results across browsers.
• Autofill styling. Browsers apply their own yellow or blue background to autofilled fields. You can adjust it with the :-webkit-autofill pseudo-class if it clashes with your design.
• Single-input address fields fail. Autofill works best when you split names and addresses into their standard tokens rather than one giant text box.
• Textarea autofill. A textarea can carry autocomplete tokens too, useful for multi-line address fields.

Build forms that autofill cleanly, every time

Getting the autocomplete attribute right is one piece of a solid form. Our HTML guide walks through the markup and best practices that make browser autofill and validation work together.

Read the HTML guide →