How to Disable Browser Autocomplete on Form Inputs in HTML

By the end of this page, you will understand how the HTML autocomplete attribute works, how to turn it off for a form or a specific input, why browsers sometimes ignore it, and when you should use more specific autocomplete values instead of disabling it entirely.

The core concept behind this question is the HTML autocomplete attribute.

Browsers try to help users by remembering values they have typed before, such as names, email addresses, addresses, and passwords. This feature is called autocomplete or autofill.

In HTML, you can control this behavior with the autocomplete attribute:

<form autocomplete="off">
  ...
</form>

or on an individual input:

<input type="text" name="search" autocomplete="off">

Why this matters

Autocomplete affects:

• User experience: helpful for repeated fields like email or shipping address
• Privacy: you may not want old values suggested in sensitive fields
• Data accuracy: autofill can insert unexpected values into the wrong fields
• Security expectations: developers sometimes try to disable autofill for passwords or one-time codes

Important reality

autocomplete="off" is a hint to the browser, not a strict command.

Modern browsers may ignore it in some cases, especially for:

• login forms
• password fields
• saved credentials

This happens because browsers prioritize user convenience and security features such as password managers.

Better approach in many cases

Instead of blindly disabling autocomplete, use a more specific value when possible:

<input type="email" name="email" autocomplete="email">
<input type="password" name="current-password" autocomplete="current-password">
<input type="text" name="otp" autocomplete="one-time-code">

That tells the browser what kind of data belongs in the field, which often produces better results than turning autocomplete off completely.

Think of the browser as a helpful assistant standing next to your form.

• If you say nothing, the assistant tries to guess what to fill in.
• If you say autocomplete="off", you are asking the assistant to stop suggesting remembered values.
• But the assistant may still step in for important jobs like passwords, because it believes that helps the user.
• If you give a specific instruction like autocomplete="email" or autocomplete="one-time-code", the assistant knows exactly what kind of value belongs there.

So autocomplete is less like a strict lock and more like a set of instructions for browser behavior.

Basic syntax

Disable autocomplete for one input

<input type="text" name="search" autocomplete="off">

This asks the browser not to suggest previously entered values for that field.

Disable autocomplete for a whole form

<form autocomplete="off">
  <input type="text" name="firstName">
  <input type="text" name="lastName">
</form>

This applies to form controls inside the form, unless a child input has its own autocomplete value.

Use a specific autocomplete value

<form>
  <input type="email" name="email" autocomplete="email">
  <input type="password" name="password" autocomplete="current-password">
</form>

This is often better than turning autocomplete off because it gives the browser accurate meaning.

Example: search field

A search box usually does not need saved personal autofill data.

<label for="site-search">Search</label>
<input id="site-search" type="search" name="q" autocomplete="off">

Why this example makes sense

• It is a field with temporary input
• Reusing saved address or profile data would be unhelpful
• Turning autocomplete off can reduce noisy suggestions

Example: one-time verification code

<label for="otp">Verification code</label>
<input id="otp" type="text" name="otp" inputmode="numeric" autocomplete="one-time-code">

This is a good example of not using off. A one-time code benefits from browser or mobile OS assistance.

Consider this form:

<form autocomplete="off">
  <label for="nickname">Nickname</label>
  <input id="nickname" name="nickname" type="text">

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email">
</form>

What happens step by step

1. The browser reads the <form> element.
2. It sees autocomplete="off" on the form.
3. That becomes the default instruction for fields inside the form.
4. The browser reads the nickname input.
5. Since that input has no explicit autocomplete value, it inherits the form-level behavior and is treated as off.
6. The browser reads the email input.
7. That input has its own autocomplete="email".
8. The input-level setting overrides the form-level default.
9. Result:
   • nickname is requested to avoid autocomplete
   • email is identified specifically as an email field

Key rule

A specific input can override the form's autocomplete setting.

When developers disable autocomplete

Search boxes

Search inputs often contain temporary text, so remembering old personal values is not useful.

<input type="search" name="q" autocomplete="off">

Promo codes or coupon fields

A coupon field usually should not suggest saved names, addresses, or unrelated text.

<input type="text" name="coupon" autocomplete="off">

Internal admin tools

Some back-office forms use short-lived values such as filters, IDs, or generated references.

<input type="text" name="reportId" autocomplete="off">

When developers should avoid disabling it

Login forms

Users benefit from password managers and saved credentials. Browsers may ignore off here anyway.

Checkout and profile forms

Autocomplete makes forms faster and more accurate for fields like:

• name
• email
• street address
• postal code
• phone number

One-time password fields

Use autocomplete="one-time-code" rather than off for better mobile UX.

In real projects, developers usually use autocomplete as part of a broader form design strategy rather than as a one-line fix.

Common patterns

1. Form-level default with input-level overrides

<form autocomplete="off">
  <input type="text" name="search">
  <input type="email" name="email" autocomplete="email">
</form>

This sets a general rule but still allows important fields to be explicit.

