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

Asked 2023-09-20 20:19:33 View 879,338

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

  • 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...' - anyone
  • Try github.com/terrylinooo/disableautofill.js , it uses JavaScript the skip the auto-fill function from browser. - anyone
  • This question is being discussed on meta. - anyone
  • <input name="otp"> is your life saviour in 2022. (Browsers won't provide suggestions for one time passwords. - anyone
  • thousand answers. Just simply add a hidden email & password field and make them auto complete, this way the browser is happy to fill out something, and it won't affect your user experience. - anyone

Answers

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" />

Answered   2023-09-20 20:19:33

  • 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. - anyone
  • Autocomplete is only defined in the HTML 5 standards, so it will break any validations you run against HTML 4.*... - anyone
  • @Winston, you should put it both on the form, AND on the input element itself. That way you cover all the nonstandardness of browsers. - anyone
  • And remember to disable your autocomplete = on extension (if you're using Chrome) before you test your webapp. Else you'll feel real silly like me. ;) - anyone
  • Surprised, why this answer is accepted and having so much votes. Even there is nothing special as said others. As per my findings most specific and proved solution has provided by @Ben Combee in this thread. - anyone

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.

Answered   2023-09-20 20:19:33

  • 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)); - anyone
  • 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". - anyone
  • 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. - anyone
  • 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? - anyone
  • @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 - anyone

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.

Answered   2023-09-20 20:19:33

  • what do you mean with "adding this on your page seems to disable autofill for the page:" - anyone
  • @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. - anyone
  • 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. - anyone
  • Hello from 2022. I've just tried this solution andd it still works on Firefox 101.0.1 but not on Chrome 102.0.5005.115 - anyone

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.

Answered   2023-09-20 20:19:33

  • An if there is no javascript then the whole form fails. -1 - anyone
  • @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). - anyone
  • @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. - anyone
  • 13 years later, this is still the best option - for those of us using JQuery, here's a quick modification: onfocus="$(this).attr('readonly',false);" - anyone
  • This is not solution. If JS not works in page, yes it fails. And also, you did a mouse event but many users don't use mouse when they enter inputs. - anyone

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.

Answered   2023-09-20 20:19:33

  • This works in Chrome for other types of fields as well, not just type="password". - anyone
  • I used it with password, email and text types and it worked. I used it simply like this: autocomplete="new" - anyone
  • autocomplete="nope" name="pswd" and used <input name="dummyPassword" type="password" style="display:none;"> before the real password input field. This worked for me. - anyone
  • This works in almost all browsers now, not just Chrome: autocomplete#Browser_compatibility. - anyone
  • This is the best answer as of now. See the end of this page for more infomation: developer.mozilla.org/en-US/docs/Web/Security/… - anyone
<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.

Answered   2023-09-20 20:19:33

  • 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. - anyone
  • 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. - anyone
  • Sadly, as of IE 11, Microsoft no longer respects this for input type="password". Hopefully no other browsers choose to remove this functionality. - anyone
  • Setting autocomplete="off" on the form is the only thing that worked for Chrome. - anyone

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.

Answered   2023-09-20 20:19:33

  • 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. - anyone
  • 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. - anyone

Always working solution

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.

Update 2022:

Chrome made this improvement: autocomplete="new-password" which will solve it but I am not sure, if Chrome change it again to different functionality after some time.

Answered   2023-09-20 20:19:33

  • This works even better. You can add a small JS that generates a random code for every page load, and add that code to the input field: <code> function autoId(){ var autoId = ""; var dict = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; for(var i=0; i<12; i++){ autoId += dict.charAt(Math.floor(Math.random() * dict.length)); } return autoId; } $('.autocompleteoff').attr('autocomplete', autoId());</code> You can add the autocompleteoff class to your desired input field. - anyone
  • Chrome has been fixed to use the standardized "off" now - anyone
  • Sadly it works better than what is called standard on chrome - anyone
  • 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. - anyone
  • autocomplete="off" works for firefox in 2022 - anyone

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.

Answered   2023-09-20 20:19:33

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

Three options:

First:

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

Second:

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

