HTML autocomplete Attribute

What is the autocomplete attribute?

The autocomplete attribute tells the browser what a form field is for, so it can fill it from what it already knows about the person using it. Writing autocomplete="given-name" on an input is the difference between a browser offering somebody's first name and offering nothing at all.

The vocabulary is larger and more structured than most people use. The HTML Standard defines 54 field names, from the obvious ones like email and postal-code to cc-exp-month, honorific-suffix, transaction-currency and one-time-code. Alongside them are 10 hint tokens that qualify a field name rather than replacing it — shipping, billing, home, work, mobile, fax, pager, a section grouping token, and the bare values on and off. There is also exactly one credential type, webauthn, which is appended after a field name and is what makes a browser offer a passkey.

Order matters and is fixed: an optional section token, then shipping or billing, then a contact hint, then the field name, then the credential type. This page parses whatever you paste and tells you which of those slots each token filled.

How to use it

1. Paste the value you have written. Just the attribute's value, not the whole tag. The four sample buttons cover a postal address, a passkey login, a value with the tokens in the wrong order, and a typo.
2. Read the control group. This is the useful part. The specification assigns every field name to a kind of control, and the tool says which one and what that means in practice.
3. Check the problems, if any. An unrecognised token, a hint in the wrong place, a missing field name, or a section token with nothing after it. All of these are silent in a browser — nothing warns you.

The control group is the part everyone drops

Look up the autocomplete values anywhere and you will get a list of tokens with a sentence of meaning each. What that leaves out is normative and immediately useful: the specification also assigns every field name to a control group, and the group tells you what kind of input the token belongs on.

The one worth knowing first is street-address, which is in the multiline group. It is meant for a textarea, because a postal address does not fit on one line. If you want single-line inputs you want address-line1, address-line2 and address-line3, which are in the text group. Putting street-address on a single-line input is the commonest mistake this page can show you, and nothing in a browser will mention it.

The date-shaped tokens split the same way. bday is in the date group and belongs on an input of type date, because it is a whole year, month and day. bday-day and bday-year are in the numeric group — they are single numbers and belong on numeric inputs. cc-exp is in the month group, which is a year and a month together, while cc-exp-month is numeric. Four tokens that all look like dates, three different kinds of control.

A few more that surprise people: one-time-code is in the password group, not the numeric one, which is what lets a browser offer a code it has just seen arrive. photo and impp are both in the url group, because their values are addresses rather than names. And cc-number is in the text group rather than numeric, since a card number is a string of digits and not a quantity.

What autocomplete=off actually promises

Less than its reputation suggests, and it is worth being exact. The specification says that when a field's autofill field name is off, the user agent should not remember the control's data and should not offer past values. That is a should, not a must. A browser that remembers anyway is still conforming.

It is equally worth saying what the specification does not contain, because this is where a lot of writing on the subject overreaches. There is no clause permitting browsers to ignore off on password fields. The section does not mention password managers, and it does not mention phishing. The should is the whole of it. Browsers do behave in ways that people describe as ignoring off, and that behaviour is real, but it is not something the standard authorises in the text — so this page does not claim that it does.

The practical reading is simple enough. off is a request, not a control. If a value must not be stored, the attribute is not the mechanism that guarantees it.

Honest limitations

This checks a value, not a page. It cannot see which element the attribute is on, so it can tell you that street-address belongs on a textarea but not that yours is on an input. That is the check that would catch the most real mistakes and it needs your markup, not your attribute value.

Nor can it tell you whether a browser will actually fill the field. Autofill depends on what the browser has stored, on heuristics that vary between browsers, and on the surrounding form — a correct attribute makes the right behaviour possible rather than certain.

The vocabulary is a snapshot. The specification adds to it: webauthn is a recent arrival, and one-time-code is newer than much of the writing you will find about this attribute. The list here is generated from the standard rather than typed out, which makes it straightforward to regenerate, but it is still the standard as it stands today.

One note on how that list was built, because it affected what this page can claim. The specification's own table uses merged cells in both directions — it has a class named for non-rectangular indentation — so it cannot be read by position, and a positional read produces a table that looks right and is wrong. The data here comes from the specification's definition anchors instead, with the extraction checked against tokens whose answers were known in advance.

Why is it free?

The list is static and the parsing runs in your browser. There is no server involved, so there is nothing to bill for and no account to create.

Nothing is uploaded and nothing is stored. Reload the page and it has forgotten what you typed.