Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Disable HTML form input autocomplete and autofill

Disable HTML Form Input Autocomplete and Autofill

  1. Add autocomplete="off" onto <form> element;
  2. Add hidden <input> with autocomplete="false" as a first children element of the form.
<form autocomplete="off" method="post" action="">
    <input autocomplete="false" name="hidden" type="text" style="display:none;">
    ...

This formation is going to prevent Chrome and Firefox to offer autofill and autocomplete for all input fields inside the form.

@zanderwar

This comment has been minimized.

Copy link

commented Mar 20, 2017

Wrong, false is not an option on autocomplete, all must be off

@Westie

This comment has been minimized.

Copy link

commented Mar 21, 2017

In addition, autocomplete=off is also a nonsense as most browsers refuse to adhere to this - the best way is to make an element [readonly] and then on hover/click/blur/focus, remove [readonly]

2019 edit: use <input type="search" />

@jehzlau

This comment has been minimized.

Copy link

commented Oct 9, 2017

+1 to Zanderwar, false is not working. I just tried it now. :D

@Fellach

This comment has been minimized.

Copy link

commented Oct 13, 2017

@zanderwar, @jehzlau,

please read Turning_off_form_autocompletion, where it stays:

many modern browsers do not support autocomplete="off" for login fields

@RedSparr0w

This comment has been minimized.

Copy link

commented Nov 17, 2017

@Fellach The link you posted states that they do not support autocomplete="off" for login fields, all other input fields should be fine.

many modern browsers do not support autocomplete="off" for login fields

It also says you should use autocomplete="new-password" for new password fields (can be used in login fields) in order for it to not be auto filled.

If an author would like to prevent the autofilling of password fields in user management pages where a user can specify a new password for someone other than themself, autocomplete="new-password" should be specified, though support for this has not been implemented in all browsers yet.

@WarenGonzaga

This comment has been minimized.

Copy link

commented Dec 26, 2017

This is helpful for me... thanks for sharing and also some comments here are helpful!

@eloisetaylor5693

This comment has been minimized.

Copy link

commented Jan 4, 2018

