How do you disable browser autocomplete on web form field / input tags?

Question

How do you disable autocomplete in the major browsers for a specific input (or form field)?

Solution 1

Firefox 30 ignores autocomplete="off" for passwords, opting to prompt the user instead whether the password should be stored on the client. Note the following commentary from May 5, 2014:

• The password manager always prompts if it wants to save a password. Passwords are not saved without permission from the user.
• We are the third browser to implement this change, after IE and Chrome.

According to the Mozilla Developer Network documentation, the Boolean form element attribute autocomplete prevents form data from being cached in older browsers.

<input type="text" name="foo" autocomplete="off" />

Solution 2

In addition to setting autocomplete=off, you could also have your form field names be randomized by the code that generates the page, perhaps by adding some session-specific string to the end of the names.

When the form is submitted, you can strip that part off before processing them on the server-side. This would prevent the web browser from finding context for your field and also might help prevent XSRF attacks because an attacker wouldn't be able to guess the field names for a form submission.

Solution 3

Most of the major browsers and password managers (correctly, IMHO) now ignore autocomplete=off.

Why? Many banks and other "high security" websites added autocomplete=off to their login pages "for security purposes" but this actually decreases security since it causes people to change the passwords on these high-security sites to be easy to remember (and thus crack) since autocomplete was broken.

Long ago most password managers started ignoring autocomplete=off, and now the browsers are starting to do the same for username/password inputs only.

Unfortunately, bugs in the autocomplete implementations insert username and/or password info into inappropriate form fields, causing form validation errors, or worse yet, accidentally inserting usernames into fields that were intentionally left blank by the user.

What's a web developer to do?

• If you can keep all password fields on a page by themselves, that's a great start as it seems that the presence of a password field is the main trigger for user/pass autocomplete to kick in. Otherwise, read the tips below.
• Safari notices that there are 2 password fields and disables autocomplete in this case, assuming it must be a change password form, not a login form. So just be sure to use 2 password fields (new and confirm new) for any forms where you allow

• Chrome 34, unfortunately, will try to autofill fields with user/pass whenever it sees a password field. This is quite a bad bug that hopefully, they will change the Safari behavior. However, adding this to the top of your form seems to disable the password autofill:

  <input type="text" style="display:none">
  <input type="password" style="display:none">
  

I haven't yet investigated IE or Firefox thoroughly but will be happy to update the answer if others have info in the comments.

Solution 4

Sometimes even autocomplete=off would not prevent to fill in credentials into the wrong fields, but not a user or nickname field.

This workaround is in addition to apinstein's post about browser behavior.

Fix browser autofill in read-only and set writable on focus (click and tab)

 <input type="password" readonly
     onfocus="this.removeAttribute('readonly');"/>

Update:

Mobile Safari sets cursor in the field, but it does not show the virtual keyboard. The new fix works like before, but it handles the virtual keyboard:

<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
    this.removeAttribute('readonly');
    // fix for mobile safari to show virtual keyboard
    this.blur();    this.focus();  }" />

Live Demo https://jsfiddle.net/danielsuess/n0scguv6/

// UpdateEnd

Because the browser auto fills credentials to wrong text field!?

I notice this strange behavior on Chrome and Safari, when there are password fields in the same form. I guess the browser looks for a password field to insert your saved credentials. Then it auto fills (just guessing due to observation) the nearest textlike-input field, that appears prior the password field in the DOM. As the browser is the last instance and you can not control it.

This readonly-fix above worked for me.

Solution 5

The solution for Chrome is to add autocomplete="new-password" to the input type password. Please check the example below.

Example:

<form name="myForm"" method="post">
   <input name="user" type="text" />
   <input name="pass" type="password" autocomplete="new-password" />
   <input type="submit">
</form>

Chrome always autocomplete the data if it finds a box of type password, just enough to indicate for that box autocomplete = "new-password".

This works well for me.

Note: make sure with F12 that your changes take effect. Many times, browsers save the page in the cache, and this gave me a bad impression that it did not work, but the browser did not actually bring the changes.

View more solutions

Comments

[aruno]

In some systems where testers have to manually enter a lot of information over and over it might be useful to have the option as configurable so that when testing you can disable it and just hit 'tab > down arrow > tab > down arrow etc...'

[Terry Lin]

Try github.com/terrylinooo/disableautofill.js , it uses JavaScript the skip the auto-fill function from browser.

[cigien]

This question is being discussed on meta.

[ConroyP]

