autocomplete="off" Not Working? Why Browsers Ignore It (and Fixes)

The symptom: you set off, the browser fills anyway

You add autocomplete="off" to a login form, a checkout address block, or a profile editor. On reload, Chrome or Edge still drops in a saved password, a full mailing address, or an old email from the autofill profile. DevTools shows the attribute on the element, so it feels like the browser is broken or your framework stripped the attribute.

The same thing happens when you set off on the parent <form> and expect every child to stay empty. Password managers and built-in autofill still offer values, especially on fields named email, username, password, address, or city. That behavior is intentional, not a regression you can fix with more copies of off.

<form autocomplete="off" action="/login" method="post">
  <label>Email
    <input type="email" name="email" id="email" autocomplete="off" />
  </label>
  <label>Password
    <input type="password" name="password" id="password" autocomplete="off" />
  </label>
  <button type="submit">Sign in</button>
</form>
<!-- Chrome may still autofill email and password -->

Why browsers ignore autocomplete="off"

The HTML autocomplete attribute is a hint about what kind of data belongs in a field. Browsers and password managers use that hint—and heuristics from type, name, id, and labels—to match saved profiles. For years, sites abused autocomplete="off" on real login and address fields to block the autofill UI for cosmetic reasons. That made password managers unreliable, so Chromium, Firefox, and Safari changed course: on fields they classify as credentials, identity, or payment, off is treated as advisory and often overridden.

That is the password-manager rule in practice. If the browser thinks a field is a username, current password, new password, street line, postal code, or card number, it will try to help the user fill it from saved data unless you use a specific standard token (for example username, current-password, or shipping street-address) or a token meant for a special case like one-time codes. Generic off does not win that argument on those field classes. Our HTML autocomplete attribute guide walks through every standard token; this article focuses on what to do when off fails.

Heuristics still matter when autocomplete is missing or wrong. An <input type="email" name="email"> is treated like an email field even with off. A text box labeled "Address" with name="address" triggers address autofill. Credit-card autofill looks for autocomplete tokens starting with cc- or familiar name patterns. Fighting those signals with off alone is why so many bug reports stay open as "working as intended."

Fixes that actually work

Start by choosing the right token instead of off. For sign-in, use autocomplete="username" and autocomplete="current-password" on the password input so managers know which saved entry to offer. For registration or change-password flows, use autocomplete="new-password" on the new password field so the browser suggests generating or saving a new credential instead of reusing the login password for the wrong field.

<label>New password
  <input
    type="password"
    name="new_password"
    autocomplete="new-password"
    required
  />
</label>
<label>Confirm new password
  <input
    type="password"
    name="confirm_password"
    autocomplete="new-password"
    required
  />
</label>

For SMS or app OTP fields, use autocomplete="one-time-code". Mobile Safari and Chrome on Android can read a code from an incoming message and offer to fill the field—behavior you want, unlike stale saved text. Pair it with inputmode="numeric" and type="text" so leading zeros are preserved.

<label>Verification code
  <input
    type="text"
    name="otp"
    inputmode="numeric"
    autocomplete="one-time-code"
    maxlength="6"
    pattern="[0-9]{6}"
  />
</label>

When the field is not an email or address but looks like one to heuristics, change the signals. A site-wide search box should use type="search", a neutral name such as q, and autocomplete="off". Avoid name="email" or id="address" on unrelated controls; those names are autofill magnets.

<form role="search" action="/search" method="get">
  <label for="site-search">Search docs</label>
  <input
    id="site-search"
    type="search"
    name="q"
    autocomplete="off"
    placeholder="Search…"
  />
</form>

Some teams try invented tokens—autocomplete="nope", autocomplete="false", or a random word—expecting the browser to skip autofill. That is unreliable: engines may ignore unknown tokens, fall back to heuristics, or still map the field to a login type. It can also confuse assistive tech and password managers. Prefer documented tokens from the spec, or redesign the field so it is not mistaken for identity data.

Form-level vs field-level: HTML allows autocomplete on the <form> element as a default for controls that do not set their own value. In modern browsers, descendants with explicit tokens override the form default. For mixed forms (billing plus a one-off coupon code), set precise tokens on each input rather than relying on a single off on the form—login and address children may still autofill despite the form hint.

• Login: username + current-password, not off.
• Signup / reset: new-password on new password fields.
• OTP: one-time-code.
• Search or internal IDs: neutral name/id, appropriate type, off only when the field is genuinely one-off.

When you should not disable autofill

Contact and lead forms are the opposite problem: autofill raises completion rates and cuts mobile typos. Name, email, phone, and company fields should use matching autocomplete tokens (name, email, tel, organization) so visitors can fill the form in a few taps. Stripping autofill to make the layout look "clean" often drops submissions with no security upside—your server must validate either way.

If you are optimizing a marketing or support form, read how autofill interacts with conversion in our contact form conversion rate article. Use off only where saved values would be wrong: a unique ticket subject, a one-time promo code, or message body text that should not repeat last time's draft.

Firefox, Safari, and Chromium differences

All major engines share the same broad rule: do not let off break password managers on credential fields. Chromium (Chrome, Edge, Brave) is the strictest about overriding off on login and address autofill; their public bug threads describe the user-impact decision explicitly. Safari on iOS and macOS honors one-time-code aggressively for SMS OTP and integrates with Keychain for passwords when tokens are correct.

Firefox generally respects standard autocomplete tokens and still fills many identity fields when off is present, but developers often report slightly higher odds that off sticks on non-standard text fields compared to Chrome. Safari can autofill contact fields from the system Contacts card when tokens align. None of them guarantee that off alone keeps a field empty across versions—test on real devices when behavior affects checkout or compliance copy, not just desktop Chrome.

FAQ