2973

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

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Brett Veenstra
  • 44,790
  • 17
  • 65
  • 84
  • 4
    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...' – Simon_Weaver Nov 22 '09 at 05:15
  • Try https://github.com/terrylinooo/disableautofill.js , it uses JavaScript the skip the auto-fill function from browser. – Terry Lin Feb 25 '21 at 08:50

89 Answers89

2751

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" />
double-beep
  • 3,889
  • 12
  • 24
  • 35
nlucaroni
  • 45,818
  • 5
  • 58
  • 85
  • 48
    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. – Winston Fassett Nov 12 '08 at 04:11
  • 20
    Autocomplete is only defined in the HTML 5 standards, so it will break any validations you run against HTML 4.*... – Jrgns Jan 19 '09 at 08:04
  • 104
    @Winston, you should put it both on the form, AND on the input element itself. That way you cover all the nonstandardness of browsers. – AviD Dec 13 '10 at 12:11
  • 89
    And remember to disable your [autocomplete = on](https://chrome.google.com/extensions/detail/ecpgkdflcnofdbbkiggklcfmgbnbabhh) extension (if you're using Chrome) before you test your webapp. Else you'll feel real silly like me. ;) – Jo Liss Feb 26 '11 at 00:57
  • 3
    This question/answer may be old now but I'll say that Firefox 15 seems to put the password in despite the autocomplete="off" in the input and form elements. It also fills it even if you change the name and id of the password field. This is if the password is already saved. Now these do seem to prevent the password from being saved if it hasn't been already. – mikato Sep 28 '12 at 14:31
  • Also, KeeFox, a Firefox extension to use KeePass to store your passwords, interferes with that and fills the password anyways if it was saved previously. – Pierre Henry Feb 05 '13 at 08:32
  • This code also disallow saved username/passwords to been shown? – Silvio Delgado Feb 25 '13 at 20:08
  • 8
    [IE11 also ignores autocomplete for password elements](http://msdn.microsoft.com/en-us/library/ms533486(VS.85).aspx) :/ – Hofi Oct 07 '13 at 13:19
  • 2
    Latest versions of Firefox >20 (older were not tested) will not prompt for saving username/password if the form has `autocomplete=off`. – unode Feb 27 '14 at 17:51
  • 2
    With jquery: $(document).ready(function(){ $('input[type="text"], select').val('') }); – e-info128 Mar 04 '14 at 14:54
  • 2
    Chrome also ignores this (for password fields) as of a code patch in Feb 2014: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/zhhj7hCip5c – Simon East Jun 27 '14 at 03:53
  • This no longer works for login/password fields at least. The code in apinstein's answer still works. – Sam Watkins May 19 '15 at 04:47
  • so what does one do when (in chrome) i have disabled autocomplete and used random name attributes for the inputs and username **AND** password still show up?? – RWolfe Jul 07 '15 at 14:29
  • 4
    You must set autocomplete to be anything but "on" or "off". Then it will actually disable. I know this is true for Chrome, but I haven't tested it in any other browsers. http://stackoverflow.com/questions/30053167/autocomplete-off-vs-false/30081850#30081850 – camiblanch Jul 14 '15 at 16:41
  • @swapab not anymore :( – brandito Apr 10 '18 at 06:48
  • If creating the form dynamically on server side, setting the value for user name to a tab should prevent the browser from auto filling the credentials. Though still providing auto completion suggestions. Upon receiving form submission trim the tab in case user didn't remove it. If a tab doesn't work maybe try a vertical tab or other non printing characters. – NOYB Jul 06 '18 at 03:58
  • 2
    For Chrome use: autocomplete="nope" It seems funny but it works! However this won't work for Firefox or other browsers. For them you can add the autocomplete="off" to the form element. If you are using web forms your form element is in the master page. – Amir Tofighi Aug 08 '18 at 20:10
  • Using random characters like this: , chrome will never remember value. When you generate tag on backend, generate random string. Simple working solution. – step Mar 27 '19 at 16:13
  • I have found that some more recent "smart" browsers, will extrapolate and make auto-fill decisions based on nearby text content with in the form. For example, if the `text` input field is immediately preceded by the text "First name: ", then browsers like Safari will start grabbing suggestions from places as far-flung as your OS contact book. One solution to this is more clever (read: "idiosyncratic") naming than obvious choices like, "First name". – Parapluie May 13 '19 at 14:56
  • this answer might require an update https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#Preventing_autofilling_with_autocompletenew-password – mh-cbon Jun 18 '19 at 15:22
  • Over last firefox (v69.0) I can only disable autocomplete globally using it inside the form:
    – gtamborero Sep 12 '19 at 11:31
  • 2
    @AviD Actually, the correct way to do it is to turn it off in the form. That way it will turn off autocomplete for every input element and it will not have any fallback autocomplete outputs. When turned off in the form, you can still specify individual input elements for their autocomplete. It will be much cleaner. Your answer is old, but I wanted to add this note. – ravo10 Oct 10 '19 at 09:21
  • @ravo10 I'd hope that 9 years later, this dumb little idiosyncrasy is finally solved :-) – AviD Oct 10 '19 at 13:05
  • @AviD Haha, yes. – ravo10 Oct 11 '19 at 17:20
  • Be sure to look at @Geynen's answer which uses autocomplete="new-password" – splashout May 19 '20 at 20:17
  • I think my solution may work around all of this stuff so that we never have to worry about the browsers again? for a while at least... it might need worked on and improved but the general idea is there and seems to work as of the date it was posted. https://stackoverflow.com/a/64499109/6730421 – Adam Whateverson Oct 23 '20 at 16:32
  • [MozillaDoc](https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion): „Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise. For this reason, many modern browsers do not support autocomplete="off" for login fields“ – tibx Nov 09 '20 at 08:01
347

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.

Ben Combee
  • 15,807
  • 6
  • 37
  • 40
  • 13
    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));` – enchance Nov 13 '11 at 09:03
  • 88
    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". – amn May 27 '13 at 17:09
  • 17
    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. – macguru2000 May 15 '14 at 21:34
  • 9
    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? – xr280xr Feb 11 '15 at 20:10
  • 12
    @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 – whoadave May 06 '15 at 02:01
  • This is not a good solution if you are using MVC forms where the name has to match the properties of the object or model you are passing information into. – jezzipin Oct 27 '15 at 14:15
  • 2
    @xr280xr Not if the appending string is a session ID (or some other session-specific generated value). Then, form POST input IDs would be validated against the session that actually created the HTML itself. – Mike U Dec 11 '15 at 22:09
  • @jezzipin: You *do not* need to used a model with MVC. Just use a generic `FormCollection` parameter and access the names/values. – Gone Coding Mar 31 '16 at 15:55
  • Note: Randomizing field names does not help in later IE browsers. It simply detects the first password field (of any name) and autocompletes on the field prior to it. – Gone Coding Aug 26 '16 at 14:16
  • This solution may be dangerous, because the browser would still save these values to some file, such as `formhistory.sqlite`, just like the regular autocomplete values. – Gras Double Aug 09 '17 at 17:16
  • 1
    Another legit use-case is when you are building internal enterprise apps and needs to be compliant with infosec rules. – JwJosefy Apr 16 '18 at 15:05
  • 7
    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 – ChronoFish Jul 12 '18 at 13:22
  • Chrome (and possibly others) currently seems to deduce autocompletion through an ``'s `placeholder` attribute. If this placeholder contains `"name"` then it will also offer autocomplete, regardless of the `name` attribute's value. So this solution won't work if you want to stop autocompletion on an input like ``. – shennan Jul 03 '19 at 23:03
  • I used this technique in an old ASP.NET web forms application, thank you. I have a UserControl that encapsulates a textbox that is extended with jQuery AutoComplete. Browser AutoFill was obscuring the AutoComplete until I appended a random integer to the TextBox ID in the Page_Init event handler. After creation, this random integer had to be stored as a Session variable because Page_Init runs every post back and for some bleeped up reason ViewState wasn't good enough. – CAK2 Jun 18 '20 at 16:47
253

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.

Zub
  • 808
  • 1
  • 12
  • 22
apinstein
  • 4,705
  • 1
  • 21
  • 21
  • 6
    what do you mean with "adding this on your page seems to disable autofill for the page:" – wutzebaer May 07 '14 at 10:31
  • 6
    @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. – David W Dec 01 '14 at 23:05
  • 7
    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. – Sam Watkins May 19 '15 at 04:44
  • How does this apply to other input fields like `email` or credit cards? We have a problem of browsers thinking the `email` box is for them, when it's for someone else. – Kelsey Hannan May 24 '15 at 04:58
  • 4
    Your safari note seems to work on Chrome too, at least as of Dec 2015. I had a username and password field on a registration form that was autocompleting with data from the login form. Creating two `type='password'` fields on the one page caused the browser's "save password" autocomplete to be ignored, which made a whole load of sense since registration forms tend to ask for the password twice when login forms only ask for it once. – Matt Fletcher Dec 20 '15 at 20:27
  • 4
    Does not seem to work in Chrome 55 anymore, unless the extra password field is not hidden, which defeats the purpose. – jokkedk Oct 10 '16 at 09:06
  • @jokkedk I've found that instead of using `display: none;` you can use `position: relative; left: -1000px;` instead and that does the trick for me in Chrome. Technically not hidden, but just shown off-screen. – crazyloonybin Oct 18 '16 at 14:13
  • 2
    Doesn't work anymore, Chrome 54 autofills all username/password fields it finds. – Stijn Van Bael Oct 20 '16 at 11:46
  • @StijnVanBael In Chrome 54, you can use `style="visibility: hidden; height: 0;"` Works for me. – Finrod Oct 24 '16 at 15:19
  • 3
    @Finrod it feels kinda pointless finding new hacks. You'll always have to stay one step ahead of the Chrome devs. If they really always want to autofill user creation forms, they'll always find a way. – Stijn Van Bael Oct 24 '16 at 15:44
  • I needed to add `name="email"` and `name="password"` to the `input`s before this solution worked. but it did! (though I feel really dirty doing it, 'cos I "know" the browser is autocompleting *those instead*) – MoshMage Feb 10 '17 at 15:31
  • @apinstein but when you make a form for admins to sign up users, for instance, Chrome autofills the username and password fields in that form, which is definitely not the desired behavior for such a form. – Andy Oct 30 '17 at 19:00
  • The problem here is that there is now a war between Security firms and Browser vendors. On the head of the poor developer. I care less and actually do not have a strong stance either way, but OWASP and the like should work together with Chrome vendors to define guidelines. – JAR.JAR.beans Nov 22 '17 at 14:45
  • 2
    Sorry, I do not agree (at all) that autofilling passwords is a good idea - for the obvious reason that it allows anyone to walk up to your PC, tablet or other device and see your password. It is even worse that we can't - other than with an ever-evolving and inconsistent range of browser hacks - prevent this in situations where we know, for sure, that it is a bad idea. I saw this when instigating a password with a show/hide password function - if you (or anyone else) decide to 'Show' the password, there will then be a dropdown of all the passwords that have been used on that input. OMG. – Geoff Kendall Mar 28 '18 at 11:32
  • But @DavidW the website is already being told of what is being input where... That's how forms work. We can access the data users input into a form, with or without a server request / form submission. – brandito Jun 29 '18 at 05:29
  • @Brandito we want to hide other sensitive data, like SSN from people looking over a shoulder. – David W Jul 04 '18 at 16:49
  • 2
    Ahh right, gotcha, you confused me at first with this part: `prevent the ` **site** `stealing password info without the user noticing` – brandito Jul 05 '18 at 01:44
  • IMHO forcing web developers to use a hack instead of an open standard is not correct. "high security" websites can use these hacks as well. – dehart Sep 27 '19 at 12:25
  • The original post refers to input fields generally, with no reference to password fields. I've just tested autocomplete on a standard text input in Firefox 70.0.1 and it respects the attribute. – Savage Nov 20 '19 at 11:09
  • Can you make it more clear (by updating the answer) what a "password field" is in this context (that is, the context is your answer)? E.g., is it exclusively an HTML form `input` field with attribute `type="password"`? Or something else? – Peter Mortensen Apr 08 '21 at 23:36
170

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.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
dsuess
  • 4,769
  • 2
  • 20
  • 21
  • 8
    An if there is no javascript then the whole form fails. -1 – Jimmy Kane Jul 10 '14 at 10:56
  • 8
    @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). – trnelson Mar 27 '15 at 17:58
  • @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. – Jimmy Kane Mar 27 '15 at 20:29
  • 4
    This doesn't work right in IE8, the readonly password field is not editable the first time you focus it, only after you unfocus and focus again. Nice idea, but unfortunately it's a bit too hacky and not safe to use. – Sam Watkins May 19 '15 at 04:57
  • This does *not* work correctly on all browsers (e.g. IE 11 & IE Edge). As soon as the `readonly` is removed, subsequent selection of the field results in the autocomplete returning. – Gone Coding Aug 26 '16 at 14:18
  • It's actually nice idea! Only, when using Bootstrap, this will create grey background for `readonly` input fields. Remove it with `style="background:none"` – Arnis Juraga Oct 04 '17 at 21:58
  • Works fine on v63 chrome, any security issues with that? – Palaniichuk Dmytro Jan 18 '18 at 12:14
  • @PalaniichukDmytro I don't know any 'security issues' and for the last 3 years this answer is published, nobody mentioned any security problems. Hope, that helps :) – dsuess Jan 24 '18 at 16:26
  • When using this workaround I've noticed that in FF 60.0.1 I have to click two times inside the password box to get the focus active. – M. Altmann May 17 '18 at 12:59
  • In my situation the user shouldn't be able to edit either, so this works great! – wedstrom Mar 01 '19 at 21:07
  • In some versions of IE you need to doubleclick (first focus, then focus out I gues). I fixed this by addin onmouseover event. – baron_bartek Apr 05 '19 at 12:52
145

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.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Geynen
  • 1,603
  • 2
  • 8
  • 6
  • 4
    This works in Chrome for other types of fields as well, not just type="password". – Jake Dec 14 '17 at 22:04
  • I used it with password, email and text types and it worked. I used it simply like this: autocomplete="new" – Crak_mboutin Jan 15 '18 at 21:02
  • autocomplete="nope" name="pswd" and used before the real password input field. This worked for me. – Denuka Jan 31 '19 at 18:51
  • Examples: https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands – IvanRF Jul 02 '19 at 20:28
  • 1
    This works in almost all browsers now, not just Chrome: [autocomplete#Browser_compatibility](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#Browser_compatibility). – Andrew Morton Apr 07 '20 at 10:38
  • 2
    This is the best answer as of now. See the end of this page for more infomation: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion – splashout May 19 '20 at 20:15
  • `autocomplete="new-password"` and why the "off" parameter doesn't work?? HTML attributes it's really crap. That works on opera browser! Thanks. – Williaan Lopes Jul 02 '20 at 23:29
  • Worked for me,.. – Jatin Mandanka Jan 08 '21 at 10:38
110
<form name="form1" id="form1" method="post"
      autocomplete="off" action="http://www.example.com/form.cgi">

This will work in Internet Explorer and Mozilla Firefox. The downside is that it is not XHTML standard.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
brendan
  • 27,495
  • 18
  • 64
  • 106
  • 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. – sholsinger May 10 '10 at 16:48
  • 16
    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 Dec 13 '10 at 12:11
  • 2
    Sadly, as of IE 11, Microsoft no longer respects this for `input type="password"`. Hopefully no other browsers choose to remove this functionality. – SamHuckaby Mar 21 '14 at 21:18
  • Setting `autocomplete="off"` on the `form` is the only thing that worked for Chrome. – Andrew Feb 09 '16 at 18:41
61

As others have said, the answer is autocomplete="off".

However, I think it's worth stating why it's a good idea to use this in certain cases as some answers to this and duplicate questions have suggested it's better not to turn it off.

Stopping browsers storing credit card numbers shouldn't be left to users. Too many users won't even realize it's a problem.

It's particularly important to turn it off on fields for credit card security codes. As this page states:

"Never store the security code ... its value depends on the presumption that the only way to supply it is to read it from the physical credit card, proving that the person supplying it actually holds the card."

The problem is, if it's a public computer (cyber cafe, library, etc.), it's then easy for other users to steal your card details, and even on your own machine a malicious website could steal autocomplete data.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Sam Hasler
  • 13,310
  • 9
  • 68
  • 101
  • 7
    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. – Simon_Weaver Nov 22 '09 at 05:13
  • 10
    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 Dec 17 '15 at 13:35
40

I've solved the endless fight with Google Chrome with the use of random characters. When you always render autocomplete with random string, it will never remember anything.

<input name="name" type="text" autocomplete="rutjfkde">

Hope that it will help to other people.

step
  • 1,625
  • 2
  • 19
  • 35
  • 3
    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: function autoId(){ var autoId = ""; var dict = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; for(var i=0; i<12; i++){ autoId += dict.charAt(Math.floor(Math.random() * dict.length)); } return autoId; } $('.autocompleteoff').attr('autocomplete', autoId()); You can add the `autocompleteoff` class to your desired input field. – Raghuram Kasyap Aug 31 '18 at 13:44
  • not working in my chrome Version 68.0.3440.106 (Official Build) (64-bit) – Sukanya Purushothaman Sep 06 '18 at 05:31
  • Chrome has been fixed to use the standardized "off" now – MacK Oct 17 '18 at 11:16
  • 1
    Sadly it works better than what is called standard on chrome – Nour Lababidi Nov 04 '18 at 03:01
  • You have to generate new random string on each reload page. – step Jun 21 '19 at 13:01
  • 1
    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. – step Oct 07 '19 at 20:11
37

I'd have to beg to differ with those answers that say to avoid disabling auto-complete.

The first thing to bring up is that auto-complete not being explicitly disabled on login form fields is a PCI-DSS fail. In addition, if a users' local machine is compromised then any autocomplete data can be trivially obtained by an attacker due to it being stored in the clear.

There is certainly an argument for usability, however there's a very fine balance when it comes to which form fields should have autocomplete disabled and which should not.

Chris Baker
  • 46,402
  • 12
  • 93
  • 112
Securatek
  • 395
  • 3
  • 2
  • 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. – Robotronx Jun 09 '15 at 13:36
  • 4
    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. – rjmunro Dec 17 '15 at 13:48
  • 1
    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 ( https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill-field-name ) which, by-the-way, allows the browser to collect valuable semantic data from the sites each user visits ? – aro_tech Nov 21 '17 at 13:38
  • 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. – David Jan 12 '18 at 18:09
34

Three options:

First:

<input type='text' autocomplete='off' />

Second:

<form action='' autocomplete='off'>

Third (JavaScript code):

$('input').attr('autocomplete', 'off');
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
yajay
  • 1,030
  • 10
  • 24
26

On a related or actually, on the completely opposite note -

"If you're the user of the aforementioned form and want to re-enable the autocomplete functionality, use the 'remember password' bookmarklet from this bookmarklets page. It removes all autocomplete="off" attributes from all forms on the page. Keep fighting the good fight!"

Raghav Dinesh
  • 491
  • 5
  • 12
Antti Kissaniemi
  • 17,999
  • 13
  • 51
  • 47
25

This works for me.

<input name="pass" type="password" autocomplete="new-password" />

We can also use this strategy in other controls like text, select etc

DisplayName
  • 12,915
  • 2
  • 9
  • 19
Muhammad Awais
  • 3,310
  • 1
  • 34
  • 32
24

Just set autocomplete="off". There is a very good reason for doing this: You want to provide your own autocomplete functionality!

Jibяaᴎ Khaᴎ
  • 3,118
  • 4
  • 32
  • 47
EndangeredMassa
  • 16,328
  • 8
  • 49
  • 79
24

In addition to

autocomplete="off"

Use

readonly onfocus="this.removeAttribute('readonly');"

for the inputs that you do not want them to remember form data (username, password, etc.) as shown below:

<input type="text" name="UserName" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

<input type="password" name="Password" autocomplete="off" readonly 
    onfocus="this.removeAttribute('readonly');" >

Hope this helps.

Murat Yıldız
  • 9,619
  • 6
  • 51
  • 58
  • 1
    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. – mcallahan Nov 10 '17 at 19:16
  • 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(); });``` – palmsey Feb 22 '18 at 14:59
  • @Andrew Sure, you can. This is the core principle to overwhelm this issue and I also added an update containing full code example ;) – Murat Yıldız Nov 08 '18 at 18:20
  • I've also added `onfocusout="this.setAttribute('readonly', 'readonly');"` – rinatdobr Jun 21 '19 at 18:21