The problem with this is if any other sites use "name_" to achieve the same objective then you're back to square one.

[Winston Fassett]

This did not work for me in Firefox 3.0.3 I had to put the autocomplete attribute in the FORM rather than the INPUT.

[Jrgns]

Autocomplete is only defined in the HTML 5 standards, so it will break any validations you run against HTML 4.*...

[Steve Perks]

so make it "mysite_name". If anyone else is using that, I'd ask them questions...

[aruno]

this messes up some of those automatic populating utilities

[aruno]

if i went to a site and it remembered my card in the dropdown i'd be very unhappy. id start to wonder how they could be so careless.

[sholsinger]

I've noticed that adding it to the form element doesn't always prevent it from being applied to individual inputs within the form. Therefore it is probably best to place it on the input element directly.

[AviD]

Actually @sholsinger, it's best to put it both on the form, AND on the input element itself. That way you cover all the nonstandardness of browsers.

[AviD]

@Winston, you should put it both on the form, AND on the input element itself. That way you cover all the nonstandardness of browsers.

[Jo Liss]

And remember to disable your autocomplete = on extension (if you're using Chrome) before you test your webapp. Else you'll feel real silly like me. ;)

[Andiih]

this doesn't avoid invalid xhtml, it simply adds the invalid bit dynamically after you have checked it it declared it to be valid!

[cherouvim]

@Andiih: So is there a way to make autocomplete work in xhtml?

[Andiih]

Work (or stop it working which is the goal): yes as above. But valid - no.

[enchance]

This is a much better solution compared to using autocomplete="off". All you have to do is generate a new name on every page load and save that name to a $_SESSION for future use: $_SESSION['codefield_name'] = md5(uniqid('auth', true));

[Armen Michaeli]

No, this is not a better solution, because the origin of preference for this setting is user agent also known as the web browser. There is a difference between supporting certain behaviour (which HTML 5 attempts to do) and forcing it by deciding on behalf of the user, which you suggest is a "much better solution".

[SamHuckaby]

Sadly, as of IE 11, Microsoft no longer respects this for input type="password". Hopefully no other browsers choose to remove this functionality.

[wutzebaer]

what do you mean with "adding this on your page seems to disable autofill for the page:"

[macguru2000]

This solution can work with all browsers, so in that respect it is "better". Still, amn is correct, deciding to disable autocomplete on behalf of your users is not a good idea. This means I would only disable autocomplete in very specific situations, such as when you plan to build your own autocomplete functionality and don't want conflicts or strange behavior.

[Jimmy Kane]

An if there is no javascript then the whole form fails. -1

[David W]

@wutzebaer, Chrome notices the hidden password field and halts auto-complete. Reportedly this is to prevent the site stealing password info without the user noticing.

[xr280xr]

Regarding XSRF attacks, I'm not sure what type of attack you were picturing, but couldn't the attacker just strip off the end part the same way you do server-side to identify the fields? Or if the attacker is posting the fields, couldn't they append their own random string since it'll be stripped off by the server?

[trnelson]