Using false (or any other string that's not on or off) is a valid workaround. See bug: https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164

@swt83

This comment has been minimized.

Copy link

commented Jan 12, 2018

I had to use false to get this to actually stop the auto-fill, and I had to do it on each individual form element instead of just the form itself. This is a pretty big problem.

@anik786

This comment has been minimized.

Copy link

commented Mar 1, 2018

This works, but not the way that you think it does.

Officially it should be: autocomplete="off". However many browsers bizarrely ignore this.

Therefore it's best to just put some random string on the autocomplete section like:

autocomplete="autocomplete_off_hack_xfr4!k"

That's why autcomplete="false" accidentally works.

Note that make sure the autocomplete value for each input is different. Hence the random string at the end. Or else you may get suggestions from fields with the same autocomplete value.

@zhoolu

This comment has been minimized.

Copy link

commented Mar 8, 2018

@anik786

Thanks, this worked like a charm, autocomplete="anyrandomstring".

@kcaporaso

This comment has been minimized.

Copy link

commented May 3, 2018

These tricks no longer seem to work in Chrome 66.0.3359.139. I was using autocomplete="nope" and all of a sudden autocomplete is back on those forms. Frustrating, and this is for non-login forms, things like address, city.

@marc-thomas

This comment has been minimized.

Copy link

commented May 14, 2018

autocomplete="random" does not work anymore for type="password" fields - seems to work with type="text" and other field types :(

@thdoan

This comment has been minimized.

Copy link

commented May 15, 2018

According to MDN, "many modern browsers do not support autocomplete="off" for login fields," in which case I assume the random value hack would also not work (basically modern browsers will just ignore this attribute altogether for login fields).

@kingdonb

This comment has been minimized.

Copy link

commented May 30, 2018

@kcaporaso I think that Chrome must have finally relented on their contrarian interpretation of the standard. I'm encountering this issue for the first time, and autocomplete="off" on the form tag seems to work, even in spite of thousands of complaints scattered across every help site on the internet claiming to the contrary.

Thank you for your post, I was beginning to think I was crazy but if I'm right and you're right, then I guess the behavior has been changed by an update within the last month or two.

@hugocruz

This comment has been minimized.

Copy link

commented Jun 18, 2018

As @thdoan referenced the MDN article explains more about it.
Most relevant for me was:

In some cases, the browser will continue 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 enforcing non-autocompletion is to assign an invalid value to the attribute, for example:

autocomplete="nope"

Since this value is not a valid one for the autocomplete attribute, the browser has no way to match it, and stops trying to autocomplete the field.

This explains why false works as stated above.

Edit: I'm using Chrome Version 67.0.3396.87 (Official Build) (64-bit)

@benbonnet

This comment has been minimized.

Copy link

commented Jun 29, 2018

@kingdonb so then I'll scatter another one here as it looks like the issue is back again, stronger than ever

@jprasmussen

This comment has been minimized.

Copy link

commented Jul 6, 2018

Adding autocomplete="off" to a text input worked for me in Chrome.

@Acidic9

This comment has been minimized.

Copy link

commented Jul 9, 2018

Nothing seems to work for me in Google Chrome..

@Abolfazl

This comment has been minimized.

Copy link

commented Jul 10, 2018

I have tried various options and nothing is working for me in Chrome.

@raphael22

This comment has been minimized.

Copy link

commented Jul 17, 2018

So... autocomplete='off' trigger a warning telling me to precise my autocomplete...
autocomplete='false' or another value not in spec does remove the warning but try to autocomplete with previous value known by the input...
This spec is a ****ing mess !

@erik2504

This comment has been minimized.

Copy link

commented Jul 25, 2018

It's back again indeed. In v68 it ignores all known workarounds to prevent auto-filling fields.
autocomplete="random-string-here" is broken. The autocomplete="off" gets ignored. Even using the method where you make your fields readonly and remove that attribute on focus doesnt seem to work anymore....

@fschlaef

This comment has been minimized.

Copy link

commented Jul 25, 2018

Nothing works. All my search fields retain recently entered values, which is completely idiotic, and tons of developers are looking like idiots for not being able to remove this, all because Google thinks their idea of "user experience" is the best and nobody should question it. Very well done.

@JefferyHus

This comment has been minimized.

Copy link

commented Jul 25, 2018

Since everyone is pissed off by google, maybe this trick can help you around, assign wrong values to autocomplete attribute.
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

@lancegliser

This comment has been minimized.

Copy link

commented Aug 1, 2018

I'm currently forced to do a browser specific sniff. If it's chrome, use autocomplete="disabled" which handles both autocomplete and address based autofill (two separate things):

// Weird browser specific hack, because autofill isn't autocomplete
// Chrome demands disabled to turn it off
element.autocomplete = isGoogleChrome() ? 'disabled' :  'off';

For reference, here's the most up to date sniffer I found:
https://stackoverflow.com/questions/4565112/javascript-how-to-find-out-if-the-user-browser-is-chrome

I feel terrible having to do this

@Adavis619

This comment has been minimized.

Copy link

commented Aug 13, 2018

autocomplete="off" works for me in IE, Chrome, and FF.

@MissIrina

This comment has been minimized.

Copy link

commented Aug 14, 2018

This worked for me -> autocomplete="anyrandomstring".

@GuiDeto

This comment has been minimized.

Copy link

commented Aug 14, 2018

autocomplete="new-password"

@mitchellurgero

This comment has been minimized.

Copy link

commented Aug 17, 2018

None of this worked for me so I used (Requires jQuery):

...
<input class="user" type="password" id="pass" class="form-control" placeholder="Account Password" name="password" value="" readonly>
...

<script>
$( document ).ready(function() {
    setTimeout(function(){
        $("#pass").attr('readonly', false);
        $("#pass").focus();
    },500);
});
</script>

Which so far has worked in IE10+, Chrome, Firefox, Safari, etc. (Pretty much every web browser used in this day and age.)

Also works in IE9, but who uses that?!

@imegory

This comment has been minimized.

Copy link

commented Sep 22, 2018

My two cents on this subject: on Chrome, autocomplete="nope" seems to work. Trying autocomplete="off" seems to be ignored by Chrome. I am pretty amazed that this has not been settled at the W3C level.

@IamCharmaineJoy

This comment has been minimized.

Copy link

commented Sep 26, 2018

autocomplete="off" works for me in Chrome 69 on macOS (Sierra) and safari

@greenjackal

This comment has been minimized.

Copy link

commented Sep 28, 2018

A jQuery plugin can solve this problem for all browsers.
https://github.com/terrylinooo/jquery.disableAutoFill

@rubensstarke

This comment has been minimized.

Copy link

commented Oct 17, 2018

use autocomplete="anyrandomstring"
And dont use id="password" or id="email", use anything else like id="field1" this should be works!

@chriscooning

This comment has been minimized.

Copy link

commented Oct 17, 2018

having to change the name of the id seems very wrong / broken to me - this is especially tedious when you have large forms.
The jQuery plugin is the only thing I've found that works in chrome.

What a shame.

@jbgraug

This comment has been minimized.

Copy link

commented Oct 25, 2018

Just remove the name attribute

@CharlyPoppins

This comment has been minimized.

Copy link

commented Nov 6, 2018

Nice workaround, thank you :)

@salmanmd786

This comment has been minimized.

Copy link

commented Nov 14, 2018

Just remove the name attribute

After so many trails, luckily your solution works. Kudos.

@DanNeely

This comment has been minimized.

Copy link

commented Nov 21, 2018

The jquery plugin is also preventing the PW from being *ed out by default. That's terrible in a different way.

@mandaputtra

This comment has been minimized.

Copy link

commented Nov 28, 2018

You should updated this gist man, many person googled see this

@dhniels

This comment has been minimized.

Copy link

commented Nov 30, 2018

The only thing I've been able to get to work is autocomplete="new-password" on each input i want it disabled (see the answer by "tibalt" in this stack overflow post)

only tested on chrome 70 so far.

Is there any "one size fits all" solution for this? This spec seems to be a total shitshow. Dependent on browser, attributes, type, input-only vs. form-wide, mobile vs desktop, etc. Disastrous.

UPDATE: testing on chrome, if I had a name attribute, it breaks. so this only works (in chrome, anyway) if name is not set.

@mariusrazoux

This comment has been minimized.

Copy link

commented Dec 3, 2018

<input type="text"
      id="search"
      autocomplete="off"
      autocorrect="off"
      autocapitalize="none"
      spellcheck="false" />

works for me without removing the name attr

@lmpampaletakis

This comment has been minimized.

Copy link

commented Dec 4, 2018

The thing is to work for passwords too. And when I say work, I mean one solid solution

@stiv-yakovenko

This comment has been minimized.

Copy link

commented Dec 15, 2018

autocomplete="nope" worked for me, autocomplete="off" didn't

@JeanCollas

This comment has been minimized.

Copy link

commented Dec 17, 2018

Feel free to vote and comment on the bugtracker... I did not find any valid solution yet. Once address autofill is enabled, it covers ggle place autocomplete....

https://bugs.chromium.org/p/chromium/issues/detail?id=587466

@cimoskill

This comment has been minimized.

Copy link

commented Dec 19, 2018

For me I confirm the best way is plain inline javascript like:
<input type="text" name="email" class="form-control" readonly="readonly" onfocus="javascript: this.removeAttribute('readonly')" />
I added the readonly attribute from start and the onfocus inline js.
I really don't like this kind of things, but I think it's far better than "removing the name attribute" omg.
Incredible issue btw.
Ciao!

@troyanvic

This comment has been minimized.

Copy link

commented Dec 19, 2018

for input tag attribute autocomplete should be off, for example <input id="date" type="text" name="date" value="2018/12/19" autocomplete="off" />

@cimoskill

This comment has been minimized.

Copy link

commented Dec 19, 2018

@troyanvic yes but that solutions doesn't work on all browsers. I still had all my form with autocomplete="off" and on each input element. That's the central point of this topic. Cya

@NicolayD

This comment has been minimized.

Copy link

commented Jan 7, 2019

For me, "off" and "false" don't work but any other string I tried, including "nope", did work.

@danielgary

This comment has been minimized.

Copy link

commented Jan 15, 2019

Hope this helps, set the autoComplete="nope" on the form element

              <form autocomplete="nope">
@LucasBSC

This comment has been minimized.

Copy link

commented Jan 17, 2019

nope incredibly worked for me lol

@tomheathershub

This comment has been minimized.

Copy link

commented Jan 23, 2019

Same for me! very strange

@CaptainN

This comment has been minimized.

Copy link

commented Jan 26, 2019

Why is this still so hard to control in 2019 - what the heck Google?!

None of the options on this page worked for me. I even tried changing the value to:

autoComplete="Chrome, stop autofilling. You don't know better than me. Why have you made this hard?"

This works for now, but I'm sure Google will make it needlessly hard again in a few weeks:

<input style={{ position: 'fixed', left: -1000 }} type="text" name="username" id="username" />
<input style={{ position: 'fixed', left: -1000 }} type="password" name="password" id="password" />

This unfortunately leaves these items in the tab progression, which is not great for accessibility, and demonstrates how Google's attempts to override my decisions as the app developer is counter productive. This should be a simple switch. I want it off.

@MonsterGameDev

This comment has been minimized.

Copy link

commented Jan 29, 2019

right now - to prevent both autofill and autocomplete i use autocomplete="off" in the form-tag and autocomplete="xpqrz" on every input then i wont suggest ANYTHING
(Chrome Version 71.0.3578.98)

@WuglyakBolgoink

This comment has been minimized.

Copy link

commented Feb 10, 2019

FYI: @MonsterGameDev

autocomplete="off" in the form-tag and autocomplete="xpqrz" on every input

Doesn't work on Version Chrome Version 71.0.3578.98 (Form was created in angular@7 App)

@dmausner

This comment has been minimized.

Copy link

commented Feb 13, 2019

Chrome 71.0.3578.127 (Official Build) (64-bit) under ChromeOS (using a ChromeBook client):
<input id=xxxxx autocomplete=none ...> (not linked to a form, no name attribute) WORKED -- no automatic suggestions.

Assume that "none" is equivalent to a random text value.

@dennisjnolan

This comment has been minimized.

Copy link

commented Feb 24, 2019

This situation is crazy. None of the hacks work for me on an iMac localhost app.
What is ridiculous is that a single text input field which is above a list of names and is used as input to filter the list blocks the first few names of the list as soon as it gets focus.
But text input fields in a dialog or modal dialog do not have this problem. So why do input tags behave differently in dialog tags to other tabs.
In my opinion this inconsistency is a bug.
Unfortunately I need modal dialogs and neither Safari nor Firefox have them yet. But they do not have that stupid suggestion box when clicking into the input field.
I noticed that it disappeared when I pressed the escape key. If it cheeses me off enough I will probably have to find a way to send an escape key event in an on focus event handler.
But shouldn't boolean attributes be disabled/off by default?

@HoldenCreative

This comment has been minimized.

Copy link

commented Mar 1, 2019

Why is this still so hard to control in 2019 - what the heck Google?!

None of the options on this page worked for me. I even tried changing the value to:

autoComplete="Chrome, stop autofilling. You don't know better than me. Why have you made this hard?"

This works for now, but I'm sure Google will make it needlessly hard again in a few weeks:

<input style={{ position: 'fixed', left: -1000 }} type="text" name="username" id="username" />
<input style={{ position: 'fixed', left: -1000 }} type="password" name="password" id="password" />

This unfortunately leaves these items in the tab progression, which is not great for accessibility, and demonstrates how Google's attempts to override my decisions as the app developer is counter productive. This should be a simple switch. I want it off.

Not sure if this hack is still valid, but you could modify the tabindex property for that specific issue. We've had no luck here though, Chrome seems dedicated to overwriting the prior methods of preventing autofill/autocomplete.

@prideptg

This comment has been minimized.

Copy link

commented Mar 5, 2019

As of right now, I'm having luck with autocomplete="!off">

Can't tell you why.

@tymothytym

This comment has been minimized.

Copy link

commented Mar 9, 2019

<form><input type="text" id="something" pattern="[ \S]+" autocomplete="off"></form>

Now works for me in Chrome 72.0.3626.121 having never worked previously.

I had been using <input type="text" id="something" pattern="[ \S]+" role="presentation" autocomplete="nope"> but that now doesn't work.

@sb2059

This comment has been minimized.

Copy link

commented Mar 12, 2019

We need an open-source, mainstream replacement for chrome that isn't vulnerable to massively expensive human error like this that can't be quickly resolved.

@yashanandan

This comment has been minimized.

Copy link

commented Mar 14, 2019

I am facing this issue recently but I noticed that if I remove my id there is not autocomplete. I am having an input box that is not under a form. Can anyone see if they are having the same experience ?
<input type="text" class="auto-sugg-text" id="autosuggest-head-txt" autocomplete="off">
doesn't seem to work but this does
<input type="text" class="auto-sugg-text" autocomplete="off">

@mhaava

This comment has been minimized.

Copy link

commented Mar 14, 2019

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

$(function() {
        setTimeout(function() {
            $('input[name="name"]').prop('readonly', false);
        }, 50);
    });
@stevenvachon

This comment has been minimized.

Copy link

commented Mar 19, 2019

As per @yashanandan's comment, removing the id solved the issue for me as well.

@kareha

This comment has been minimized.

Copy link

commented Mar 20, 2019

Add this at the first line after <form>
<input type="password" style="display:none;" readonly>

Browsers are looking for the first occurrence of a password type field, they fill that with the password and the field before that with username.
Nothing else helps. Even no timeout stuff and changing attributes.

@lyallb

This comment has been minimized.

Copy link

commented Mar 21, 2019

I am using chrome 73.03683.86
i set my username input field and password field in a form to autocomplete=''
and the console message about autocomplete went away
hope this helps

@eggerand13

This comment has been minimized.

Copy link

commented Mar 22, 2019

@kareha
That is actually a good idea as a workaround. Still pretty terrible that we have to hack this way.

@gregmousseau

This comment has been minimized.

Copy link

commented Mar 24, 2019

Currently, this seems to work (Chrome v73, FF v66):

$('form, input, select').attr('autocomplete', 'nope')

@gillytech

This comment has been minimized.

Copy link

commented Mar 25, 2019

In addition, autocomplete=off is also a nonsense as most browsers refuse to adhere to this - the best way is to make an element [readonly] and then on hover/click/blur/focus, remove [readonly]

@Westie Your suggestion about combination readonly and some JS has worked perfectly. Thanks for the tip!

@matheusioxi

This comment has been minimized.

Copy link

commented Mar 25, 2019

$('form, input, select').attr('autocomplete', 'nope')

Isto funcionou comigo no meu projeto em asp.net forms

@Crixin

This comment has been minimized.

Copy link

commented Apr 1, 2019

Use this, it's working for me!
<input autocomplete="nope" type="text">

@Jackiedk100

This comment has been minimized.

Copy link

commented Apr 2, 2019

Use this, it's working for me!
<input autocomplete="nope" type="text">

Not working here.. :(

@Crixin

This comment has been minimized.

Copy link

commented Apr 3, 2019

Use this, it's working for me!
<input autocomplete="nope" type="text">

Not working here.. :(

@Jackiedk100 What is your browser and version?

@singelone

This comment has been minimized.

Copy link

commented Apr 4, 2019

try to remove your id attribute.it's working for me

@derrickpeavy

This comment has been minimized.

Copy link

commented Apr 9, 2019

In Safari, nothing works. I've even renamed the fields to "fieldName&randomNumber" like so:
name="amount8764876234" value="myValue"
Doesn't matter. On initial reload, the old value is in the form field. I have to do a second reload or empty cache plus reload to see the correct values that were just submitted.

@derrickpeavy

This comment has been minimized.

Copy link

commented Apr 10, 2019

SOLUTION!

So, I see that some people are having luck with certain attributes, javascript, etc. But the problem is that the browser is caching the URL and the page content.

And, it's the URL that has proven to be the problem and the solution (at least for me).

For example, www.site.com/myFormPage.ext?var=value&var2=value2

At least as far as Safari was/is concerned, it appeared that as long as it could find the URL in history, it was going to fill in the form fields with the prior values come hell or high water.

I tried generating random numbers dynamically on the form (name="myField863598365") and that would change on each page load. The form processing evaluates the name and chops off the number, no problem. But Safari still cached the prior page content even with unique and always changing names.

autocomplete="pick any thing you want" - didn't matter.

javascript didn't make a difference

So, when editing data on a form that you are developing, if the URL can be retrieved from cache and still be valid, nothing worked. It appeared that Safari was looking only at the URL string, and the vars in the URL. So, www.site.com/myFormPage.ext?var=value&var2=value2 would always be cached - even if the values changed on submission, the prior values would be shown for that URL string with those vars.

Again, as an example, www.site.com/myFormPage.ext?var=value&var2=value2.... Load the form, change a value, submit the form - the old values show up on reload. You then have to force the cache to be emptied, or a second page load, only then would either option show the new form value.

Not acceptable. Users are going to be confused.

Here is what worked.

In the case of web development, you are sort of always "rolling your own solution." So, instead of using url vars and values (example: www.site.com/myFormPage.ext?var=value&var2=value2). I added a field to my database for a pseudo/fake link value which is randomly generated EVERY TIME the form is submitted.

I then use that value in my URL like so: www.site.com/myFormPage/896983642/

Or, it can also be just www.site.com/896983642/

Notice no file extensions or url vars!

The trick of course is how to process that. But again, you are already "rolling your own." So, in my framework, I scan the URL string and process the pseudo/fake directories with a combination of modRewrite and server side processing. This is not unlike what WordPress does with SEO friendly links.

In this case, the framework of the application looks up the /896983642/ section and matches it to a record that I am trying to edit, then loads the correct page, using the correct values in the session scope without passing them through the URL.

Because /896983642/ is unique and changes on EACH record update, the URL is always unique to the browser and so it can never retrieve those old form values from cache. And of course there are checks and safeguards in the framework to process the URL string and avoid nefarious injections.

So, bottom line apparently, the browser has to see a unique URL each time you load the form. And while it's a pain in the ass, it also creates it's own level of data protection in that no URL is ever reused.

I suspect that more browsers will gradually force caching of some level like Safari is doing. Not because Safari is all that and a cup of tea, but because it's a way to add speed and reduce bandwidth (or so some people think - because while it might reduce bandwidth by a few bytes, it's actually a problem for data integrity and user experience, leading to either a second page load (more bandwidth) or a support ticket).

So while Safari has removed it's "Disable Caches" option and perhaps other browsers have not (removed the equivalent), I wouldn't be surprised based on this thread and Google searches if this continues to be an issue in all browsers going forward. If so, then a unique and disposable URL is all you have left to fight with.

@kreba

This comment has been minimized.

Copy link

commented Apr 14, 2019

@kareha's suggestion to soak up the browser's autocomplete attempt with a hidden dummy field worked like a charm.

@PABretherton

This comment has been minimized.

Copy link

commented Apr 15, 2019

I just made an account so I could chime in. The answer is to use either a textarea or a div with contenteditable.

@LouisOfEidex

This comment has been minimized.

Copy link

commented Apr 15, 2019

I've been following this thread for the last month trying to fix a bug where chrome's autocomplete is over our bootstrap typeahead. I have a few partial solutions. The first I was able to implement was autocomplete="disabled" but it will only remove the autocomplete feature from filling out multiple input fields. Currently it will suggest an autocomplete for the current input but won't autofill other inputs.
Next, I tried to a css hack to remove the autocomplete which works only when you hover over the input then the autocomplete flashes away.

<style> {` input:-webkit-autofill { display:none; `} </style>

I'm no css wizard so any suggestions will help, Thanks.

@ilken

This comment has been minimized.

Copy link

commented Apr 15, 2019

Remove id and set autocomplete to off and it should work with the latest Chrome version.

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

@LouisOfEidex

This comment has been minimized.

Copy link

commented Apr 15, 2019

@ilken thank you for the feedback but I am on the lasted chrome version 73.0.3683.103 (Official Build) (64-bit), and latest version of React.
<input autocomplete="off" type="text"/> is still ignored and will autofill the whole form.
<input autocomplete="anyRandomString" type="text"/> will autofill the current input but not the whole form.

EDIT: Fixed, changed placeholder to a non location based name!!!

@MorevM

This comment has been minimized.

Copy link

commented Apr 16, 2019

$('form, input').each(function() {
$(this).attr('autocomplete', 'si_fuck_off_this_autocomplete');
});

Works good for me.

@xama

This comment has been minimized.

Copy link

commented Apr 18, 2019

So.. the ultimate solution of this heavy weight story is just to put any string you want as value of autovomplete ? strange but did the job !
<input type="x" name="y" autocomplete="whatever" />

@spartha1995

This comment has been minimized.

Copy link

commented Apr 23, 2019

These tricks no longer seem to work for chrome as well as in firefox

@derrickpeavy

This comment has been minimized.

Copy link

commented Apr 23, 2019

None of the "tricks" will ever work for very long. The browser wants to give you speed over accuracy so it will autocomplete as long as it thinks you are loading the same page. As long as the URL does not change, you will not solve this 100% of the time.

The only way to fix this is to load unique URL's each time for the same page. It's a pain, but it's quite easy to do if you are developing the form and data structure yourself already.

Take a look at the answer I posted earlier. Not only will it always load the correct data, but the link itself is safer because it is always unique. Forms don't need to be SEO'd, so that is not a problem.

@jhaidze

This comment has been minimized.

Copy link

commented Apr 24, 2019

A potential workaround that I'm currently using is to set 'autocomplete="disabled"'
and then to avoid the attribute value switch, add a script similar to

setTimeout(function(){ $('input').attr('autocomplete', 'disabled'); }, 400);

I'm not sure what the potential drawbacks are, but it's working for the moment.

@xeon826

This comment has been minimized.

Copy link

commented Apr 25, 2019

I did autocomplete="new-password" for a few inputs. I believe it only works for at most two on the same page which in my case wouldn't suffice for my search form that has many inputs so I just did

  $('input').on('focus', function(obj) { // disable autofill
    $('input').removeAttr('autocomplete');
    $(this).attr('autocomplete', 'new-password');
  })
@brandonbird

This comment has been minimized.

Copy link

commented May 16, 2019

@kareha 's solution looked like the best trick but Chrome seems to have started to check the css visibility of the input and so it didn't work for us. Inspired by that solution, instead of trying to make the decoy input invisible we just positioned it way off-screen.

<input type="password" name="password" style="position: absolute; right: -20000px">

This seems to be working... for now.

@shubhamcompro

This comment has been minimized.

Copy link

commented May 21, 2019

This is working fine.
<input type="password" autocomplete="new-password" name="password">

Refer https://stackoverflow.com/questions/15738259/disabling-chrome-autofill

@anish-techpro

This comment has been minimized.

Copy link

commented May 23, 2019

In addition, autocomplete=off is also a nonsense as most browsers refuse to adhere to this - the best way is to make an element [readonly] and then on hover/click/blur/focus, remove [readonly]

this works for me

@snowballrandom

This comment has been minimized.

Copy link

commented May 27, 2019

For me this seems to be doing the trick. Im sure this can be made to be a little more elegant ;)

  <form name="myForm" >
    <input name=r_email" type="text" readonly="true">
// Clear Form On Load
function clearForm(){
    document.registerForm.reset();
    
    var email = $('input[name="r_email"]');
    var password = $('input[name="r_password"]');
    
    email.val('');
    password.val('');
    
    email.attr('readonly', false);
    password.attr('readonly', false);
    
    
}
$(document).ready(function(){
    clearForm();
});

You may want to try to substitute:

$(document).ready()

With

$( window ).on( "load", function() { ... })

@hotelratepro

This comment has been minimized.

Copy link

commented May 27, 2019

As per @yashanandan's comment, removing the id solved the issue for me as well.

I tried everything before this (all variation of autocomplete="{something}" and this is the only one that worked, thanks!
(I'm using 74.0.3729.131)

@jsantillan7

This comment has been minimized.

Copy link

commented Jun 1, 2019

This small code worked fine for me on Chrome 74 :) Use CSS to avoid gray background for user's eyes:

<input type="email" id="txtCorreoE" readonly onfocus="this.removeAttribute('readonly')" style="background:#ffffff" />

@Jokero

This comment has been minimized.

Copy link

commented Jun 2, 2019

Combined solution of @kareha and @brandonbird with adding a special password field to a form works in Chrome (although does not work in Firefox):

<form>
    <input type="password" readonly style="position: absolute; right: -20000px">
@koutsenko

This comment has been minimized.

Copy link

commented Jun 5, 2019

When input has name such as "name", "company" etc, autocomplete is forced.
If input name is autogenerated, no suggestions showed.

@Jokero

This comment has been minimized.

Copy link

commented Jun 5, 2019

@koutsenko I guess this doesn't work with password fields

@mh-cbon

This comment has been minimized.

Copy link

commented Jun 18, 2019

...

@pimski

This comment has been minimized.

Copy link

commented Jun 20, 2019

None of the hacks/workarounds work anymore (on Chrome 75 / Windows 7). The only thing (hack) that seems to work is removing "id" and "name" attributes from the input elements. This feels wrong to me. I don't use id attributes, however, form fields without name attributes feels wrong. Even though I don't use them (I post my forms through ajax requests) I'd like my form fields to have matching names with the data I send to the server.
Driving me nuts this sjit!

@Jokero

This comment has been minimized.

Copy link

commented Jun 20, 2019

@pimski Solution that I've described above works in Chrome 75 on Mac OS

@iZamza

This comment has been minimized.

Copy link

commented Jun 24, 2019

Hi everybody!)
This work for me:
<input id="some-class" type='text' onclick="deleteInfo()" readonly>
and into script

function deleteInfo() {
                        $('#some-class').attr('readonly', false); //or getElementById ...
                    }

@mvr-devs

This comment has been minimized.

Copy link

commented Jun 24, 2019

The answer is to place meaningful data in the autocomplete attribute like so:

<input type="text" autocomplete="crm-phone-number" />

See the chrome developers response here:

https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164

@ZakariaF1

This comment has been minimized.

Copy link

commented Jun 25, 2019

The following html helper:
@Html.TextBox("loanAmount-input", "whatever", new { @class = "form-control", autocomplete = "off" })
it generates the following input:
<input autocomplete="off" class="form-control" id="loanAmount-input" name="loanAmount-input" type="text" value="whatever">
and its working
Chrome version : Version 75.0.3770.100 (Official Build) (64-bit)

@james11a

This comment has been minimized.

Copy link

commented Jun 26, 2019

My input (type="text") had a placeholder named 'IP Address'. This resulted in chrome providing suggestions with my personal addresses saved in the browser. As many suggested, autocomplete="any random string" in place of autocomplete="off" helped remove the address suggestions but weirdly the browser started suggesting email addresses now!

Ultimately what fixed the problem was providing a name attribute (which should also be a random string, definitely not name="address" or name="email") to the input field together with autocomplete="any random string".

So, hopefully something like below should fix your issue as well:

<input autocomplete="disabelAutocompleteHack" name="forAutocompleteHackToWork">
@marcelo-ribeiro

This comment has been minimized.

Copy link

commented Jun 27, 2019

Random name attribute

On focus:

<input type="text" id="name" onfocus="this.name = 'inputname_' + Date.now()">

Or in js window load:

document.querySelectorAll('[autocomplete="off"]').foreach( function(input) {
  input.name = input.name + '_' + Date.now();
});
@michauk

This comment has been minimized.

Copy link

commented Jun 28, 2019

The answer is to place meaningful data in the autocomplete attribute like so:

<input type="text" autocomplete="crm-phone-number" />

See the chrome developers response here:

https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164

MANY THANKS FOR THIS LINK. So stop fighting with "off" works or not "hack" works or not. You should do it another way to make it work EACH TIME.

Spoiler: as pointed out by some others, a random name is the best "hack". BUT. Let's apply it with the google recommandations.

So Google explains they don't consider autocomplete="off" anymore because everyone was using it everywhere with [potentially] no good reason. They want us to have autofilling where helpful/needed but they want the developpers to be able to guide Chrome to do it correctly.
So they tell you to use your specific way of writing an autocomplete attribute value, the name must have a semantic meaning. If the word you choose is new, autocomplete won't run. Like autocomplete="my-special-phonenumber-field". You're the only one to use this one, but we still know it's a phone number field.
The problem is, if the user comes back to fill this form again, my-special-phonenumber-field isn't a new thing anymore. Chrome autocompletes. In my case, it does it wrong and modifies some fields it should not. which is boring as people validate a form with modified values and they don't notice....

That's why people say autocomplete="off" WORKS. THE FIRST TIME. TRY AGAIN, it doesn't work. Eventually, if you already visited a website with some field containing ="off" it might just not work at all, even the first time

That's why people say autocomplete="my_super_hack" WORKS. THE FIRST TIME ONLY. Try again, it doesn't work.

That's why I say : generate it randomly each time, but with a semantic meaning, why not. Like autocomplete="phonenumber_". Avoid phonenumber123 or one day, someone will have used it too...

This finally corrected a bug I've been seeing for months in my web application and I just corrected it.

@MateusFGoncalves

This comment has been minimized.

Copy link

commented Jul 3, 2019

you can to use for inputs type password: <input id="password" type="password" autocomplete="new-password">
or you can to use jquery: $(function() { $('input[type="password"]').val(''); });
or: <input id="username" type="text" autocomplete="false"> or <input id="username" type="text" autocomplete="off">

@wplab

This comment has been minimized.

Copy link

commented Jul 3, 2019

just added to input "readonly" attrubute and it finally works

<input type="text" readonly />

@Madgeniusblink

This comment has been minimized.

Copy link

commented Jul 5, 2019

Wrong, false is not an option on autocomplete, all must be off

thank you!

@iZamza

This comment has been minimized.

Copy link

commented Jul 6, 2019

@LordMidi

This comment has been minimized.

Copy link

commented Jul 8, 2019

I can't get rid of autofill in Chrome - it seems to be on purpose
see the quote: https://stackoverflow.com/a/50621749/1337906

@michauk

This comment has been minimized.

Copy link

commented Jul 8, 2019

I can't get rid of autofill in Chrome - it seems to be on purpose
see the quote: https://stackoverflow.com/a/50621749/1337906

As already written here above, the autocomplete="off" is no longer considered by Chrome. The only way is to fill autocomplete with something NEW. If you use autocomplete="my-user-name-field-blah" it will work. ONE TIME. then if the user goes again on this form, chrome will remember that in the field with this autocomplete attribute, the usered enter a specific value and it'll autocomplete again.
So you have to generate a random autocomplete value EACH TIME. like autocomplete="my-login-form-ihjedfbng456" the last part being random.. See my previous messages.

@KhoaVanNguyen

This comment has been minimized.

Copy link

commented Jul 11, 2019

I remove the autocomplete="off" on the

tag and use the autocomplete="off" for input tag. This way works!

@langdonx

This comment has been minimized.

Copy link

commented Jul 11, 2019

@michauk Doesn't doing a random value every time pollute some cache in Chrome? The more you use whatever form is doing it, the more values Chrome knows about. Seems kinda gross.

@michauk

This comment has been minimized.

Copy link

commented Jul 11, 2019

@michauk Doesn't doing a random value every time pollute some cache in Chrome? The more you use whatever form is doing it, the more values Chrome knows about. Seems kinda gross.

Probably. Questions are : 1) will people come often on your form or not. 2) It's their choice to use this stupid browser which doesn't want you to disable autocomplete easily "in your interest" (I disagree). I wouldn't disable it if it didn't mess up with fields in a website of mine : It modifies quite silently some correct fields when at the end, autocomplete applies on a field it seems to recognize and then modifies a previous field and the user doesn't notice...
Hopefully it's a cache stuff somewhere, maybe automatically cleaned up from time to time. If not, I don't care.