Third (JavaScript code):

$('input').attr('autocomplete', 'off');

Answered   2023-09-20 20:19:33

  • The first and second options should be one option, since it varies on how browsers handle this. - anyone
  • Tried $formElement.attr('autocomplete', 'off'); and it does not work. - anyone

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');" >

Answered   2023-09-20 20:19:33

  • 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. - anyone
  • 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(); }); - anyone
  • @Andrew Sure, you can. This is the core principle to overwhelm this issue and I also added an update containing full code example ;) - anyone
  • I've also added onfocusout="this.setAttribute('readonly', 'readonly');" - anyone

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

Answered   2023-09-20 20:19:33

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!"

Answered   2023-09-20 20:19:33

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

Answered   2023-09-20 20:19:33

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>

Answered   2023-09-20 20:19:33

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!

Answered   2023-09-20 20:19:33

  • As you said in chrome, the off value doesn't work. It needs to be "false" - anyone
  • Works for me on Chrome 44.0.2403.130. - anyone
  • Tried this: $formElement.attr('autocomplete', 'false'); sorry does not work. - anyone

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.

Answered   2023-09-20 20:19:33

  • 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? - anyone

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.

Answered   2023-09-20 20:19:33

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

Answered   2023-09-20 20:19:33

  • I found this to work in my preliminary testing. So odd that "off" doesn't work. - anyone
  • 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. - anyone
  • @tebs1200 Which one? The password field or the text field? - anyone
  • @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. - anyone

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.

Answered   2023-09-20 20:19:33

  • The problem with this is if any other sites use "name_" to achieve the same objective then you're back to square one. - anyone
  • so make it "mysite_name". If anyone else is using that, I'd ask them questions... - anyone
  • this messes up some of those automatic populating utilities - anyone

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.

Answered   2023-09-20 20:19:33

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

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"

Answered   2023-09-20 20:19:33

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

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

Answered   2023-09-20 20:19:33

So here is it:

function turnOnPasswordStyle() {
  $('#inputpassword').attr('type', "password");
}
<input oninput="turnOnPasswordStyle()" id="inputpassword" type="text">

Answered   2023-09-20 20:19:33

  • Looks like good idea if style text boxes to prevent flash of visible password. - anyone
  • Thanks so much, this did the job +1, my variation to your solution was to make it by single line: <input oninput="this.type='password'" id="inputpassword" type="text"> - anyone
  • @HasnaaIbraheem Thanks (: sometimes more readable is better . - anyone
  • This is the only way I could get it to work - readonly attr worked but messed up the tab order. - anyone
  • An explanation would be in order. E.g., what is the idea/gist? What was it tested on (incl. versions)? - anyone

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.

Answered   2023-09-20 20:19:33

  • this doesn't avoid invalid xhtml, it simply adds the invalid bit dynamically after you have checked it it declared it to be valid! - anyone
  • @Andiih: So is there a way to make autocomplete work in xhtml? - anyone
  • Work (or stop it working which is the goal): yes as above. But valid - no. - anyone

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.

Answered   2023-09-20 20:19:33

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

autocorrect="off" autocapitalize="off" autocomplete="off"

Answered   2023-09-20 20:19:33

  • autoComplete for React... $0.02 - anyone

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>

Answered   2023-09-20 20:19:33

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

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>

Answered   2023-09-20 20:19:33

  • 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. - anyone

Things had changed now as I tried it myself old answers no longer work.

Implementation that I'm sure it will work. I test this in Chrome, Edge and Firefox and it does do the trick. You may also try this and tell us your experience.

set the autocomplete attribute of the password input element to "new-password"

<form autocomplete="off">
....other element
<input type="password" autocomplete="new-password"/>
</form>

This is according to MDN

If you are defining a user management page where a user can specify a new password for another person, and therefore you want to prevent autofilling of password fields, you can use autocomplete="new-password"

This is a hint, which browsers are not required to comply with. However modern browsers have stopped autofilling <input> elements with autocomplete="new-password" for this very reason.

Answered   2023-09-20 20:19:33

  • only this solution is working from entire internet - anyone