22

None of the solutions worked for me in this conversation.

I finally figured out a pure HTML solution that doesn't require any JavaScript, works in modern browsers (except Internet Explorer; there had to at least be one catch, right?), and does not require you to disable autocomplete for the entire form.

Simply turn off autocomplete on the form and then turn it ON for any input you wish it to work within the form. For example:

<form autocomplete="off">
    <!-- These inputs will not allow autocomplete and Chrome
         won't highlight them yellow! -->
    <input name="username"  />
    <input name="password" type="password" />
    <!-- This field will allow autocomplete to work even
         though we've disabled it on the form -->
    <input name="another_field" autocomplete="on" />
</form>
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
lifo
  • 2,701
  • 1
  • 19
  • 31
22

I've been trying endless solutions, and then I found this:

Instead of autocomplete="off" just simply use autocomplete="false"

As simple as that, and it works like a charm in Google Chrome as well!

SuperBiasedMan
  • 8,997
  • 9
  • 43
  • 66
Fery Kaszoni
  • 3,740
  • 1
  • 16
  • 11
22

We did actually use sasb's idea for one site.

It was a medical software web app to run a doctor's office. However, many of our clients were surgeons who used lots of different workstations, including semi-public terminals. So, they wanted to make sure that a doctor who doesn't understand the implication of auto-saved passwords or isn't paying attention can't accidentally leave their login information easily accessible.