@LordMidi

This comment has been minimized.

Copy link

commented Jul 11, 2019

I've implemented a simple spam detection (honeypot) with a hidden form field which should be left empty by human users. But because of autofill I had to name the hidden field with a senseless name. If I use names like "lastname" or "phone" autofill will use it even if it's hidden. So I hope a spam-bot will still fill out the field.
If all Browsers would support autocomplete="off" I could name the hidden field like "phone" and a bot will surely put some data into it. argh Using the autocomplete="off" on single inputs didn't work aswell... (in Chrome)

@michauk

This comment has been minimized.

Copy link

commented Jul 11, 2019

I've implemented a simple spam detection (honeypot) with a hidden form field which should be left empty by human users. But because of autofill I had to name the hidden field with a senseless name. If I use names like "lastname" or "phone" autofill will use it even if it's hidden. So I hope a spam-bot will still fill out the field.
If all Browsers would support autocomplete="off" I could name the hidden field like "phone" and a bot will surely put some data into it. argh Using the autocomplete="off" on single inputs didn't work aswell... (in Chrome)

yes, common way to detect a bot. You even can use 2 fields. With stupid autocomplete names, autocomplete won't occur ever, so no pb

@derrickpeavy

This comment has been minimized.

Copy link

commented Jul 11, 2019

