Autofill and autocomplete

You have probably typed your address into a form 200 times. The browser knows it. Your password manager knows it. The only reason it does not auto-fill is that your form has not told the browser what each field is.

The vehicle for that information is the autocomplete attribute. It is not just on or off — it is a long list of named values, each describing a piece of personal data. Get them right and the user fills the whole form with one tap.

The token list

The autocomplete attribute takes a single token (or sometimes a space-separated list). Each token describes the kind of data the field holds.

<input name="name" autocomplete="name">
<input name="email" autocomplete="email">
<input name="tel" autocomplete="tel">
<input name="url" autocomplete="url">

The tokens are pre-defined in the HTML spec — you cannot make them up. The browser only fills fields it recognizes by token, not by name. That is why a field called name="email_address" without the autocomplete attribute is invisible to autofill.

A short list of common tokens:

• name — full name. Or split: given-name (first), family-name (last), additional-name (middle).
• email — email address.
• tel — phone, full international format. Or tel-national, tel-country-code, tel-area-code.
• url — a URL.
• organization — company name. organization-title for job title.
• bday — birthday, full date. Or bday-day, bday-month, bday-year.

Pick the most specific token that matches the field. name versus given-name matters when the form splits first and last names into two inputs.

<label>First name <input name="first" autocomplete="given-name"></label>
<label>Last name <input name="last" autocomplete="family-name"></label>

The autofill suggestion now lands the right name in the right field. Without the tokens, the browser would have to guess.

Username and password sections

Password managers care about three tokens above all others.

• username — the username or email used to log in.
• current-password — the password the user is currently logging in with.
• new-password — the password the user is creating or changing to.

The distinction between current-password and new-password is what makes password managers work cleanly:

<form action="/login" method="post">
<label>Email <input name="email" autocomplete="username"></label>
<label>Password <input type="password" name="pw" autocomplete="current-password"></label>
<button type="submit">Log in</button>
</form>

The password manager sees current-password and offers to fill the saved password. It does not offer to generate a new one — that would be wrong here.

<form action="/signup" method="post">
<label>Email <input name="email" autocomplete="username"></label>
<label>Password <input type="password" name="pw" autocomplete="new-password"></label>
<label>Confirm <input type="password" name="pw2" autocomplete="new-password"></label>
<button type="submit">Sign up</button>
</form>

Same form skeleton, different tokens. The password manager now offers to generate a strong password and remember it. The two new-password fields tell it "this is a fresh credential being created".

For the email/username, the same autocomplete="username" token works on both forms — login and signup. The distinction is the password's token, not the username's.

Addresses, phones, payments

Address tokens use a shipping or billing prefix to disambiguate. Each address piece has its own token.

<fieldset>
<legend>Shipping address</legend>
<input name="ship_addr1" autocomplete="shipping address-line1">
<input name="ship_addr2" autocomplete="shipping address-line2">
<input name="ship_city" autocomplete="shipping address-level2">
<input name="ship_state" autocomplete="shipping address-level1">
<input name="ship_zip" autocomplete="shipping postal-code">
<input name="ship_country" autocomplete="shipping country">
</fieldset>

address-level1 is the largest subdivision (state, province), address-level2 is the next level down (city). The naming is unintuitive but standardized — copy it from a reference card and move on.

For payments, the spec defines a parallel set of cc-* tokens.

<input name="card" autocomplete="cc-number" inputmode="numeric">
<input name="exp" autocomplete="cc-exp" placeholder="MM / YY">
<input name="cvc" autocomplete="cc-csc" inputmode="numeric">
<input name="name" autocomplete="cc-name">

Apple Pay, Google Pay, and most password managers fill these directly. A user with a saved card sees a "fill from saved card" option in their browser's autofill bar — three taps replaces six.

The full reference list of tokens is in the HTML spec. Skim it once, bookmark it, and you have the table you need for any form you build.

When to turn it off

Sometimes you want autofill off. For example, a "Type the word DELETE to confirm" field — the browser should not offer to fill it.

<input name="confirm" autocomplete="off" required>

autocomplete="off" tells the browser not to suggest values. It does not prevent password managers from acting (they can override the hint). For the password-specific case, autocomplete="new-password" tends to be better than off — it tells the manager "do not fill the saved password here", which is usually what you actually want.

Browsers sometimes ignore autocomplete="off" on login fields, on the theory that users are better served by their saved passwords than by a developer's preference. That's a feature, not a bug. Plan around it: do not put critical UX on the assumption that autofill is silent.