Of course, this was before the idea of private browsing that is starting to be featured in Internet Explorer 8, Firefox 3.1, etc. Even so, many physicians are forced to use old school browsers in hospitals with IT that won't change.

So, we had the login page generate random field names that would only work for that post. Yes, it's less convenient, but it's just hitting the user over the head about not storing login information on public terminals.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Jon Adams
  • 22,969
  • 17
  • 78
  • 115
  • 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 Apr 08 '21 at 23:05
21

I think autocomplete=off is supported in HTML 5.

Ask yourself why you want to do this though - it may make sense in some situations but don't do it just for the sake of doing it.

It's less convenient for users and not even a security issue in OS X (mentioned by Soren below). If you're worried about people having their passwords stolen remotely - a keystroke logger could still do it even though your app uses autcomplete=off.

As a user who chooses to have a browser remember (most of) my information, I'd find it annoying if your site didn't remember mine.

GDP
  • 7,641
  • 6
  • 40
  • 73
user631300
  • 311
  • 2
  • 2
17

The best solution:

Prevent autocomplete username (or email) and password:

<input type="email" name="email"><!-- Can be type="text" -->
<input type="password" name="password" autocomplete="new-password">

Prevent autocomplete a field:

<input type="text" name="field" autocomplete="nope">

Explanation: autocomplete continues work in <input>, autocomplete="off" does not work, but you can change off to a random string, like nope.

Works in:

  • Chrome: 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63 and 64

  • Firefox: 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57 and 58

Cava
  • 4,012
  • 3
  • 17
  • 31
  • 2
    I found this to work in my preliminary testing. So odd that "off" doesn't work. – Craig Jacobs Mar 26 '18 at 14:36
  • 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. – tebs1200 Aug 10 '18 at 04:55
  • @tebs1200 Which one? The password field or the text field? – Cava Aug 12 '18 at 02:55
  • @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. – tebs1200 Aug 18 '18 at 02:57
16

Use a non-standard name and id for the fields, so rather than "name" have "name_". Browsers will then not see it as being the name field.

The best part about it is that you can do this to some, but not all, fields and it will autocomplete some, but not all fields.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Teifion
  • 98,441
  • 75
  • 152
  • 192
16

Adding autocomplete="off" is not going to cut it.

Change the input type attribute to type="search".
Google doesn't apply auto-fill to inputs with a type of search.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Matas Vaitkevicius
  • 49,230
  • 25
  • 212
  • 228
  • 6
    It is a hack. The field is not a search field. In the future this could cause troubles. – Roel Dec 31 '15 at 13:24
15

I just ran into this problem and tried several failures, but this one works for me (found on MDN):

In some cases, the browser will keep suggesting autocompletion values even if the autocomplete attribute is set to off. This unexpected behavior can be quite puzzling for developers. The trick to really force the no-completion is to assign a random string to the attribute like so:

autocomplete="nope"
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
AAH-Shoot
  • 627
  • 2
  • 14
  • 30
14

Adding the

autocomplete="off"

to the form tag will disable the browser autocomplete (what was previously typed into that field) from all input fields within that particular form.

Tested on:

  • Firefox 3.5, 4 BETA
  • Internet Explorer 8
  • Chrome
Jonas G. Drange
  • 8,500
  • 2
  • 25
  • 36
Hash
  • 332
  • 2
  • 8
13

So here is it:

function turnOnPasswordStyle() {
  $('#inputpassword').attr('type', "password");
}
<input oninput="turnOnPasswordStyle()" id="inputpassword" type="text">
garfbradaz
  • 3,052
  • 7
  • 35
  • 64
Stav Bodik
  • 1,490
  • 1
  • 14
  • 21
12

This is a security issue that browsers ignore now. Browsers identify and store content using input names, even if developers consider the information to be sensitive and should not be stored.

Making an input name different between 2 requests will solve the problem (but will still be saved in browser's cache and will also increase browser's cache).

Asking the user to activate or deactivate options in their browser's settings is not a good solution. The issue can be fixed in the backend.

Here's the fix. All autocomplete elements are generated with a hidden input like this:

<?php $r = md5(rand() . microtime(TRUE)); ?>
<form method="POST" action="./">
    <input type="text" name="<?php echo $r; ?>" />
    <input type="hidden" name="__autocomplete_fix_<?php echo $r; ?>" value="username" />
    <input type="submit" name="submit" value="submit" />
</form>

The server then processes the post variables like this: (Demo)

foreach ($_POST as $key => $val) {
    $newKey = preg_replace('~^__autocomplete_fix_~', '', $key, 1, $count);
    if ($count) {
        $_POST[$val] = $_POST[$newKey];
        unset($_POST[$key], $_POST[$newKey]);
    }
}

The value can be accessed as usual

echo $_POST['username'];

And the browser won't be able to suggest information from the previous request or from previous users.

This will continue to work even if browsers update their techniques to ignore/respect autocomplete attributes.

mickmackusa
  • 33,121
  • 11
  • 58
  • 86
Simmoniz
  • 1,022
  • 14
  • 24