2. Semantic autofill values

Teams often prefer meaningful values over off:

<input name="givenName" autocomplete="given-name">
<input name="familyName" autocomplete="family-name">
<input name="postalCode" autocomplete="postal-code">

This improves browser compatibility and helps accessibility.

3. Validation plus autocomplete

Autocomplete does not replace validation. Real codebases combine both:

<input type="email" name="email" autocomplete="email" required>

The browser may help fill the field, but the app still validates the value.

4. Sensitive temporary fields

For short-lived values, developers often disable autocomplete and also choose clear field names and labels.

<input type="text" name="sessionNote" autocomplete="off">

5. Authentication-specific values

Instead of trying to block password managers, modern apps usually cooperate with them:

<input type="text" name="username" autocomplete="username">
<input type="password" name="password" autocomplete="current-password">
<input type="password" name="newPassword" autocomplete="new-password">

This is the modern, expected pattern.

1. Assuming autocomplete="off" always works

Broken expectation:

<input type="password" name="password" autocomplete="off">

Problem:

• Some browsers still offer saved passwords
• Password managers may still fill the field

How to avoid it:

• Treat off as a browser hint, not a guarantee
• Use correct semantic values like current-password or new-password

2. Disabling autocomplete on fields where users benefit from it

Broken approach:

<input type="email" name="email" autocomplete="off">
<input type="text" name="address" autocomplete="off">

Problem:

• Makes forms slower to complete
• Hurts user experience

How to avoid it:

• Use email, street-address, postal-code, and similar values instead

3. Putting autocomplete only on the form and forgetting overrides

<form autocomplete="off">
  <input type="email" name="email">
</form>

Problem:

• You may accidentally disable helpful browser behavior for all fields

How to avoid it:

• Add input-level values where needed

<form autocomplete="off">
  <input type="email" name="email" autocomplete="email">
</form>

4. Using non-meaningful field setup

<input type="text" name="field1" autocomplete="off">

Problem:

• Poor naming and missing semantic intent make forms harder for browsers and developers

How to avoid it:

• Use meaningful name, id, and autocomplete values when possible

5. Confusing autocomplete with validation or security

Problem:

• Disabling autocomplete does not validate data
• Disabling autocomplete does not secure sensitive data by itself

How to avoid it:

• Still validate on the client and server
• Use proper authentication and transport security practices

Form-level vs input-level

off vs specific values

• Use off when suggestions are unhelpful or distracting.
• Use specific values when the field has clear meaning.
• Prefer specific values for common user data such as name, email, address, and passwords.

<!-- Disable for one field -->
<input type="text" name="search" autocomplete="off">

<!-- Disable for a form -->
<form autocomplete="off">
  <input type="text" name="query">
</form>

<!-- Recommended semantic values -->
<input type="email" name="email" autocomplete="email">
<input type="text" name="username" autocomplete="username">
<input type="password" name="password" autocomplete="current-password">
<input type="password" name="newPassword" autocomplete="new-password">
<input type="text" name="otp" autocomplete="one-time-code">

Quick rules

• autocomplete can go on a <form> or an individual form control.
• Input-level values can override the form-level value.
• autocomplete="off" is a hint, not a guarantee.
• Browsers may ignore off for login and password-related fields.
• Use semantic values when the field purpose is known.

Good defaults

• Search field: off
• Email field: email
• Username field: username
• Current password: current-password
• New password: new-password
• Verification code: one-time-code

Edge case reminder

If a browser still autofills a field, that does not necessarily mean your HTML is wrong. It may be the browser intentionally overriding your hint.

Can I completely disable autocomplete in every browser?

No. autocomplete="off" is only a hint. Some browsers ignore it for certain fields, especially login and password fields.

Should I put autocomplete="off" on the form or the input?

You can do either. Put it on the form for a default behavior, and use input-level values when individual fields need different behavior.

Why does my password field still autofill even with autocomplete="off"?

Browsers and password managers often override off to help users log in securely and conveniently.

What should I use for login forms instead of turning autocomplete off?

Use semantic values such as autocomplete="username" and autocomplete="current-password".

Is disabling autocomplete good for user experience?

Only sometimes. It can help for temporary fields like search or coupon codes, but it usually hurts UX for common personal information fields.

Does autocomplete affect form validation?

No. Autocomplete only suggests or fills values. You still need proper validation.

Can I use different autocomplete values on different inputs in the same form?

Yes. That is a common and recommended approach.

• HTML forms — Autocomplete is part of how forms collect and submit user input.
• Input attributes — Attributes like name, type, required, and autocomplete work together.
• Form validation — Autofill and validation solve different problems and are often used together.
• Accessibility in forms — Clear labels and semantic field meanings improve usability for all users.
• Password managers — They often interact with username, current-password, and new-password fields.
• Browser autofill — This is the broader browser feature that autocomplete helps control.
• Semantic HTML — Using meaningful field types and attributes helps browsers understand your form.