Autocomplete and Name Attributes

Browsers and password managers key off name, id, autocomplete, and nearby labels to fill forms correctly. Inventing name="field1" or disabling autocomplete “for security theater” creates support tickets and accessibility friction.

Docs: MDN autocomplete, HTML autofill, MDN forms.

name is the form’s wire format

<form method="post" action="/register">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required />

  <label for="new-password">Password</label>
  <input
    id="new-password"
    name="password"
    type="password"
    autocomplete="new-password"
    required
  />

  <button type="submit">Create account</button>
</form>

• name — key in submitted form data (FormData, POST body).
• id — label association and fragment scripting.
• They can match but serve different jobs.

Unnamed controls are not successful controls — they won’t appear in submission.

autocomplete tokens that matter

Token	Use
name	Full name
given-name / family-name	Split names
email	Email
username	Login id
new-password / current-password	Registration vs login
tel	Phone
street-address, address-line1, postal-code, country	Address
cc-number, cc-exp, cc-csc	Payments (PCI considerations apply)
one-time-code	OTP SMS autofill
off	Request no autofill (not always honored)

<input
  name="otp"
  inputmode="numeric"
  autocomplete="one-time-code"
  pattern="[0-9]*"
/>

Sectioning tokens exist (shipping , billing , section-…) for multi-address forms — see the HTML spec list.

Login vs signup passwords

<!-- Login -->
<input type="password" name="password" autocomplete="current-password" />

<!-- Signup -->
<input type="password" name="password" autocomplete="new-password" />
<input type="password" name="password_confirm" autocomplete="new-password" />

Wrong tokens make managers offer the old password on signup or fail to save new ones.

Why “autocomplete=off” fails product goals

Browsers ignore off in many login cases intentionally. For sensitive one-off fields, prefer correct semantics and backend security (CSRF, rate limits), not fighting autofill. For internal admin tools that must avoid storing values, still test real browsers — results vary.

Dynamic forms (SPA)

When fields mount late:

1. Keep stable name/autocomplete
2. Don’t recycle one input for email then password without remounting
3. Ensure labels remain associated after re-renders

Password managers inspect the DOM at specific times; flaky mounting breaks them.

Interview out-loud

“name defines submitted keys; autocomplete tells browsers and password managers the field’s meaning. I use the standard tokens for email, passwords, addresses, and OTP. Login uses current-password, signup new-password. I don’t rely on random names or blanket autocomplete off as security.”

Footguns

1. Missing name on controlled React inputs that only use id.
2. Same name on conflicting fields in one form without array intent.
3. Custom select components that don’t forward hidden native inputs for autofill.
4. Using placeholder as the only label.
5. Credit-card fields without understanding PCI scope.

Shipping address block

<fieldset>
  <legend>Shipping address</legend>
  <label for="ship-name">Full name</label>
  <input id="ship-name" name="shipping_name" autocomplete="shipping name" />

  <label for="ship-line1">Address</label>
  <input id="ship-line1" name="shipping_line1" autocomplete="shipping address-line1" />

  <label for="ship-city">City</label>
  <input id="ship-city" name="shipping_city" autocomplete="shipping address-level2" />

  <label for="ship-postal">Postal code</label>
  <input id="ship-postal" name="shipping_postal" autocomplete="shipping postal-code" />
</fieldset>

The shipping token scopes autofill when billing fields exist on the same page. Mirror with billing for payment address. Test with real browser autofill profiles — synthetic QA accounts often miss these bugs.

Related

• Forms labels and inputs
• Form validation attributes
• Input types for mobile keyboards
• Accessible forms errors

Further reading

• autocomplete — MDN
• Autofill — HTML living standard
• Creating accessible forms — WAI

Related guides

• fieldset and legendGroup related form controls with fieldset/legend — radio groups, disabled fieldsets, and accessible naming for control sets.
• Form Validation AttributesNative constraint validation — required, type, pattern, min/max, minlength/maxlength, and wiring :invalid with accessible errors.
• Forms, Labels, and InputsWire labels to controls correctly, choose input types, group fields, and avoid the accessibility bugs that fail real users and audits.
• Accessibility Tree OverviewHow browsers build the accessibility tree from DOM and CSS — roles, names, states, what’s pruned, and how to inspect it in DevTools.
• Audio and Video ElementsNative audio/video — controls, sources, captions, autoplay policies, and accessibility requirements for media on the web.