12

I can't believe this is still an issue so long after it's been reported. The previous solutions didn't work for me, as Safari seemed to know when the element was not displayed or off-screen, however the following did work for me:

<div style="height:0px; overflow:hidden; ">
  Username <input type="text" name="fake_safari_username" >
  Password <input type="password" name="fake_safari_password">
</div>
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Ben
  • 3,981
  • 4
  • 28
  • 49
  • 1
    so, putting this prior to the actual username and password fields worked? the browser filled those and not the real ones – Andrew Nov 08 '18 at 16:54
12

In order to avoid the invalid XHTML, you can set this attribute using JavaScript. An example using jQuery:

<input type="text" class="noAutoComplete" ... />

$(function() {
    $('.noAutoComplete').attr('autocomplete', 'off');
});

The problem is that users without JavaScript will get the autocomplete functionality.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
cherouvim
  • 30,497
  • 14
  • 99
  • 144
11

Try these too if just autocomplete="off" doesn't work:

autocorrect="off" autocapitalize="off" autocomplete="off"
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
jeff
  • 135
  • 1
  • 2
10

None of the hacks mentioned here worked for me in Chrome. There's a discussion of the issue here: https://code.google.com/p/chromium/issues/detail?id=468153#c41

Adding this inside a <form> works (at least for now):

<div style="display: none;">
    <input type="text" id="PreventChromeAutocomplete" name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
  • 1
    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. – Mikal Schacht Jensen Nov 07 '17 at 12:30
9

You may use it in input.

For example;

<input type=text name="test" autocomplete="off" />
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
xxxxx
  • 91
  • 1
  • 1
7

Many modern browsers do not support autocomplete="off" for login fields anymore. autocomplete="new-password" is wokring instead, more information MDN docs

hien
  • 1,481
  • 14
  • 13
6

Chrome is planning to support this.

For now the best suggestion is to use an input type that is rarely autocompleted.

Chrome discussion

<input type='search' name="whatever" />

To be compatible with Firefox, use normal autocomplete='off'

<input type='search' name="whatever" autocomplete='off' />
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Blair Anderson
  • 17,040
  • 7
  • 64
  • 96
6

You can disable autocomplete if you remove the form tag.

The same was done by my bank and I was wondering how they did this. It even removes the value that was already remembered by the browser after you remove the tag.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
jcubic
  • 51,975
  • 42
  • 183
  • 323
6

You can simply put the autocomplete="off" in the HTML fields like following code.

<input type="text" name="" value="" autocomplete="off" />
Prakash Bhandari
  • 493
  • 8
  • 14
6

No fake inputs, no javascript!

There is no way to disable autofill consistently across browsers. I have tried all the different suggestions and none of them work in all browsers. The only way is not using password input at all. Here's what I came up with:

<style type="text/css">
    @font-face {
        font-family: 'PasswordDots';
        src: url('text-security-disc.woff') format('woff');
        font-weight: normal;
        font-style: normal;
    }

    input.password {
        font-family: 'PasswordDots' !important;
        font-size: 8px !important;
    }
</style>

<input class="password" type="text" spellcheck="false" />

Download: text-security-disc.woff

Here's how my final result looks like:

Password Mask

The negative side effect is that it's possible to copy plain text from the input, though it should be possible to prevent that with some JS.

Julius Žaromskis
  • 1,515
  • 10
  • 15
5
<script language="javascript" type="text/javascript">
    $(document).ready(function () {
        try {
            $("input[type='text']").each(
                function(){
                   $(this).attr("autocomplete", "off");
                });
        }
        catch (e) {
        }
    });
</script>
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Tamilselvan K
  • 790
  • 8
  • 10
  • How is this any different than setting it to autocomplete=off in html, which doesn't work these days? – Andrew Nov 08 '18 at 16:29
  • 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 Apr 08 '21 at 23:46
5

This is what we called autocomplete of a textbox.

Enter image description here

We can disable autocomplete of a Textbox in two ways:

  1. By Browser Label

  2. By Code

    To disable in a browser, go to the setting

To disable in the browser, go to the setting

Go to Advanced Settings and uncheck the checkbox and then Restore.

Go to Advanced Settings and uncheck the checkbox and then Restore.

If you want to disable in coding label you can do as follows -

Using AutoCompleteType="Disabled":

<asp:TextBox runat="server" ID="txt_userid" AutoCompleteType="Disabled"></asp:TextBox>

By Setting Form autocomplete="off":

<asp:TextBox runat="server" ID="txt_userid" autocomplete="off"></asp:TextBox>

By Setting Form autocomplete="off":

<form id="form1" runat="server" autocomplete="off">
    // Your content
</form>

By using code in the .cs page:

protected void Page_Load(object sender, EventArgs e)
{
    if(!Page.IsPostBack)
    {
        txt_userid.Attributes.Add("autocomplete", "off");
    }
}

By using jQuery

<head runat="server">
    <title></title>

    <script src="Scripts/jquery-1.6.4.min.js"></script>

    <script type="text/javascript">
        $(document).ready(function () {
            $('#txt_userid').attr('autocomplete', 'off');
        });
    </script>
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Debendra Dash
  • 3,944
  • 35
  • 32
5

If your issue is having a password field being auto-completed, then you may find this useful...

We had this issue in several areas of our site where the business wanted to re-query the user for their username and password and specifically did not want the password autofill to work for contractual reasons. We found that the easiest way to do this is to put in a fake password field for the browser to find and fill while the real password field remains untouched.

<!-- This is a fake password input to defeat the browser's autofill behavior -->
<input type="password" id="txtPassword" style="display:none;" />
<!-- This is the real password input -->
<input type="password" id="txtThisIsTheRealPassword" />

Note that in Firefox and IE, it was simply enough to put any input of type password before the actual one but Chrome saw through that and forced me to actually name the fake password input (by giving it an obvious password id) to get it to "bite". I used a class to implement the style instead of using an embedded style so try that if the above doesn't work for some reason.

Jason L.
  • 841
  • 8
  • 14
5

The answer dsuess posted with the readonly was very clever and worked.

But as I am using Bootstrap, the readonly input field was - until focused - marked with grey background. While the document loads, you can trick the browser by simply locking and unlocking the input.

So I had an idea to implement this into a jQuery solution:

jQuery(document).ready(function () {
    $("input").attr('readonly', true);
    $("input").removeAttr('readonly');
});
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Peter
  • 1,380
  • 2
  • 19
  • 25
5

My problem was mostly autofill with Chrome, but I think this is probably more problematic than autocomplete.

Trick: using a timer to reset the form and set the password fields to blank. The 100 ms duration seems to be the minimum for it to work.

$(document).ready(function() {
    setTimeout(function() {
        var $form = $('#formId');
        $form[0].reset();
        $form.find('INPUT[type=password]').val('');
    }, 100);
});
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Master DJon
  • 1,776
  • 2
  • 16
  • 24
  • 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 Nov 08 '18 at 16:27
5

I use this TextMode="password" autocomplete="new-password" and in in page load in aspx txtPassword.Attributes.Add("value", '');

Mohaimin Moin
  • 783
  • 8
  • 20
5

Google Chrome ignores the autocomplete="off" attribute for certain inputs, including password inputs and common inputs detected by name.

For example, if you have an input with name address, then Chrome will provide autofill suggestions from addresses entered on other sites, even if you tell it not to:

<input type="string" name="address" autocomplete="off">

If you don't want Chrome to do that, then you can rename or namespace the form field's name:

<input type="string" name="mysite_addr" autocomplete="off">

If you don't mind autocompleting values which were previously entered on your site, then you can leave autocomplete enabled. Namespacing the field name should be enough to prevent values remembered from other sites from appearing.

<input type="string" name="mysite_addr" autocomplete="on">
joeytwiddle
  • 24,338
  • 11
  • 107
  • 91
4

It could be important to know that Firefox (I think only Firefox) uses a value called ismxfilled that basically forces autocomplete.

ismxfilled="0" for OFF

or

ismxfilled="1" for ON

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
WolfyD
  • 779
  • 3
  • 10
  • 26
4

It doesn't seem to be possible to achieve this without using a combination client side and server side code.

In order to make sure that the user must fill in the form every time without autocomplete I use the following techniques:

  1. Generate the form field names on the server and use hidden input fields to store those names, so that when submitted to the server the server side code can use the generated names to access the field values. This is to stop the user from having the option to auto populate the fields.

  2. Place three instances of each form field on the form and hide the first and last fields of each set using css and then disable them after page load using javascript. This is to prevent the browser from filling in the fields automatically.

Here is a fiddle that demonstrates the javascript, css and html as described in #2 https://jsfiddle.net/xnbxbpv4/

javascript:

$(document).ready(function() {
    $(".disable-input").attr("disabled", "disabled");
});

css:

.disable-input {
  display: none;
}

html:

<form>
<input type="email" name="username" placeholder="username" class="disable-input">
<input type="email" name="username" placeholder="username">
<input type="email" name="username" placeholder="username" class="disable-input">
<br>
<input type="password" name="password" placeholder="password" class="disable-input">
<input type="password" name="password" placeholder="password">
<input type="password" name="password" placeholder="password" class="disable-input">
<br>
<input type="submit" value="submit">
</form>

