Guidance for disabling browser autofill in data-entry forms

[shreyam1008]

I’m using TanStack Form for an internal data-entry app. One operator enters records for many different people on the same browser. Chrome and Safari may suggest the operator’s saved address, password managers attach to password fields, and normal inputs offer values from previous records. That makes it easy to put one person’s data into another record.

Today I add autocomplete="off" to the form and individual inputs:

<form autoComplete="off">
  <form.Field name="address.line1">
    {(field) => (
      <input
        name={field.name}
        autoComplete="off"
        value={field.state.value}
        onChange={(e) => field.handleChange(e.target.value)}
      />
    )}
  </form.Field>
</form>

This is inconsistent across browsers and password managers, and easy to miss in reusable field components.

Since TanStack Form is headless, I’m not expecting it to override browser behavior. Could the docs include a recommended best-effort pattern for this use case, covering address, password, and ordinary text fields, plus the limits that cannot be controlled? A small example using shared field components would be enough.

[MILLERMARRU]

Since this is browser/password-manager behavior rather than anything TanStack Form controls, the reliability ceiling is set by Chrome and Safari's heuristics, not the form library, but there's a more consistent pattern than plain autocomplete="off", which browsers have increasingly started ignoring for password-adjacent fields specifically.

• Ordinary text/address fields: autocomplete="off" mostly works here, Chrome respects it for non-credential fields more reliably than for login-shaped ones. Randomizing the name attribute per record (e.g. name={address-line1-${recordId}}) is the more bulletproof fallback, since autofill heuristics key heavily off name/id values, a name that doesn't look like a stable, repeated field is much less likely to get suggestions attached to it.
• Password fields: autocomplete="off" is well known to be ignored by Chrome/Safari's password managers. The documented working alternative is autocomplete="new-password", browsers treat that as "don't offer a saved credential here" even though it's semantically meant for signup forms, it's become the de facto way to suppress save-prompts and autofill on a password field that isn't a login form.
• Address autofill specifically: setting autocomplete="off" on the <form> element only, without repeating it per-field, is what tends to leak through in Chrome, autofill in Chrome largely ignores the form-level attribute and evaluates each field's own autocomplete value, so your reusable field component needs to accept and forward its own autocomplete prop rather than relying on inheritance from the wrapping <form>.

None of this is airtight across every browser/password-manager combination, that limit is real and worth documenting as-is rather than promising a fix, per-field autocomplete="new-password" (for anything credential-adjacent) plus randomized name attributes (for everything else) is the most consistent combination people land on for exactly this kind of shared-browser data-entry scenario.