As michauk commented above, there is a right way to do this. It looks like most people on this thread are not reading the whole thing and simply sharing their latest "hack" which only works for a few seconds.

Or, as I have explained above (see https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-2885166) there is an even better and valid solution which is browser independent, and works regardless of future updates.

That I am working on involves financial data. Nothing too important, just purchase amounts. But they have to be correct every time or things go way wrong.

All browsers now do a deep dive on your cache and do everything they can to bring old data back to life.

They do this by checking the URL and then the names of the fields.

Maybe not everyone can do this because you might not be building your own solution, but simply working with php or html and not permitted to structure a table in a database.

But if you can, the solution is to create a UNIQUE URL EVERY TIME the page loads. And it can't just be URL vars. The actual URL has to be unique.

I create a link that is a combination of unix time and random numbers. That data is stored in a table which also stores the specific template that needs to be called. (recordID, uniqueURL, templateName) (1, 097867654645767, myCardForm.php)

The url then becomes: https://www.mySite.com/097867654645767

And every time the form data is updated, a new string is generated.

Using mod_rewrite and a database lookup you can easily determine which template to load.

This stops the caching dead in its tracks. And then your form can have normal, simple, standard names and values. It works in every browser.

@jinguohao1991

This comment has been minimized.

Copy link

commented Jul 11, 2019