Here is a rough example of what the server code using asp.net with razor would be to facilitate #1

model:

public class FormModel
{
    public string Username { get; set; }
    public string Password { get; set; }
}

controller:

public class FormController : Controller
{
    public ActionResult Form()
    {
        var m = new FormModel();

        m.Username = "F" + Guid.NewGuid().ToString();
        m.Password = "F" + Guid.NewGuid().ToString();

        return View(m);
    }

    public ActionResult Form(FormModel m)
    {
        var u = Request.Form[m.Username];
        var p = Request.Form[m.Password];

        // todo: do something with the form values

        ...

        return View(m);
    }
}

view:

@model FormModel

@using (Html.BeginForm("Form", "Form"))
{
    @Html.HiddenFor(m => m.UserName)
    @Html.HiddenFor(m => m.Password)

    <input type="email" name="@Model.Username" placeholder="username" class="disable-input">
    <input type="email" name="@Model.Username" placeholder="username">
    <input type="email" name="@Model.Username" placeholder="username" class="disable-input">
    <br>
    <input type="password" name="@Model.Password" placeholder="password" class="disable-input">
    <input type="password" name="@Model.Password" placeholder="password">
    <input type="password" name="@Model.Password" placeholder="password" class="disable-input">
    <br>
    <input type="submit" value="submit">
}
4

I tried almost all the answer but the new version of Chrome is smart; if you write

autocomplete="randomstring" or autocomplete="rutjfkde"

it automatically converts it to

autocomplete="off"

when input control receives the focus.

So, I did it using jQuery, my solution is as follows.

$("input[type=text], input[type=number], input[type=email], input[type=password]").focus(function (e) {
    $(this).attr("autocomplete", "new-password");
})

This is the easiest and will do the trick for any number of controls you have on the form.

mickmackusa
  • 33,121
  • 11
  • 58
  • 86
Sikandar Amla
  • 1,341
  • 17
  • 25
3

Safari does not change its mind about autocomplete if you set autocomplete="off" dynamically from JavaScript. However, it would respect if you do that on per-field basis.

$(':input', $formElement).attr('autocomplete', 'off');
Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Ben Affleck
  • 11,374
  • 5
  • 50
  • 74
3

The idea is to create an invisible field with the same name before the original one. That will make the browser auto populate the hidden field.

I use the following jQuery snippet:

// Prevent input autocomplete
$.fn.preventAutocomplete = function() {
    this.each(function () {
        var $el = $(this);
        $el
            .clone(false, false) // Make a copy (except events)
            .insertBefore($el)   // Place it before original field
            .prop('id', '')      // Prevent ID duplicates
            .hide()              // Make it invisible for user
        ;
    });
};

And then just $('#login-form input').preventAutocomplete();

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Oleg
  • 6,128
  • 3
  • 39
  • 43
3

Try this :

<input type='text' autocomplete='off' />
Cool
  • 159
  • 1
  • 1
  • 10
3

To solve this problem, I have used some CSS tricks and the following works for me.

input {
    text-security:disc;
    -webkit-text-security:disc;
    -mox-text-security:disc;
}

Please read this article for further detail.

RobC
  • 16,905
  • 14
  • 51
  • 62
gem007bd
  • 935
  • 12
  • 11
3

To prevent browser auto fill with the user's saved site login credentials, place a text and password input field at the top of the form with non empty values and style "position: absolute; top: -999px; left:-999px" set to hide the fields.

<form>
  <input type="text" name="username_X" value="-" tabindex="-1" aria-hidden="true" style="position: absolute; top: -999px; left:-999px" />
  <input type="password" name="password_X" value="-" tabindex="-1" aria-hidden="true" style="position: absolute; top: -999px; left:-999px" />
  <!-- Place the form elements below here. -->
</form>

It is important that a text field precede the password field. Otherwise the auto fill may not be prevented in some cases.

It is important that the value of both the text and password fields not be empty, to prevent default values from being overwritten in some cases.

It is important that these two fields are before the "real" password type field(s) in the form.

For newer browsers that are html 5.3 compliant the autocomplete attribute value "new-password" should work.

<form>
  <input type="text" name="username" value="" />
  <input type="password" name="password" value="" autocomplete="new-password" />
</form>

A combination of the two methods can be used to support both older and newer browsers.

<form>
  <div style="display:none">
    <input type="text" readonly tabindex="-1" />
    <input type="password" readonly tabindex="-1" />
  </div>
  <!-- Place the form elements below here. -->
  <input type="text" name="username" value="" />
  <input type="password" name="password" value="" autocomplete="new-password" />
</form>
NOYB
  • 425
  • 5
  • 12
3

If you want to prevent the common browser plug-in LastPass from auto-filling a field as well, you can add the attribute data-lpignore="true" added to the other suggestions on this thread. Note that this doesn't only apply to password fields.

<input type="text" autocomplete="false" data-lpignore="true" />

I was trying to do this same thing a while back, and was stumped because none of the suggestions I found worked for me. Turned out it was LastPass.

RealSollyM
  • 1,340
  • 1
  • 18
  • 32
JoerT
  • 57
  • 4
3

Most of the answers didn't help as the browser was simply ignoring them. (Some of them were not cross-browser compatible). The fix that worked for me is:

<form autocomplete="off">
    <input type="text" autocomplete="new-password" />
    <input type="password" autocomplete="new-password" />
</form>

I set autofill="off" on the form tag and autofill="new-password" wherever the autofill was not necessary.

3

As of Dec 2019:

Before answering this question let me say, I tried almost all the answers here on SO and from different forums but couldn't find a solution that works for all modern browsers and IE11.

So here is the solution I found, and I believe it's not yet discussed or mentioned in this post.

According to Mozilla Dev Network(MDN) post about how to turn off form autocomplete

By default, browsers remember information that the user submits through fields on websites. This enables the browser to offer autocompletion (that is, suggest possible completions for fields that the user has started typing in) or autofill (that is, pre-populate certain fields upon load)

On same article they discussed the usage of autocmplete property and its limitation. As we know, not all browsers honor this attribute as we desire.

Solution

So at the end of the article they shared a solution that works for all browsers including IE11+Edge. It is basically a jQuery plugin that do the trick. Here is the link to jQuery plugin and how it works.

Code snippet:

$(document).ready(function () {        
    $('#frmLogin').disableAutoFill({
        passwordField: '.password'
    });
});

Point to notice in HTML is that password field is of type text and password class is applied to identify that field:

<input id="Password" name="Password" type="text" class="form-control password">

Hope this would help someone.

Azaz ul Haq
  • 1,315
  • 2
  • 15
  • 38
3

There are many answers but most of them are hacks or some kind of workaround.

There are three cases here.

Case I: If this is your standard login form. Turning it off by any means is probably bad. Think hard if you really need to do it. Users are accustomed to browsers remembering and storing the passwords. You shouldn't change that standard behaviour in most cases.

In case you still want to do it, see Case III

Case II: When this is not your regular login form but name or id attribute of inputs is not "like" email, login, username, user_name, password.

Use

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

Case III: When this is not your regular login form but name or id attribute of inputs is "like" email, login, username, user_name, password.

For example: login, abc_login, password, some_password, password_field.

All browsers come with password management features offering to remember them OR suggesting stronger passwords. That's how they do it.

However, suppose you are an admin of a site and can create users and set their passwords. In this case you wouldn't want browsers to offer these features.

In such cases, autocomplete="off" will not work. Use autocomplete="new-password"

<input type="text" name="yoda" autocomplete="new-password">

Helpful Link:

  1. https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
Nerve
  • 5,435
  • 3
  • 25
  • 29
3

In Chrome, for password type inputs, the autocomplete="new-password" is the only thing working for me.

Juangui Jordán
  • 4,129
  • 1
  • 30
  • 26
2

A workaround is not to insert the password field into the DOM before the user wants to change the password. This may be applicable in certain cases:

In our system we have a password field which in an admin page, so we must avoid inadvertently setting other users' passwords. The form has an extra checkbox that will toggle the password field visibility for this reason.

So in this case, autofill from a password manager becomes a double problem, because the input won't even be visible to the user.

The solution was to have the checkbox trigger whether the password field is inserted in the DOM, not just its visibility.

Pseudo implementation for AngularJS:

<input type="checkbox" ng-model="createPassword">
<input ng-if="changePassword" type="password">
Dag Høidahl
  • 6,759
  • 7
  • 46
  • 62
2

With regards to Internet Explorer 11, there is a security feature in place that can be used to block autocomplete.

It works like this:

Any form input value that is modified in JavaScript after the user has already entered it is flagged as ineligible for autocomplete.

This feature is normally used to protect users from malicious websites that want to change your password after you enter it or the like.

However, you could insert a single special character at the beginning of a password string to block autocomplete. This special character could be detected and removed later on down the pipeline.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Alexander Ryan Baggett
  • 2,170
  • 4
  • 28
  • 55
