Nonstandard field names make autofill land in the wrong fields

What it is

Browsers guess whether a field is a name, an address, or a card from name, id, the visible label, and autocomplete hints. Nonstandard naming means those clues fight each other or use internal codes (input1, txt_3, an email box called username), so a home address lands in “Company” and a card number lands in “Member ID.” This is a mapping error, not a stale app profile, and not two sources racing to write. Fill into hidden fields, and whether people can override a wrong fill, are the next two steps.

Why it happens

Autofill is heuristic: standard autocomplete tokens first (given-name, address-line1, cc-number), then English words in name/id, then neighboring label text. Internal codes contain none of those words, so the browser falls back to “the nth text box looks like an address.” Two “Name” fields on one form—cardholder and recipient—both called name often receive the same string. A second layer is framework-generated names. A server list renders items[2].street; the heuristic sees street and writes the address into the third line of item notes. Once mismatched, validation may still pass (both are legal address formats); the error explodes at fulfillment. People rarely notice, because the box “looks like an address.” autocomplete="off" is often ignored on sign-in and address fields and cannot replace naming; correct tokens are more reliable than turning fill off.

Studying it

Store one address and one card in a clean browser profile, open forms with different naming, and record which value type actually landed in each field.

Independent variables: whether autocomplete tokens are standard, whether name/id are semantic, whether one form has two groups of synonymous fields, whether label copy agrees with the token. Dependent variables: mismatches (address in phone, card in member ID), whether people notice before submit, fulfillment errors.

Do not use a developer’s own profile—those fields have already been “learned.” Use a fresh profile or a private window plus a new address. Turn app prefill off, or you cannot tell who wrote.

Where it stops holding

Custom controls (canvas, contenteditable divs) have no autocomplete hook; the browser will not fill, so mismatch does not occur—what is missing is fill itself. Localized forms with non-Latin labels and no English name have weaker heuristics and depend even more on explicit tokens. Password managers are more conservative on username/password than on address, but naming an OTP box password still triggers a password fill. If the server only accepts codes and the front end uses tokens, both names must be semantic; pretty labels are not enough.

Applying it

• Put a standard autocomplete token on every fillable field. Token, visible label, and name must name the same thing.
• Distinguish two address groups or two names on one form with different tokens (shipping versus billing prefixes). Do not call both name.
• Do not use input1, framework subscripts, or username for email. off does not replace a correct token.
• Verify with a new browser profile holding one address and one card: open the form and check each field received its own type. Set shipping name and cardholder name both to name as a required mismatch control. Turn app prefill off and repeat, confirming the mismatch came from the browser, not a profile script.

Related

• Within the group: H1.13.1 Browser autofill and in-app prefill have different sources and must be handled apart · H1.13.3 Autofill into hidden fields can harvest data and must be scoped · H1.13.4 Autofill results must remain manually overridable
• Adjacent: E2.01 Single-line text fields · H1.10 Structured information input · H1.09 Smart prefill
• Search terms: autocomplete token · autofill mismatch · heuristic