You can do this.
$(document).ready(function () {
$("input[autocomplete='off']").attr('readonly', true).on('focus', function () {
$(this).removeAttr('readonly')
});
});

And in your .css file:
input[autocomplete='off']:read-only {
background-color: transparent!important;
}
This will work perfectly in all browsers as long as it supports javascript,:)

@langdonx

This comment has been minimized.

Copy link

commented Jul 11, 2019

@derrickpeavy your solution (using a unique URL) doesn't work in Chrome.

I have a user admin UI and when I modify my own user (the path is /users/client-portal/142), it tries to auto-complete the form (the username field is blue and it fills in the password in the "Change Password" field, which is not desired.

So in assuming what you were saying was valid, I deleted my user and recreated it (new path is /users/client-portal/181) and it still turned the field blue.

It's interesting to note that when editing other users, Chrome doesn't think it can auto-fill the "Change Password" field, assume, because the username is not one that it knows it has a password for...

@derrickpeavy

This comment has been minimized.

Copy link

commented Jul 11, 2019

So, it's always frustrating to share a situation like this in a forum because I can't see your screen, you can't see mine. So we may both be seeing the same or different things.

I am testing on Chrome (latest) on OS X and it works!

But let me put it this way...

If you have two URL's such as:
/users/client-portal/142
/users/client-portal/181

And even if the form structure (fields) are the same on both, if ANY browser fills in the data from one form (141) in the other one (181), then there is something seriously wrong with the browser, so wrong that it can't be possible.

The URL /users/client-portal/142 is seen by the server as 3 distinct directories. And /users/client-portal/181 is also three distinct directories. Wether these actually exist on the server or are "pseudo" or fake links that mod_rewrite interprets and passes to you, the thing is, the browser simply cannot assume they are the same.

I should point out that in the process I describe above, the back end application server is checking for the correct data from the database and making sure that data is presented to the template.

However, if the underlying code and server assume the following:

/users/client-portal/142 where 142 is a non existent item in the directory of "client-portal" then the server should default to an index in "client-portal" that being the case, if that default index is the same for both 142 and 181 (as it would be in this scenario I am laying out in this paragraph), then yes, the browser would pull from cache.

What I am describing is allow mod_rewrite or whatever extension your server uses, to take a string such as /987564564/ and to pass that string as a value to your application server which then looks up the value in a database. That value indicates what template should load and what key variables go with it. It's very much like what you would see in WordPress with "nice" URL's which actually look up a template, not the actual file name.

If you do that, the URL is unique every time and the browser, by its very design will not fill in that data.

@langdonx

This comment has been minimized.

Copy link

commented Jul 11, 2019

And even if the form structure (fields) are the same on both, if ANY browser fills in the data from one form (141) in the other one (181), then there is something seriously wrong with the browser, so wrong that it can't be possible.

I can't say I agree here. Chrome is intending to provide you with your username and password that you asked it to save ANYWHERE on the web site you saved it. The password manager associates passwords to entire domains, not to unique URLs.

Perhaps we're talking about two different things here... password-auto-fill versus address/phone/cc auto-fill.

@derrickpeavy

This comment has been minimized.

Copy link

commented Jul 11, 2019

OK, in that case, yes we are talking two different things. Apologies if I muddied the water, but I recall this years long thread being about data integrity in a form, as much as about user name and password in a form.

My focus in my work is to make sure that when a user loads a form to edit an expense, and then the same template and process to edit a different expense, that they get the right data. Most browsers (and especially Safari) are bad about caching the data and reusing it, which you can only clear with a forced reload of the browser. And you can't expect users to actually do that. So what I describe ensures that the correct data is loaded each time.

As for the user name and password if the user told the browser to save it... My question (to whomever) is, why is this a problem? If the USER ASKED a browser to save user name and password and you as a developer are trying to override that, there is a lot wrong there. I understand a business case where you may want to enforce security, but you can't assume that it's acceptable to override a choice like that. And ultimately, you can't. The developer would be trying to negate a choice which the user made and a key browser function, and would always be trying to catch up with updates and user preferences. Not to mention that it's actually less secure because the user is likely to simply write down the password somewhere to make their life easier. That is going to put everything at risk.

Digress. Rant. End.

@mh-cbon

This comment has been minimized.

Copy link

commented Jul 11, 2019

anyways, painfully bloated. too bad for security i guess.

@langdonx

This comment has been minimized.

Copy link

commented Jul 12, 2019

My question (to whomever) is, why is this a problem? If the USER ASKED a browser to save user name and password and you as a developer are trying to override that, there is a lot wrong there.

I want the username/password to be saved and auto-filled on the login screen, of course.

However, when I'm making changes to my profile, which has a "Change Password" field on it, I don't want it filed in by default, because I also have a "Confirm New Password" field that doesn't get auto-filled. So the user ends up having to clear out the password box to update their profile, or re-type their password in the confirm field.

It's forcing me to have bad UX that I can't control. There are of course ways around it -- redesign the screen so that change password is on a separate screen or use the readonly+onfocus hack -- but I shouldn't have to go to these great lengths.

@derrickpeavy

This comment has been minimized.

Copy link

commented Jul 12, 2019

No good options I suppose. I think mobile apps and mobile design have trained people to look for a simpler screen. And things like changing a password get moved to a screen by itself. Maybe not most efficient, but it does solve this problem, no? On the app I am currently working on, I made the change password flow simple and deliberate - not saying you should or that it's best, just that it works best for the users who I am working with - wide range of ages and skills. So, they click a link to reset the password. The next screen asks if they are sure? If so, the password is blanked out and a link is emailed to set a new password. When they click that, the link is validated, then they type the password once. When that form is submitted, then they type the password again to log in as the "second" confirmation. Again, every case is going to be different and you might not be able to change that in your flow.

If you do find a solution, please post, because while the way I am ensuring form data integrity is working and is a valid approach, won't be affected by updates, etc., it would be nice to NOT have to do it.!!

@dslawrence

This comment has been minimized.

Copy link

commented Jul 12, 2019

Here's a good way to do it using jquery, this is working well for me:

  1. disable all text input fields (this prevents them from auto-filling)
  2. add some javascript to re-enable them on click

Pros:

  1. No autofill!

Cons:

  1. Doesn't allow tabbing between form inputs

I have a div of class "form-group" around each of my inputs. Its helpful to have some standard class around each input to facilitate the click above the level of the input field.

To disable & re-enable I:

// have a query that finds all of your inputs and disables them
$('input[type="text"]').attr('disabled', 'disabled');

// when someone clicks on the form-group that contains the disabled input, enable the input and focus it
$('.form-group').on('click', function(e) {
var $input = $(e.currentTarget).find('input');
$input.removeAttr('disabled');
$input.focus();
});

@derrickpeavy

This comment has been minimized.

Copy link

commented Jul 12, 2019

Pretty crazy what we've all come up with to solve this, or variants of this. I personally don't like the intense caching that browsers do now. I understand why, but I don't like it. Would be nice if there were a standard HTML 5 tag which could indicate no-caching of a particular form or file. You know, something that all browsers would honor? I dunno, like a no cache tag?

Except that it would actually work.

@davewallace

This comment has been minimized.

Copy link

commented Jul 14, 2019

Well I think you have a good point with the URL caching @derrickpeavy - it's not a solution I can roll with, but I found that when I experimented with your technique it worked for me. And it would work around changes based on attributes that come and go at the whim of Google engineers.

I am absolutely dumbfounded at how many people have hit this. Imagine the time, money and ability to go on that has suffered because of this.

In my use case, I am dynamically switching between an <input type="text" /> and <input type="password" /> as I want to present only a single input box to the end user - they use this single box for all text input in fact. Simple text input is the only thing allowed in my scenario - the only exception to 'simple' is that at certain times they need to put in their password. My first attempt was to just dynamically switch the attribute on a single <input /> from type="text" to type="password", that's when I fell into this rabbit-hole.

I'm also finding that the Chrome password manager is actually showing up on type="text" under certain scenarios where it definitely shouldn't be.

I've tried all of the hacks above, apart from textarea/contenteditable as @PABretherton generously created an account just to suggest as an alternative.

I agree with the UX pattern Chromium is enforcing, in most use cases it would be best practice - BUT NOT ALL USE CASES. We're not all stupid, Chromium.

I've spent 6 hours researching and experimenting with A TEXT INPUT FIELD. I have a great deal of actual functionality to write, but no... TEXT INPUT FIELD CAN HAZ CHEESEBURGER.

My rant also over.

@davewallace

This comment has been minimized.

Copy link

commented Jul 14, 2019

Just another thought, maybe if we all remove the safeguard of type="password" altogether and just use type="text" with an emoji or Wingdings font, then the Chromium team will need to re-evaluate their approach to ensure we're all behaving as they expect.

@MuhammadRaheelFayyaz

This comment has been minimized.

Copy link

commented Jul 16, 2019

i also facing this issuse is there is any way to romve page localstoage

@muhammedsafeer

This comment has been minimized.

Copy link

commented Jul 20, 2019

I just tried <input type="text" autocomplete="new-username" .... > <input type="password" autocomplete="new-password" ...>, now it works fine for me - Google Chrome Version 75.0.3770.142
got it from https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-2260555

@motsmanish

This comment has been minimized.

Copy link

commented Jul 20, 2019

I just tried <input type="text" autocomplete="new-username" .... > <input type="password" autocomplete="new-password" ...>, now it works fine for me - Google Chrome Version 75.0.3770.142
got it from https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-2260555

Working 👍

@RizziWilliam

This comment has been minimized.

Copy link

commented Jul 23, 2019

With React.js you can make the input start with ReadOnly and on componentDidMount you simple remove the attribute from it using a delay (setTimeOut). This away google can't put data on the input.

@derrickpeavy

This comment has been minimized.

Copy link

commented Jul 24, 2019

Though my approach is off topic as has been pointed out, my issue is not with the password, but with cached financial data. Especially Chrome is nasty about using the cache.

A little validation to my approach:
https://stackoverflow.com/questions/54295688/turning-off-cache-on-my-apache-web-server-so-html-files-are-live:

Caching is done by the browser, not by the server. Options are: Assign a unique query string to every URL to force a new request, or use JavaScript to dynamically load the content that changes.
EDIT
You can also add a Cache-Control: no-cache header to your response.

I've also since double checked my server config to expire data. We'll see.

@DiomedesDominguez

This comment has been minimized.

Copy link

commented Jul 24, 2019

I just tried <input type="text" autocomplete="new-username" .... > <input type="password" autocomplete="new-password" ...>, now it works fine for me - Google Chrome Version 75.0.3770.142
got it from https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-2260555

This worked for me in Firefox 68.0.1 on Windows 10 x64

@arkytn

This comment has been minimized.

Copy link

commented Aug 1, 2019

If you really want to disable the pop-up list, the duplicate field trick works well. The latest Chrome puts up it's select list for everything except disabled. I found this little plugin that does this for you

https://github.com/biesbjerg/jquery.disable-autofill

It creates a clone of the field, inserts it in front of the original field and hides it.

I did make one mod to this for field names of the form "aFieldName[]" for php arrays. I set the clones name to a blank string "" so it doesn't show up in the array.

  Plugin.prototype.initialize = function() {
    var $element = $(this.element);
    $element
    .val($element.attr('value'))
    .clone()
    .removeAttr('id class required')

    .attr('name', '') //so clone doesn't submit. <--Added

    .insertBefore(this.element)
    .hide();
  };
@albinjoseph1994

This comment has been minimized.

Copy link

commented Aug 2, 2019

autocomplete="nope" is working for me on chrome (Version 75.0.3770.142)

@Fahad36

This comment has been minimized.

Copy link

commented Aug 5, 2019

@Fellach The link you posted states that they do not support autocomplete="off" for login fields, all other input fields should be fine.

many modern browsers do not support autocomplete="off" for login fields

It also says you should use autocomplete="new-password" for new password fields (can be used in login fields) in order for it to not be auto filled.

If an author would like to prevent the autofilling of password fields in user management pages where a user can specify a new password for someone other than themself, autocomplete="new-password" should be specified, though support for this has not been implemented in all browsers yet.

Thanks it was really workfull

@ian-holden

This comment has been minimized.

Copy link

commented Aug 7, 2019

What worked best for me was:
<input type="text" ... readonly onfocus="this.removeAttribute('readonly')" onblur="this.setAttribute('readonly', '')" />
This works after returning to the field again, and using tab or mouse to navigate around.

@tmthn

This comment has been minimized.

Copy link

commented Aug 8, 2019

We managed to solve this issue with a little bit of javascript. It looks like that if you remove the name attribute on the given input, Chrome (76.0.3809.100) will disable the autocomplete feature as expected. The script replaces the name attribute with a blank string and saves it as a data attribute. When the form gets submitted all name attributes will be replaced with their previous value.

function disableAutocomplete() {
  var nameSelector;
  nameSelector = "data-name";
  return document.querySelectorAll("form").forEach(function(form) {
    if (form.getAttribute("autocomplete") === "off") {
      form.querySelectorAll("input").forEach(function(input) {
        input.setAttribute(nameSelector, input.name);
        return input.name = "";
      });
      return form.addEventListener("submit", function() {
        return form.querySelectorAll("input").forEach(function(input) {
          return input.name = input.getAttribute(nameSelector);
        });
      });
    }
  });
};
@Westie

This comment has been minimized.

Copy link

commented Aug 15, 2019

So my friend reminded me of this gist

The best way now is to use <input type="search" />

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search

@MaceWindu

This comment has been minimized.

Copy link

commented Aug 15, 2019

Was addressing this issue recently in our app, so want to share what helped us. After trying some autocomplete=something fixes, I've decided to not waste my time and check chrome autofill code.
Discovered that some google code-monkey decided that autocomplete values should be ignored for form-less inputs and just fill first input with saved form data, which usually be login name from saved credentials (it called it "heuristics" 🤦‍♂ ).

So our fix was to wrap markup, containing inputs info plain attribute-less <form></form> tags to make autocomplete=nothanks respected.

@hamzash750

This comment has been minimized.

Copy link

commented Aug 19, 2019

Just use this tag

and not give the input id please remove the input id and aslo name

@Abdoulrasheed

This comment has been minimized.

Copy link

commented Aug 21, 2019

A jQuery plugin can solve this problem for all browsers.
https://github.com/terrylinooo/jquery.disableAutoFill

Spend an hour looking for solution, finally this works

@ardok

This comment has been minimized.

Copy link

commented Aug 21, 2019

image

Just wanna make sure, we're all talking about disabling that black dropdown auto suggestion thing, right?
I'm struggling to disable it too.


Never mind, autocomplete off seems to do the trick.
Looks like my problem is with "suggestion", not "autofill".

@guzmanoj

This comment has been minimized.

Copy link

commented Aug 21, 2019

  1. Make sure that the <form> has the autocomplete="off" attribute
  2. Set a random name attribute to the input and also the autocomplete="off" to the input.
    You'll get something like this:
<form autocomplete="off">
<inpute type="text" autocomplete="off" name="lastname_74758209201093747">
</form>

With this approach we trick the autofill feature of the browser 😄

@biechao

This comment has been minimized.

Copy link

commented Aug 28, 2019

I just tried <input type="text" autocomplete="new-username" .... > <input type="password" autocomplete="new-password" ...>, now it works fine for me - Google Chrome Version 75.0.3770.142
got it from https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-2260555

This worked for me in Firefox 68.0.1 on Windows 10 x64

Amazing!😄

@MathiasBerwig

This comment has been minimized.

Copy link

commented Sep 3, 2019

Commenting here for the next time I visit this gist hoping to solve the problem:
With react.js a simple autoComplete="off" must do it (I forgot the capital C soooo many times).

(On Chrome 76.0.3809.132)

@WooMai

This comment has been minimized.

Copy link

commented Sep 5, 2019

autocomplete="new-password" worked for me.
Chrome/76.0.3809.100

@gabrielzevedo

This comment has been minimized.

Copy link

commented Sep 11, 2019

Following this tutorial: https://developers.google.com/web/fundamentals/design-and-ux/input/forms/#recommended_input_name_and_autocomplete_attribute_values, I was able to specify autocomplete for each field of my form

@KenQQQ

This comment has been minimized.

Copy link

commented Sep 18, 2019

First I tried with autocomplete="new-field" but it didn't work.

Then I tried it in FF. Where only two fields got the stupid autocomplete. One type="password" field and the field above that field. FF acted as it was username and password fields.

So I change the type to "text" for the password field and it worked in FF!

In Chrome I needed to combine the type-fix with the autocomplete="new-field" fix in order to get it to work.

BOOM!

@ScottWindon

This comment has been minimized.

Copy link

commented Sep 21, 2019

This is gonna sound so random but this works for me.
After trying every different combination of autocomplete="off", autocomplete="off_randomstring", autocomplete="new-password", and so on. And even trying the hidden login fields etc. I still couldn't get it to work.
And then I stumbled across something! Randomly all my fields work with autocomplete="off_randomstring" BUT only after I added address fields to my form. I have no idea why this worked but it did. After going through it bit by bit the simplest method is this:
Add this to your form <input id="_suburb" type="text" style="display:none;" disabled> and then add autocomplete="off_randomstring" to the fields you want to prevent from autocomplete.

@iammai

This comment has been minimized.

Copy link

commented Sep 24, 2019

I used autocomplete="new-password" as specified in this article and this fixed the problem for my form: https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

@sonichandni

This comment has been minimized.

Copy link

commented Sep 25, 2019

This incredibly works for me:
<input readonly onfocus="this.removeAttribute('readonly');" type="text" id="searchTextbook" placeholder="Search Books" value="">

@toeurtenh

This comment has been minimized.

Copy link

commented Oct 1, 2019

autocomplete="off" is in both input and form works for me

@TonyC5

This comment has been minimized.

Copy link

commented Oct 3, 2019

@sonichandni, @ian-holden - this seems like a clever solution, but setting the "readonly" attribute prevents some mobile browsers from displaying the soft keyboard (even though the script removes the "readonly" attribute on focus).

Also, my forms have autocomplete="off" in the inputs and the form and that is not working reliably on mobile Chrome.

@shruti19

This comment has been minimized.

Copy link

commented Oct 17, 2019

https://makandracards.com/makandra/24933-chrome-34+-firefox-38+-ie11+-ignore-autocomplete-off

Chrome and Firefox now allow to mark password fields with an attribute autocomplete="new-password". This will prevent the field to be filled in automatically.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.