2

You can use autocomplete = off in input controls to avoid auto completion

For example:

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

if the above code doesn't works then try to add those attributes also

autocapitalize="off" autocomplete="off"

or

Change input type attribute to type="search". Google doesn't apply auto-fill to inputs with a type of search.

Rob
  • 25,569
  • 15
  • 73
  • 87
Codemaker
  • 4,115
  • 1
  • 32
  • 30
2

My solution is Change the text inputs type dynamically using angular js directive and it works like charm

first add 2 hidden text fields

and just add a angular directive like this

 (function () {

    'use strict';

    appname.directive('changePasswordType', directive);

    directive.$inject = ['$timeout', '$rootScope',  '$cookies'];

    function directive($timeout,  $rootScope, $cookies) {
        var directive = {
            link: link,
            restrict: 'A'
        };

        return directive;

        function link(scope,element) {
            var process = function () {
                var elem =element[0];
                elem.value.length > 0 ? element[0].setAttribute("type", "password") :
                element[0].setAttribute("type", "text");
            }

            element.bind('input', function () {
                process();
            });

            element.bind('keyup', function () {
                process();
            });
        }
    }
})()

then use it in your text field where you need to prevent auto complete

    <input type="text" style="display:none">\\can avoid this 2 lines
    <input type="password" style="display:none">
    <input type="text"  autocomplete="new-password" change-password-type>

NB: dont forget to include jquery, and set type ="text" initially

Edison
  • 1,183
  • 12
  • 27
2

I wanted something that took the field management completely out of the browser's hands, so to speak. In this example, there's a single standard text input field to capture a password — no email, user name etc...

<input id='input_password' type='text' autocomplete='off' autofocus>

There's a variable named "input", set to be an empty string...

var input = "";