@JimmyKane the key would be to also add the attribute using javascript in the first place (which dsuess hasn't done here, but just adding for completeness sake).

[Jimmy Kane]

@tmelson I understand but still why use js to even disable? Let's avoid js for things that can be improved natively. Again I agree with you though.

[whoadave]

@macguru2000 building your own autocomplete is a completely legit and common use-case. Really the browser should make it easier for developers to turn off autocomplete when they need to instead of forcing us to use hacks like this one

[azuax]

As you said in chrome, the off value doesn't work. It needs to be "false"

[Sam Watkins]

Your snippet of code prevent autocompletes for login fields on Chrome, Firefox, IE 8 and IE 10. Did not test IE 11. Good stuff! Only simple answer that still works.

[Robotronx]

It has just come to my attention that IE doesn't trigger onChange events when you fill a text input using AutoComplete. We've got dozens of forms and over a thousand onChange events (input validations, business logic) scattered all over them. Recently we upgraded IE to a newer version and all of a sudden weird things started to happen. Luckily we're running an intranet app and autocomplete is not an UX issue for us, it's easier to just turn it off.

[rybo111]

The first and second options should be one option, since it varies on how browsers handle this.

[GuiGS]

Works for me on Chrome 44.0.2403.130.

[pronebird]

Tried $formElement.attr('autocomplete', 'off'); and it does not work.

[pronebird]

Tried this: $formElement.attr('autocomplete', 'false'); sorry does not work.

[rjmunro]

Much simpler / more critical case. When I visit a user's page on the admin portion of my site, it tries to set their username and password to be my admin username and password, not being able to tell that this isn't a login form. I want to have my admin password remembered, but it is a critical error that it tries to apply that remembered username / password to any users that I then edit.

[rjmunro]

If a users local machine is compromised, they are screwed, period. It could have a keylogger installed, it could have a fake SSL root certificate added and everything sent through a false proxy etc. I have a real reason to disable autocomplete - When I log in as an admin and visit the edit user page, it assigns that user my admin username and password. I need to prevent this behaviour.

[Roel]

It is a hack. The field is not a search field. In the future this could cause troubles.

[Mike]

Setting autocomplete="off" on the form is the only thing that worked for Chrome.

[Jamie Rees]

This is a horrible solution and would not recommend anyone doing this

[Mikal Schacht Jensen]

Note that using this technique, FireFox will still actually autofill that hidden field, which will be included when submitting the form. That would likely be bad, as the password would then be transfered over a potentially unsecured connection. Fortunately adding maxlength="0" does prevent firefox from autofilling the field.

[mcallahan]

For me in IE11 I can't type into the text box even after the onfocus removes the readonly attribute. However, if I click a second time on the text box then I can type.

[aro_tech]

Browser vendors seem to be looking out for their own interests. Saved passwords = user lock-in. And autocomplete on/off was too simple - why not a complex standard of semantic hints ( html.spec.whatwg.org/multipage/… ) which, by-the-way, allows the browser to collect valuable semantic data from the sites each user visits ?

[Jake]

This works in Chrome for other types of fields as well, not just type="password".

[David]

the specific use case I am trying to solve is this: they are already logged in. but now they are about to access something even more sensitive. I want to show a dialog that makes them re-authenticate, against the possibility that they walked off to have a smoke and a bad person sat down in their chair. have tried several techniques to defeat autocompletion, and nothing works. now I am thinking, maybe, at least, use good old 'password = window.prompt("Please re-enter your password")' plus the username in the session, and try to authenticating that.

[Crak_mboutin]

I used it with password, email and text types and it worked. I used it simply like this: autocomplete="new"

[Scrappydog]

I ran into the same issue with IE11 (can't type until second focus). Adding a blur and then focus again works. $(document).on('focus', 'input:password[readonly="readonly"]', function () { $(this).prop('readonly', false).blur().focus(); });

[Craig Jacobs]

I found this to work in my preliminary testing. So odd that "off" doesn't work.

[ChronoFish]

I can't believe this is still an issue. I get that "the user should have control" however there are use-cases where autocomplete makes no sense. For example the last thing you want on a data-entry application, i.e. a reception desk, is to have the last record to be pre-populated. There are many enterprise application use-cases outside the standard e-commerce checkout model that chrome/firefox are catering to

[tebs1200]

This doesn't work for Chrome on Android. I've tried setting string values for the autocomplete attribute and it still displays previous entries as autocomplete suggestions under the input.

[Cava]

@tebs1200 Which one? The password field or the text field?

[tebs1200]

@Cava sorry for the delayed response. The text field. It doesn't matter what value I set autocomplete to, i still get a suggestion dropdown based on previously entered values. It's fine on desktop, but not on Android chrome.

[Raghuram Kasyap]

This works even better. You can add a small JS that generates a random code for every page load, and add that code to the input field: <code> function autoId(){ var autoId = ""; var dict = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456‌​789"; for(var i=0; i<12; i++){ autoId += dict.charAt(Math.floor(Math.random() * dict.length)); } return autoId; } $('.autocompleteoff').attr('autocomplete', autoId());</code> You can add the autocompleteoff class to your desired input field.

[Sukanya Purushothaman]

not working in my chrome Version 68.0.3440.106 (Official Build) (64-bit)

[MacK]

Chrome has been fixed to use the standardized "off" now

[Nour Lababidi]

Sadly it works better than what is called standard on chrome

[Andrew]

Doesnt help with default values, but it is an idea, as you could track & replace the values with the ones that were there originally I suppose.

[Andrew]

How is this any different than setting it to autocomplete=off in html, which doesn't work these days?

[Andrew]

Looks like good idea if style text boxes to prevent flash of visible password.

[Andrew]

so, putting this prior to the actual username and password fields worked? the browser filled those and not the real ones

[Murat Yıldız]

@Andrew Sure, you can. This is the core principle to overwhelm this issue and I also added an update containing full code example ;)

[Denuka]

autocomplete="nope" name="pswd" and used <input name="dummyPassword" type="password" style="display:none;"> before the real password input field. This worked for me.

[Hasnaa Ibraheem]

Thanks so much, this did the job +1, my variation to your solution was to make it by single line: <input oninput="this.type='password'" id="inputpassword" type="text">

[Stav Bodik]

@HasnaaIbraheem Thanks (: sometimes more readable is better .

[step]

You have to generate new random string on each reload page.

[rinatdobr]

I've also added onfocusout="this.setAttribute('readonly', 'readonly');"

[IvanRF]

Examples: chromium.org/developers/design-documents/…

[step]

Today I found that Chrome will overwrite random string with "Off". I can not believe that Chrome developers doing this attribute bad and noncontrol. Why ohh my got.

[Andrew Morton]

This works in almost all browsers now, not just Chrome: autocomplete#Browser_compatibility.

[splashout]

This is the best answer as of now. See the end of this page for more infomation: developer.mozilla.org/en-US/docs/Web/Security/…

[Williaan Lopes]

autocomplete="new-password" and why the "off" parameter doesn't work?? HTML attributes it's really crap. That works on opera browser! Thanks.

[Neil Gaetano Lindberg]

autoComplete for React... $0.02

[mickmackusa]

This answer is missing its educational explanation.

[ZF007]

You have to do better than what you just posted to prevent down-voting or flagging for "low quality" answer. Keep in mind you're competing with 82 other answers. Add versioning. End of Review.

[Robin Schaaf]

This is the only way I could get it to work - readonly attr worked but messed up the tab order.

[Peter Mortensen]

There isn't any current user by the name "sasb" here (incl. in deleted answer). (Though comments on some deleted answers are no longer visible.) What answer (or comment) does it refer to?

[Peter Mortensen]

An explanation would be in order. E.g., what is the idea/gist? What was it tested on (including version information) and under what conditions?

[Peter Mortensen]

An explanation would be in order. E.g., what is the idea/gist? What was it tested on (incl. versions)?

[Peter Mortensen]

Re "Most of the answers didn't help as the browser was simply ignoring them": Can you be more specific? What browser(s) and what version(s) and on what platform(s) (incl. version(s)). Please respond by editing (changing) your answer, not here in comments (without "Edit:", "Update:", or similar - the answer should appear as if it was written today).

[Peter Mortensen]

What do you mean by "how email address to" (seems incomprehensible)? Please respond by editing (changing) your answer, not here in comments (without "Edit:", "Update:", or similar - the answer should appear as if it was written today).

[Peter Mortensen]

Re "add the ‌ character into the middle of your labels": How is that going to be maintainable? How is a new developer to discover that in a timely manner? How do you suggest documenting the invisible characters (also if they aren't invisible in some contexts)?

[Alex from Jitbit]

Stopped working in Chrome 94.0 and Edge 94.0

[AmerllicA]

Appreciate for your complete explanation.

[John Ruiz]

13 years later, this is still the best option - for those of us using JQuery, here's a quick modification: onfocus="$(this).attr('readonly',false);"

[Shahid Malik]

Surprised, why this answer is accepted and having so much votes. Even there is nothing special as said others. As per my findings most specific and proved solution has provided by @Ben Combee in this thread.

[Alex from Jitbit]

How do you prevent users hitting "enter"?

[Alex from Jitbit]

not any more, stopped working in recent browsers

[mahmoud nezar sarhan]

this doesn't seem to work with me until I put a form with autocomplete='off' around the input field

[Sachin Yadav]

You can also use Math.random().toString() atleast it worked for me in material UI

[Wilt]

Where on MDN, that link you added doesn't mention anything with "nope". Maybe the page has changed?

[Lojith Vinsuka]

This works for me. Thanks for your help :)

[General Grievance]

An explanation would be good, especially on old questions with a lot of answers already. Do you need all those attributes set?

[General Grievance]

Ok. Please edit such details into your answer.

[Himanshu Pandey]

only this solution is working from entire internet

[rAthus]

The "Update 2022" with the autocomplete="new-password" works, thanks!

[KOMODO]

This is not solution. If JS not works in page, yes it fails. And also, you did a mouse event but many users don't use mouse when they enter inputs.

[Aseem]

autocomplete="off" works for firefox in 2022

[Victor Marcoianu]

This no longer works.