The field events are monitored by JQuery...

  1. On focus, the field content and the associated "input" variable are always cleared.
  2. On keypress, any alphanumeric character, as well as some defined symbols, are appended to the "input" variable, and the field input is replaced with a bullet character. Additionally, when the Enter key is pressed, the typed characters (stored in the "input" variable) are sent to the server via Ajax. (See "Server Details" below.)
  3. On keyup, the Home, End, and Arrow keys cause the "input" variable and field values to be flushed. (I could have gotten fancy with arrow navigation and the focus event, and used .selectionStart to figure out where the user had clicked or was navigating, but it's not worth the effort for a password field.) Additionally, pressing the Backspace key truncates both the variable and field content accordingly.

$("#input_password").off().on("focus", function(event) {
    $(this).val("");
    input = "";

}).on("keypress", function(event) {
    event.preventDefault();

    if (event.key !== "Enter" && event.key.match(/^[0-9a-z!@#\$%&*-_]/)) {
        $(this).val( $(this).val() + "•" );
        input += event.key;
    }
    else if (event.key == "Enter") {
        var params = {};
        params.password = input;

        $.post(SERVER_URL, params, function(data, status, ajax) {
            location.reload();
        });
    }

}).on("keyup", function(event) {
    var navigationKeys = ["Home", "End", "ArrowLeft", "ArrowRight", "ArrowUp", "ArrowDown"];
    if ($.inArray(event.key, navigationKeys) > -1) {
        event.preventDefault();
        $(this).val("");
        input = "";
    }
    else if (event.key == "Backspace") {
        var length = $(this).val().length - 1 > 0 ? $(this).val().length : 0;
        input = input.substring(0, length);
    }
});

Front-End Summary

In essence, this gives the browser nothing useful to capture. Even if it overrides the autocomplete setting, and/or presents a dropdown with previously entered values, all it has is bullets stored for the field value.


Server Details (optional reading)

As shown above, Javascript executes location.reload() as soon as the server returns a JSON response. (This logon technique is for access to a restricted administration tool. Some of the overkill, related to the cookie content, could be skipped for a more generalized implementation.) Here are the details:

  • When a user navigates to the site, the server looks for a legitimate cookie.
  • If there is no cookie, the logon page is presented. When the user enters a password and it is sent via Ajax, the server confirms the password and also checks to see if the user's IP is in an Authorized IP list.
  • If either the password or IP are not recognized, the server doesn't generate a cookie, so when the page reloads, the user sees the same logon page.
  • If both the password and IP are recognized, the server generates a cookie that has a ten-minute life span, and it also stores two scrambled values that correspond with the time-frame and IP.
  • When the page reloads, the server finds the cookie and verifies that the scrambled values are correct (i.e., that the time-frame corresponds with the cookie's date and that the IP is the same).
  • The process of authenticating and updating the cookie is repeated every time the user interacts with the server, whether they are logging in, displaying data, or updating a record.
  • If at all times the cookie's values are correct, the server presents the full website (if the user is logging in) or fulfills whatever display or update request was submitted.
  • If at any time the cookie's values are not correct, the server removes the current cookie which then, upon reload, causes the logon page to be re-displayed.
Alan M.
  • 1,170
  • 2
  • 15
  • 29
2

Easy Hack

Make input read-only

<input type="text" name="name" readonly="readonly">

Remove read-only after timeout

$(function() {
        setTimeout(function() {
            $('input[name="name"]').prop('readonly', false);
        }, 50);
    });
Kishan Vaghela
  • 7,008
  • 3
  • 36
  • 63
2

unfortunately this option was removed in most browsers, so it is not possible to disable the password hint, until today I did not find a good solution to work around this problem, what we have left now is to hope that one day this option will come back.

Lucas
  • 189
  • 5
  • 35
2

None of the solutions I've found at this day bring a real working response.

Solutions with an autocomplete attribute do not work.

So, this is what I wrote for myself:

<input type="text" name="UserName" onkeyup="if (this.value.length > 0) this.setAttribute('type', 'password'); else this.setAttribute('type', 'text');" >

You should do this for every input field you want as a password type on your page.

And this works.

cheers

Zain Aftab
  • 709
  • 7
  • 21
Patrick
  • 61
  • 4
  • Hi @Patrick you're answering a question which is over 11 years old. Please try to answer new questions, this is more helpful. – Archer Apr 08 '20 at 16:39
  • @Archer your comment is 100% dead wrong. The age of a question has no bearing on whether or not it should receive a new answer. In fact, too many people are focused on answering new questions and they end up posting redundant advice on questions that were resolved years earlier and should have been closed as a duplicate. What IS crucial is that every new answer on a page should contain unique and valuable insights. An answer that only gives advice which has already been stated by an earlier answer is likely to be DV'ed then removed as redundant content. – mickmackusa Aug 28 '20 at 05:16
2

Pretty sure this is the most generic solution as of today

This stops auto-complete and the popup suggestion box too.

Intro

Let's face it, autocomplete=off or new-password doesn't seem to work. It's should do but it doesn't and every week we discover something else has changed and the browser is filling a form out with more random garbage we don't want. I've discovered a really simple solution that doesn't need autocomplete on sign in pages.

How to implement

Step 1). Add the same function call to the onmousedown and onkeyup attributes for your username and password fields, making sure you give them an id AND note the code at the end of the function call. md=mousedown and ku=keyup

For the username field only add a value of &nbsp; as this prevents the form auto-filling on entry to the page.

For example:

<input type="text" value="&nbsp;" id="myusername" onmousedown="protectMe(this,'md')" onkeyup="protectMe(this,'ku')" />

Step 2). Include this function on the page

function protectMe(el,action){

 // Remove the white space we injected on startup
 var v = el.value.trim();
 
// Ignore this reset process if we are typing content in
// and only acknowledge a keypress when it's the last Delete
// we do resulting in the form value being empty
 if(action=='ku' && v != ''){return;} 

// Fix double quote issue (in the form input) that results from writing the outerHTML back to itself
  v = v.replace(/"/g,'\\"'); 
  
  // Reset the popup appearing when the form came into focus from a click  by rewriting it back
  el.outerHTML=el.outerHTML; 

  // Issue instruction to refocus it again, insert the value that existed before we reset it and then select the content.
  setTimeout("var d=document.getElementById('"+el.id+"'); d.value=\""+v+"\";d.focus();if(d.value.length>1){d.select();}",100);
}

What does it do?

  • Firstly it adds an &nbsp; space to the field so the browser tries to find details related to that but doesn't find anything, so that's auto-complete fixed
  • Secondly, when you click, the HTML is created again, cancelling out the popup and then the value is added back selected.
  • Finally, when you delete the string with the Delete button the popup usually ends up appearing again but the keyup check repeats the process if we hit that point.

What are the issues?

  • Clicking to select a character is a problem but for a sign in page most will forgive the fact it select all the text
  • Javascript does trim any inputs of blank spaces but you might want to do it too on the server side to be safe

Can it be better?

Yes probably. This is just something I tested and it satisfies my basic need but there might be more tricks to add or a better way to apply all of this.

Tested browsers

Tested and working on latest Chrome, Firefox, Edge as of this post date

1

autocomplete = 'off' didn't work for me, anyway i set the value attribute of the input field to a space i.e <input type='text' name='username' value=" "> that set the default input character to a space, and since the username was blank the password was cleared too.

Sam
  • 41
  • 1
  • 7
1

None of the provided answers worked on all the browsers I tested. Building on already provided answers, this is what I ended up with, (tested) on Chrome 61, Microsoft Edge 40 (EdgeHTML 15), IE 11, Firefox 57, Opera 49 and Safari 5.1. It is wacky as a result of many trials; however it does work for me.

<form autocomplete="off">
    ...
    <input type="password" readonly autocomplete="off" id="Password" name="Password" onblur="this.setAttribute('readonly');" onfocus="this.removeAttribute('readonly');" onfocusin="this.removeAttribute('readonly');" onfocusout="this.setAttribute('readonly');" />
    ...
</form> 

<script type="text/javascript">
    $(function () {           
        $('input#Password').val('');
        $('input#Password').on('focus', function () {
        if (!$(this).val() || $(this).val().length < 2) {
            $(this).attr('type', 'text');
        }
        else {
            $(this).attr('type', 'password');
        }
    });
    $('input#Password').on('keyup', function () {
        if (!$(this).val() || $(this).val().length < 2) {
            $(this).attr('type', 'text');
        }
        else {
            $(this).attr('type', 'password');
        }
    });
    $('input#Password').on('keydown', function () {
        if (!$(this).val() || $(this).val().length < 2) {
            $(this).attr('type', 'text');
        }
        else {
            $(this).attr('type', 'password');
        }
    });
</script>
zinczinc
  • 518
  • 5
  • 9
1

Fixed. Just need to add above real input field

https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion - MDN https://medium.com/paul-jaworski/turning-off-autocomplete-in-chrome-ee3ff8ef0908 - medium tested on EDGE, Chrome(latest v63), Firefox Quantum (57.0.4 64-бит), Firefox(52.2.0) fake fields are a workaround for chrome/opera autofill getting the wrong fields

 const fakeInputStyle = {opacity: 0, float: 'left', border: 'none', height: '0', width: '0'}

 <input type="password" name='fake-password' autoComplete='new-password' tabIndex='-1' style={fakeInputSyle} />

<TextField
  name='userName'
  autoComplete='nope'
  ... 
/>

<TextField
      name='password'
      autoComplete='new-password'
      ... 
    />
Palaniichuk Dmytro
  • 2,041
  • 3
  • 26
  • 53
1

I was able to stop Chrome 66 from autofilling by adding two fake inputs and giving them position absolute:

<form style="position: relative">
  <div style="position: absolute; top: -999px; left: -999px;">
    <input name="username" type="text" />
    <input name="password" type="password" />
  </div>
  <input name="username" type="text" />
  <input name="password" type="password" />

At first, I tried adding display:none; to the inputs but Chrome ignored them and autofilled the visible ones.

1

This worked for me like a charm.

  1. Set the autocomplete attribute of the form to off
  2. Add a dummy input field and set its attribute also to off.
<form autocomplete="off">
 <input type="text" autocomplete="off" style="display:none">
</form>
zapping
  • 3,963
  • 6
  • 38
  • 54
1

I'v solved putting this code after page load:

<script>
var randomicAtomic = Math.random().toString(36).substring(2, 15) + Math.random().toString(36).substring(2, 15);
  $('input[type=text]').attr('autocomplete',randomicAtomic);
</script>
Marcelo Agimóvel
  • 1,432
  • 2
  • 14
  • 23
1

I went through the same problem, today 09/10/2019 only solution I found was this

Add autocomplete="off" into the form tag.

put 1 false inputs after opening form tag.

<input id="username" style="display:none" type="text" name="fakeusernameremembered">

but it won't work on password type field, try

<input type="text" oninput="turnOnPasswordStyle()" placeholder="Enter Password" name="password" id="password" required>

on script

function turnOnPasswordStyle() {
    $('#password').attr('type', "password");
}

This is tested on Chrome-78, IE-44, Firefox-69

Tauhed
  • 99
  • 6
1

The simplest answer is

<input autocomplete="on|off">

But keep in mind the browser support. Currently, autocomplete attribute is supported by

Chrome 17.0 & latest IE 5.0 & latest
Firefox 4.0 & latest
Safari 5.2 & latest
Opera 9.6 & latest

azizsagi
  • 228
  • 1
  • 12
1

My solution with jQuery. It may not be 100% reliable, but it works for me. The idea is described in code annotations.

    /**
 * Prevent fields autofill for fields.
 * When focusing on a text field with autocomplete (with values: "off", "none", "false") we replace the value with a new and unique one (here it is - "off-forced-[TIMESTAMP]"),
 * the browser does not find this type of autocomplete in the saved values and does not offer options.
 * Then, to prevent the entered text from being saved in the browser for a our new unique autocomplete, we replace it with the one set earlier when the field loses focus or when user press Enter key.
 * @type {{init: *}}
 */
var PreventFieldsAutofill = (function () {
    function init () {
        events.onPageStart();
    }

    var events = {
        onPageStart: function () {
            $(document).on('focus', 'input[autocomplete="off"], input[autocomplete="none"], input[autocomplete="false"]', function () {
                methods.replaceAttrs($(this));
            });
            $(document).on('blur', 'input[data-prev-autocomplete]', function () {
                methods.returnAttrs($(this));
            });
            $(document).on('keydown', 'input[data-prev-autocomplete]', function (event) {
                if (event.keyCode == 13 || event.which == 13) {
                    methods.returnAttrs($(this));
                }
            });
            $(document).on('submit', 'form', function () {
                $(this).find('input[data-prev-autocomplete]').each(function () {
                    methods.returnAttrs($(this));
                });
            });
        }
    };

    var methods = {
        /**
         * Replace value of autocomplete and name attribute for unique and save the original value to new data attributes
         * @param $input
         */
        replaceAttrs: function ($input) {
            var randomString = 'off-forced-' + Date.now();
            $input.attr('data-prev-autocomplete', $input.attr('autocomplete'));
            $input.attr('autocomplete', randomString);
            if ($input.attr('name')) {
                $input.attr('data-prev-name', $input.attr('name'));
                $input.attr('name', randomString);
            }
        },
        /**
         * Restore original autocomplete and name value for prevent saving text in browser for unique value
         * @param $input
         */
        returnAttrs: function ($input) {
            $input.attr('autocomplete', $input.attr('data-prev-autocomplete'));
            $input.removeAttr('data-prev-autocomplete');
            if ($input.attr('data-prev-name')) {
                $input.attr('name', $input.attr('data-prev-name'));
                $input.removeAttr('data-prev-name');
            }
        }
    };

    return {
        init: init
    }
})();
PreventFieldsAutofill.init();
.input {
  display: block;
  width: 90%;
  padding: 6px 12px;
  font-size: 14px;
  line-height: 1.42857143;
  color: #555555;
  background-color: #fff;
  background-image: none;
  border: 1px solid #ccc;
  border-radius: 4px;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.0/jquery.min.js"></script>
<form action="#">
  <p>
    <label for="input-1">Firts name without autocomplete</label><br />
    <input id="input-1" class="input" type="text" name="first-name" autocomplete="off" placeholder="Firts name without autocomplete" />
  </p>
  <p>
    <label for="input-2">Firts name with autocomplete</label><br />
    <input id="input-2" class="input" type="text" name="first-name" autocomplete="given-name" placeholder="Firts name with autocomplete" />
  </p>
  <p>
    <button type="submit">Submit form</button>
  </p>
</form>
xixe
  • 120
  • 1
  • 6
1

Simply try to put attribute autocomplete with value "off" to input type.

<input type="password" autocomplete="off" name="password" id="password" />
Nagnath Mungade
  • 513
  • 5
  • 8
1

The autofill functionality changes the value without selecting the field. We could use that in our state management to ignore state changes before the select event.

An example in React:

import React, {Component} from 'react';

class NoAutoFillInput extends Component{

    constructor() {
        super();
        this.state = {
            locked: true
        }
    }

    onChange(event){
        if (!this.state.locked){
            this.props.onChange(event.target.value);
        }
    }

    render() {
        let props = {...this.props, ...{onChange: this.onChange.bind(this)}, ...{onSelect: () => this.setState({locked: false})}};
        return <input {...props}/>;
    }
}

export default NoAutoFillInput;

If the browser tries to fill the field, the element is still locked and the state is not affected. Now you can just replace the input field with a NoAutoFillInput component to prevent autofill:

<div className="form-group row">
    <div className="col-sm-2">
        <NoAutoFillInput type="text" name="myUserName" className="form-control" placeholder="Username" value={this.state.userName} onChange={value => this.setState({userName: value})}/>
    </div>
    <div className="col-sm-2">
        <NoAutoFillInput type="password" name="myPassword" className="form-control" placeholder="Password" value={this.state.password} onChange={value => this.setState({password: value})}/>
    </div>
</div>

Off course, this idea could be used with other JS frameworks as well.

Jos
  • 823
  • 1
  • 10
  • 23
1
<input type="text" name="attendees" id="autocomplete-custom-append">

<script>
  /* AUTOCOMPLETE */

  function init_autocomplete() {

    if (typeof ($.fn.autocomplete) === 'undefined') {
      return;
    }
    // console.log('init_autocomplete');

    var attendees = {
      1: "Shedrack Godson",
      2: "Hellen Thobias Mgeni",
      3: "Gerald Sanga",
      4: "Tabitha Godson",
      5: "Neema Oscar Mracha"
    };

    var countriesArray = $.map(countries, function (value, key) {
      return {
        value: value,
        data: key
      };
    });

    // initialize autocomplete with custom appendTo
    $('#autocomplete-custom-append').autocomplete({
      lookup: countriesArray
    });

  };
</script>
Shedrack
  • 302
  • 2
  • 10
1

I must have spent two days on this discussion before resorting to creating my own solution:

First, if it works for the task, ditch the input and use a textarea. To my knowledge, autofill/autocomplete has no business in a textarea, which is a great start in terms of what we're trying to achieve. Now you just have to change some of the default behaviors of that element to make it act like an input.

Next, you'll want to keep any long entries on the same line, like an input, and you'll want the textarea to scroll along the y-axis with the cursor. We also want to get rid of the resize box, since we're doing our best to mimic the behavior of an input, which doesn't come with a resize handle. We achieve all of this with some quick CSS:

#your-textarea {
  resize: none;
  overflow-y: hidden;
  white-space: nowrap;
}

Finally, you'll want to make sure the pesky scrollbar doesn't arrive to wreck the party (for those particularly long entries), so make sure your text-area doesn't show it:

#your-textarea::-webkit-scrollbar {
  display: none;
}

Easy peasy. We've had zero autocomplete issues with this solution.

Dharman
  • 21,838
  • 18
  • 57
  • 107
1
  1. Leave inputs with text type and hidden.
  2. On DOMContentLoaded, call a function that changes the types for password and display the fields, with a delay of 1s.

document.addEventListener('DOMContentLoaded', changeInputsType);

function changeInputsType() {
    setTimeout(function() {
        $(/*selector*/).prop("type", "password").show();
    }, 1000);
}
  • 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. – ZF007 Nov 24 '20 at 13:13
1

After trying all solutions (some have worked partly, disabling autofill but not autocomplete, some did not work at all) I've found the best solution as of 2020 to be adding type="search" and autocomplete="off" to your input element. like this:

<input type="search" /> or <input type="search" autocomplete="off" />

Also make sure to have autocomplete="off" on the form element. this works perfectly and disables both autocomplete and autofill.

Also, if your'e using type="email" or any other text type, you'll need to add autocomplete="new-email" and that will disable both perfectly. same goes for type="password". just add a "new-" prefix to the autocomplete together with the type. like that:

<input type="email" autocomplete="new-email" />
<input type="password" autocomplete="new-password" />
Elazar Zadiki
  • 344
  • 2
  • 14
1

I already posted a solution for this here: https://stackoverflow.com/a/60664102/5117084

The workaround is to set the autocomplete attribute as "cc-csc" that value is the CVC of a credit card and that they are no allowed to store it! (for now...)

autocomplete="cc-csc"

Guido
  • 161
  • 1
  • 6
1

[Works in 2021 for Chrome(v88, 89, 90), Firefox, Brave, Safari]

The old answers already written here will work with trial and error, but most of them don't link to any official doc or what Chrome has to say on this matter.

The issue mentioned in the question is because of Chrome's autofill feature, and here is Chrome's stance on it in this bug link - https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164

To put it simply, there are two cases -

  • [CASE 1]: Your input type is something other than password. In this case, the solution is simple, and has three steps.

  • Add name attribute to input

  • name should not start with a value like email or username, otherwise Chrome still ends up showing the dropdown. For example, name="emailToDelete" shows the dropdown, but name="to-delete-email" doesn't. Same applies for autocomplete attribute.

  • Add autocomplete attribute, and add a value which is meaningful for you, like new-field-name

It will look like this, and you won't see the autofill for this input again for the rest of your life -

  <input type="text/number/something-other-than-password" name="x-field-1" autocomplete="new-field-1" />
  • [CASE 2]: input type is password
  • Well, in this case, irrespective of your trials, Chrome will show you the dropdown to manage passwords / use an already existing password. Firefox will also do something similar, and same will be the case with all other major browsers. [1]
  • In this case, if you really want to stop the user from seeing the dropdown to manage passwords / see a securely generated password, you will have to play around with JS to switch input type, as mentioned in the other answers of this question.

[1] A detailed MDN doc on turning off autocompletion - https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

thisisashwani
  • 1,403
  • 2
  • 16
  • 19
1

Simply change the name attribute in your input element to something unique each time and it will never autocomplete again!

An example might be a time tic added at the end. Your server would only need to parse the first part of the text name to retrieve the value back.

<input type="password" name="password_{DateTime.Now.Ticks}" value="" />
Stokely
  • 4,231
  • 1
  • 14
  • 10
1

Here's the perfect solution that will work in all browsers as of May 2021!

TL;DR

Rename your input field names and field ids to something non-related like 'data_input_field_1'. Then add the &#8204; character into the middle of your labels. This is a non-printing character, so you won't see it, but it tricks the browser into not recognizing the field as one needing auto-completing, thus no built-in auto-complete widget is shown!

The Details

Almost all browsers use a combination of the field's name, id, placeholder, and label to determine if the field belongs to a group of address fields that could benefit from auto-completion. So if you have a field like <input type="text" id="address" name="street_address"> pretty much all browsers will interpret the field as being an address field. As such the browser will display its built-in auto-completion widget. The dream would be that using the attribute autocomplete="off" would work, unfortunately, most browsers nowadays don't obey the request.

So we need to use some trickery to get the browsers to not display the built-in autocomplete widget. The way we will do that is by fooling the browser into believing that the field is not an address field at all.

Start by renaming the id and the name attributes to something that won't give away that you're dealing with address-related data. So rather than using <input type="text" id="city-input" name="city">, use something like this instead <input type="text" id="input-field-3" name="data_input_field_3">. The browser doesn't know what data_input_field_3 represents. But you do.

If possible, don't use placeholder text as most browsers will also take that into account. If you have to use placeholder text, then you'll have to get creative and make sure you're not using any words relating to the address parameter itself (like City). Using something like Enter location can do the trick.

The final parameter is the label attached to the field. However, if you're like me, you probably want to keep the label intact and display recognizable fields to your users like "Address", "City", "State", "Country". Well, great news: YOU CAN! The best way to achieve that is to insert a Zero-Width Non-Joiner Character &#8204; as the second character in the label. So replacing <label>City</label> with <label>C&#8204;ity</label>. This is a non-printing character, so your users will see City, but the browser will be tricked into seeing C ity and not recognize the field!

Mission accomplished! If all went well, the browser should not display the built-in address auto-completion widget on those fields anymore!

Hope this helps you in your endeavors!

0

You can add name in attribute name how email address to you form and generate email value for example:

<form id="something-form">
  <input style="display: none" name="email" value="randomgeneratevalue"></input>
  <input type="password">
</form>

If you use this method, Google Chrome can't insert autofill password.

ladone
  • 102
  • 8
0

Just autocomplete="off" list="autocompleteOff" in your input and work done for IE/Edge! and for chrome add autocomplete="new password"

0

I was fighting to autocomplete for years. I've tried every single suggestion, and nothing worked for me. Adding by jQuery 2 attributes worked well:

$(document).ready( function () {
    setTimeout(function() {
        $('input').attr('autocomplete', 'off').attr('autocorrect', 'off');
    }, 10);
}); 

will result in HTML

<input id="start_date" name="start_date" type="text" value="" class="input-small hasDatepicker" autocomplete="off" placeholder="Start date" autocorrect="off">
Adrian P.
  • 4,484
  • 1
  • 40
  • 43
0

Works with Chrome 84.0.4147.105

1. Assign text type to password fields and add a class, e.g. "fakepasswordtype"

<input type="text" class="fakepasswordtype" name="password1">
<input type="text" class="fakepasswordtype" name="password2">

2. Then use jQuery to change the type back to password the moment when first input is done

jQuery(document).ready(function($) {
    $('.fakepasswordtype').on('input', function(e){
        $(this).prop('type', 'password');
    });
});

This stopped Chrome from it's nasty ugly behavior from auto filling.

Juergen
  • 1,126
  • 17
  • 27
0

Chrome keeps trying to force autocomplete. So there are a few things you need to do.

The input field's attributes id and name need to not be recognizable. So no values such as name, phone, address, etc.

The adjacent label or div also needs to not be recognizable. However, you may wonder, how will the user know? Well there is a fun little trick you can do with ::after using the content. You can set it to a letter.

<label>Ph<span class='o'></span>ne</label>
<input id='phnbr' name='phnbr' type='text'>

<style>
  span.o {
    content: 'o';
  }
</style>
jemiloii
  • 21,771
  • 7
  • 47
  • 76
-4

To avoid autocomplete add the autocomplete="off" to your html input property.

Example:

<input type="text" name="foo" autocomplete="off" />
mickmackusa
  • 33,121
  • 11
  • 58
  • 86