Chrome/Firefox autocomplete=new-password not working - html

I'm trying to add autocomplete=new-password to some user-editing forms, but it fails to follow the correct behavior in Chrome 79 and Firefox 71. It's supposed to be supported in both browsers.
What's wrong here?
I created two very simple examples to remove any external interference to the issue. They can be served from any HTTP server (e.g. php -S localhost:8999). The first page triggers the "save login" feature, but the second should NOT use that info to autocomplete the password - yet, it does.
<!-- login.htm -->
<html>
<head></head>
<body>
<form action="edit.htm" method="post">
<label>Login <input type="text" name="login" /></label></br>
<label>Password <input type="password" name="pwd" /></label><br />
<input type="submit">
</form>
</body>
</html>
<head></head>
<body>
<form>
<label>Login <input type="text" name="login" /></label></br>
<label>New Password <input type="password" name="pwd" autocomplete="new-password" /></label><br />
<input type="submit">
</form>
</body>
</html>
This is not exactly a dup from "how to use autocomplete=new-password" as the behavior seems to have changed or is ill-documented.


This seems to be an issue/advantage that browsers force pages to behave this way, and absolutely this is not fixed when setting autocomplete="new-password" or even if you set the value to off. but there seems to be a workaround to fix this issue caused accidentally by the browser.
- HTML way:
You can fix this by adding hidden fields at the top of your form to distract the browser
<!-- fake fields are a workaround for chrome/opera autofill getting the wrong fields -->
<input id="username" style="display:none" type="text" name="fakeusernameremembered">
<input id="password" style="display:none" type="password" name="fakepasswordremembered">
- JS way:
you can just set the password input to readonly the change its state
<html>
<head></head>
<body>
<form>
<label>Login <input type="text" name="login"/></label></br>
<label>New Password <input type="password" id="password" name="pwd" readonly autocomplete="new-password"/></label><br/>
<input type="submit">
</form>
<script>
document.getElementById('password').onfocus = function() {
document.getElementById('password').removeAttribute('readonly');
};
</script>
</html>


As you didn't reply to my comments I suppose that my assumption was correct. So I'll post the comments as the answer:
I don't have Chrome 79 and Firefox 71. I've tested it on Chrome 85 and FF 80 on Ubuntu.
It works as intended.
I assume that by
should NOT use that info to autocomplete the password - yet, it does.
you mean that:
When the password field gets focus browsers show a drop-down list with an option to fill in the field with previously stored password.
This looks to you as
[browsers] should NOT use that info to autocomplete the password.
[...] the behavior seems to have changed or is ill-documented.
But actually this is exactly the intended behavior.
From this (the previous paragraph on the same page you've linked) you can see the reason:
Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise.
For this reason, many modern browsers do not support autocomplete="off" for login fields
If a site sets autocomplete="off" for username and password fields, then the browser still offers to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
Of course, it's about autocomplete="off" not about autocomplete="new-password"
Let's read further
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.
From this:
autofilling is not the same thing as suggestions
browser CAN, but not SHOULD prevent autofilling
autocomplete="new-password" prevents autofilling not suggestions
So when you set autocomplete="new-password" browsers stop filling these fields but continue to show drop-downs with suggestions.
There is nothing about autocomplete="new-password" stopping suggestions, and there is a clear reason why suggestions are always available.
Yes, maybe the wording is a little bit confusing, but follows the behavior to the word.
About the history and use-cases behind this feature you can read here
And now about use-cases... why do you need this?
If several users have access to the computer, disabling suggestions won't stop them from logging in to a site as a different user. They can see passwords in the settings and use them. To prevent this, users must have different accounts on the computer.
If you don't want them to use old password in place of a new-password, then, yes, it will complicate things a little (which is actually bad - when things are complicated users tend to use poor passwords), but won't stop them from remembering the old password or, again, from getting it from the settings. For that you need to check if the password is really new in your code.
If you want to prevent suggestions anyway, then you can use hacks from #Moayad.AlMoghrabi's answer (I haven't tested them, but I believe he did). But without knowing your use case, I would strongly recommend against it. It breaks user experience and does not boost security. On the contrary, lessens it.


I know what your talking about, and in your case you should leave it. Security is a major issue, obviously, and the answers above are absolutely correct. There are work-arounds though, like using read-only which has been mentioned, I would try to achieve your goal using read-only, however; read-only does not always give disired results. A less favorable, and I feel like someone is going to lecture me hard for answering with this, but I feel as a developer, you need all the information, what you do with that information is your decision.
PSEUDO ELEMENTS
Googles chrome and Safari, imho, are the most annoying when it comes to auto-fill. To get around this, one option is to create HTML pseudo elements for the pwd and login inputs. Hide them using CSS display property set to none. Since google will only auto-fill one password-input element, and one username text-input element, this work around tricks Google into auto-filling elements that are not displayed.
The Problem With This Method
The problem with this method is that you need to make sure that you validate the data on the backend, and even more so, you need to make-sure your using the right elements to pull data from for your database. The worst problem is that as things update this work-around will guaranteed, at some-point, either stop working and the elements will one-day show without you knowing, making not developers using your site very confused, or confuse the browser in ways we cannot predict because the changes have not come. Its somthing you always have to be aware of. I use to use this method alot, but I stopped because people who know a lot more than I do, really did not like me doing it.
End Note:
Every browser is programed to present forms differently. Some browsers, especially mobile versions and safari actually change the physical look of your elements, which IMO is uncalled for. At the same time though they do this to try and deliver web standards to boost security and make things easier to use for people like my non tech-savvy 85 year-old Grandma. As noted, browser do things differently, and people can choose different browsers, selecting the one they want. Auto-fill is part of the experience that users get from a browser, and is a major deciding factor on which browser people choose. If you use work around, like the one I explained you change that browser experience, and give the user what you want, but it might not be what they want.
If you do decide to use, or at-least try this method, please let me know how it goes, its a pretty easy hack/work-around, and I have got pretty good at tricking browsers and can help you if my example doesn't work for you. Let me know what backend your using and browsers your experimenting with and I will get you working code, but first think about what you really want. Sometimes we have to settle, especially if it is in the best interest of the clients experience using the sites/apps we build, or to improve the security of, not just the client but, our servers and our self.
body{
width: 100vw;
padding: 0;
margin: 0;
background-color: #ddb;
overflow-x: hidden;
}
#login-psuedo{
display: none;
}
#pwd-psuedo{
display: none;
}
<html>
<head>
<style></style>
</head>
<body>
<form>
<input id="login-psuedo" type="text" name="login-psuedo"/>
<input id="pwd-psuedo" type="password" name="pwd-psuedo" autocomplete="new-password"/>
<br />
<label>Login <input type="text" name="login"/></label></br>
<label>New Password <input type="password" name="pwd" autocomplete="new-password"/></label>
<br>
<br>
<input type="submit" value="Submit">
</form>
</html>


I know quite an old question.
But adding autocomplete="off" in the form tag might help (I know not in all cases - as some fields might require autocomplete fills - Specially when you are testing)
works for firefox now* (*98.0.2 (64-bit))

Related

Disabling Safari autofill on usernames and passwords

You might already know, that Safari has a nasty autofill bug where it fills email, username and password fields no matter if you set autocomplete="off" or not.
Here's a basic form:
<form action="/" method="post">
<p>
<label>E-mail</label>
<input type="text" name="email" value="" />
</p>
<p>
<label>Password</label>
<input type="password" name="password" value="" />
</p>
</form>
...Safari autofills those fields on page load like it should, job well done!
If you put autocomplete="off" to the fields and/or the form element, Safari still autofills those fields:
<form action="/" method="post" autocomplete="off">
<p>
<label>E-mail</label>
<input type="text" name="email" value="" autocomplete="off" />
</p>
<p>
<label>Password</label>
<input type="password" name="password" value="" autocomplete="off" />
</p>
</form>
Even this doesn't work:
<form action="/" method="post" autocomplete="off">
<p>
<label>E-mail</label>
<input type="text" name="secretfield1" value="" autocomplete="off"/>
</p>
<p>
<label>Password</label>
<input type="password" name="secretfield2" value="" autocomplete="off" />
</p>
</form>
...since Safari looks up those <label> elements if they contain words "E-mail", "Password" etc. and goes ahead with the autofill.
Aaaahhhhha!, I thought, and tried this:
<form action="/" method="post" autocomplete="off">
<p>
<label>%REPLACE_EMAIL_TITLE%</label>
<input type="text" name="%REPLACE_EMAIL_NAME%" value="" autocomplete="off"/>
</p>
<p>
<label>%REPLACE_PASSWORD_TITLE%</label>
<input type="password" name="%REPLACE_PASSWORD_NAME%" value="" autocomplete="off" />
</p>
</form>
...and replace %TAGS% with the real names using JavaScript. Safari autofill kicks in. No matter if you set a 10 second timeout on the replacement.
So, is this really the only option?
<form action="/" method="post" autocomplete="off">
<p>
<label>That electronic postal address we all use, but can't write the title here because Safari fills this with YOUR information if you have autofill turned on</label>
<input type="text" name="someelectronicpostaladdress" value="" autocomplete="off"/>
</p>
<p>
<label>A set of characters, letters, numbers and special characters that is so secret that only you or the user you are changing it for knows, but can't write the title here because Safari sucks</label>
<input type="password" name="setofseeecretcharacters" value="" autocomplete="off" />
</p>
</form>
I hope not?
UPDATE: #skithund pointed out in Twitter, that Safari is getting a 4.0.3 update, which mentions "Login AutoFill". Does anyone know if that update is going to fix this?

The reason browsers are ignoring autocomplete=off is because there have been some web-sites that tried to disable auto-completing of passwords.
That is wrong.
And in July 2014 Firefox was the last major browser to finally implement the change to ignore any web-site that tries to turn off autocompleting of passwords.
June 2009: IEInternals blog where they discuss keeping the user in control (archive)
February 2014: Chrome's announcement when they began ignoring autocomplete=off (archive)
January 2014: Bugzilla Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager (archive)
Reddit discussion (archive)
One of the top user-complaints about our HTML Forms AutoComplete feature is “It doesn’t work– I don’t see any of my previously entered text.” When debugging such cases, we usually find that the site has explicitly disabled the feature using the provided attribute, but of course, users have no idea that the site has done so and simply assume that IE is buggy. In my experience, when features are hidden or replaced, users will usually blame the browser, not the website.
Any attempt by any web-site to circumvent the browser's preference is wrong, that is why browsers ignore it. There is no reason known why a web-site should try to disable saving of passwords.
Chrome ignores it
Safari ignores it
IE ignores it
Firefox ignores it
At this point, web developers typically protest “But I wouldn’t do this everywhere– only in a few little bits where it makes sense!” Even if that’s true, unfortunately, this is yet another case where there’s really no way for the browser to tell the difference. Remember, popup windows were once a happy, useful part of the web browsing experience, until their abuse by advertisers made them the bane of users everywhere. Inevitably, all browsers began blocking popups, breaking even the “good” sites that used popups with good taste and discretion.
What if I'm a special snowflake?
There are people who bring up a good use-case:
I have a shared, public area, kiosk style computer. We don't want someone to (accidentally or intentionally) save their password so the next user could use it.
That does not violate the statement:
Any attempt by any web-site to circumvent the browser's preference is wrong
That is because in the case of a shared kiosk:
it is not the web-server that has the oddball policy
it is the client user-agent that has the oddball policy
The browser (the shared computer) is the one that has the requirement that it not try to save passwords.
The correct way to prevent the browser from saving passwords
is to configure the browser to not save passwords.
Since you have locked down and control this kiosk computer: you control the settings. That includes the option of saving passwords.
In Chrome and Internet Explorer, you configure those options using Group Policies (e.g. registry keys).
From the Chrome Policy List:
AutoFillEnabled
Enable AutoFill
Data type: Boolean (REG_DWORD)
Windows registry location: Software\Policies\Chromium\AutoFillEnabled
Description: Enables Chromium's AutoFill feature and allows users to auto complete web forms using previously stored information such as address or credit card information. If you disable this setting, AutoFill will be inaccessible to users. If you enable this setting or do not set a value, AutoFill will remain under the control of the user. This will allow them to configure AutoFill profiles and to switch AutoFill on or off at their own discretion.
Please pass the word up to corporate managers that trying to disable autocompleting of password is wrong. It is so wrong that browsers are intentionally ignoring anyone who tries to do it. Those people should stop doing the wrong thing.™
Put it another way
In other words:
if the users browser
mistakes "Please enter the name of your favorite maiden name's first color." for a new password
and the user
doesn't want their browser
to update their password,
then they
will click Nope
if i want to save my HIPPA password: that's my right
if i want to save my PCI password: that's my right
if i want to save the "new password for the user": that's my right
if i want to save the one-time-password: that's my right
if i want to save my "first color's favorite maiden" answer: that's my right.
It's not your job to over-rule the user's wishes. It's their browser; not yours.

I had the same problem. And though my solution is not perfect, it seems to work. Basically, Safari seems to look for an input field with password and username and always tries to fill it. So, my solution was to add a fake username and password field before the current one which Safari could fill. I tried using style="display: none;" but that did not work. So, eventually, I just used
<input id="fake_user_name" name="fake_user[name]" tabindex="-1"
style="display:none;" type="text" value="Safari Autofill Me"
and this hid the input field out of sight and seemed to work fine.
I did not want to use JavaScript but I guess you could hide it with JavaScript.
Now Safari never autocompletes my username and password fields.

Fix: browser autofill in by readonly-mode and set writable on focus
<input type="password" readonly onfocus="this.removeAttribute('readonly');"/>
(focus = at mouse click and tabbing through fields)
Update:
Mobile Safari sets cursor in the field, but does not show virtual keyboard. New Fix works like before but handles 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
Explanation: Browser auto fills credentials to wrong text field?
Ok, you just noticed that:
Safari autofill kicks in. No matter [what the fields are named] #Jari
and there's an assumption that:
Safari seems to look for an input field with password and username and always tries to fill it #user3172174
Sometimes 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 autofills username into the nearest textlike-input field , that appears prior the password field in DOM (just guessing due to observation). As the browser is the last instance and you can not control it,
sometimes even autocomplete=off would not prevent to fill in credentials into wrong fields, but not user or nickname field.
This readonly-fix above worked for me.

Adding the CSS to the input will hide the Safari button pseudo-element and users will not be able to use autocomplete:
input::-webkit-contacts-auto-fill-button,
input::-webkit-credentials-auto-fill-button {
visibility: hidden;
position: absolute;
right: 0;
}

This question has already been successfully answered, but as of today's date, the solution didn't work for me without making some oddly particular changes - so I'm noting it here as much for my own reference if I decide to come back to it as for everyone else's.
The fake input needs to be after the real email input in the dom.
The fake input requires a fake label.
The fake label cannot be absolutely positioned.
Can't use display, visibility or opacity to hide the fake elements.
The only solution I found was to clip the visibility of the fake elements with overflow: hidden.
<label for="user_email">Email</label>
<input autocomplete="off" type="text" value="user#email.com" name="user[email]" id="user_email">
<!-- Safari looks for email inputs and overwrites the existing value with the user's personal email. This hack catches the autofill in a hidden input. -->
<label for="fake_email" aria-hidden="true" style="height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px)">Email</label>
<input type="text" name="fake[email]" id="fake_email" style="height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px)" tab-index="-1" aria-hidden="true">
For the record, the particular case this hack came in useful for was one where an admin is editing the profile of other users and Safari was replacing the email of the user with the email of the admin. We've decided that for the small (but frustrating) amount of support requests that this Safari 'feature' creates, it's not worth maintaining a hack that seems to need to evolve as Safari tightens up on it, and instead provide support to those users on how to turn off autofill.

Just put search into the name, Safari will ignore the field for autofill.
<input type="password" name="notsearch_password">

After scanning through Apple's Safari HTML pages and not finding anything on auto complete, I did some searching and thinking.
After reading a (mildly) related question on Apple discussions, I remembered that the default is to not allow remembered passwords, etc (which can be enabled in iDevice system settings, or at the prompt). Since Apple has moved this feature out of the browser and into their (proprietary, i)OS (screen shots on this article), I believe they are ignoring the HTML form/field property entirely.
Unless they change their mentality as to this feature, as I'm sure this is their expected behavior, on their locked down devices, I would work under the assumption that this isn't going away. This is probably different for native iOS apps. Definitely keep the form autocomplete="off" and hopefully they'll one day get back to the HTML5 standard for the feature.
I know this doesn't include any work around, but I think if you come to terms with it being a non-browser 'feature' on iDevices, it makes sense (in an Apple kind of way).

I can't believe this is still an issue so long after it's been reported. The above 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="position:absolute;height:0px; overflow:hidden; ">
Username <input type="text" name="fake_safari_username" >
Password <input type="password" name="fake_safari_password">
</div>
Hope that's useful for somebody!

I have also been bitten by Safari's weird default autocomplete behaviour, but rather than completely disable it, I managed to make it work for me by following the guidelines at https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands.
Specifically, I put autocomplete="username" on the username field and autocomplete="password-current" on the password field. This tells the browser which fields to autofill, rather than having it guess, and it fixed autocomplete for my use case.
This approach works for both "email first" login forms (password field not immediately visible, eg Google login) as well as conventional login forms with both username and password fields visible.

My issue: I have a section in an admin area that allows users to set all language values, some of which contain the words "password", "email", "email address" etc. I don't want these values to be filled with the user's details, they are for creating translations into another language. This is then a valid exception to the "circumvent the browser's preference" mentioned.
My solution: I simply created alternate names:
$name = str_replace('email','em___l',$name);
$name = str_replace('password','pa___d',$name);
<input type="text" name="<?=$name?>" id="<?=$name?>" />
Then when the form is posted:
foreach($_POST as $name=>$value) {
$name=str_replace('em___l','email',$name);
$name=str_replace('pa___d','password',$name);
$_POST[$name]=$value;
}
This is the only method that worked for me.

For me, this problem was very sharp. But only about password autofill.
Safari generates it's 'strong' password into a sign-in form. Not a sign-up form. Only the user's password will work in sign-in form, not generated. Obvious.
I made a few tries to disable it with advice from here. But without results.
BTW. It was easy to fix with angular binding. So. This code will work 4 you only in case of using Angular2+ in the web layer.
<mat-form-field appearance="fill">
<mat-label>Enter your password</mat-label>
<input #pwd
matInput
[type]="pwd.value.length === 0 ? 'text': 'password'"
formControlName="passwordCtrl"
required>
</mat-form-field>
Attribute [type] use one side binding with "[", "]". And automatically set value by the condition "(condition) ? option1: option2". If no symbols in the input - then the type is 'text'.
And not very 'clever' Safari browser doesn't perform autofill. So. Goal reached. Autofill disabled.
After more than 1 symbol in the input field. Type changes to 'password' very fast. And the user has no idea about something that happened. The type of the field is 'password'.
Also, it works with (keypressed) Event. Or using [(ngModel)]="pwd" instead of #pwd. And access by reactive forms.
But the basic thing that solved the problem for my cases - angular binding.

I came up with a similar solution to Nikita Danilov's, but for vanilla JavaScript instead of Angular.
Basic principle is for the field to start off as a generic type like "text" or "number", then switch to "password" or "email" where appropriate. onkeydown is a good event to bind here - should work on Desktop and Mobile.
Example:
<input
type="text"
name="password"
id="password"
autocomplete="off"
onkeydown="this.setAttribute('type','password')"
>
While I understand the points made against introducing this behaviour, I think many make an assumption that the context of a password field is always a login / registration form that the end-user interacts with. In some cases e.g. where passwords or other details are being set on admin panels, by users other than the end-user, I believe it is justified to avoid engaging the browser's autofill, as it is linked against the current user's personal data. In such case the current user, is not the end-user.

You can try this variant. It works for me.
If you change field value once, Safari will change it again. If user clicked at this field, after this the value wouldn't be changed by Safari automatically.
$.browser.chrome = /chrome/.test(navigator.userAgent.toLowerCase());
if($.browser.chrome){
$.browser.safari = false;
}
var isChanged=false;
$('#Email').change(function () {
if ($.browser.safari && !isChanged) {
$('#Email').val('#Model.Email');
}
});
$('#Email').click(function () {
if ( $.browser.safari && !isChanged) {
isChanged = true;
}
}); var isChangePassword = false;
$('#OldPassword').change(function () {
if ($.browser.safari && !isChangePassword) {
$('#OldPassword').val('');
}
});
$('#OldPassword').click(function () {
if ($.browser.safari && !isChangePassword) {
isChangePassword= true;
}
});

It seems the browser programmers think they know more than the website writers. While it's sometimes handy to allow the user to save passwords, there are other times when it's a security risk. For those times, this workaround might help:
Start by using a conventional text input, instead of a 'password' type.
Password: &nbsp <input type="text" id="fkpass" name="bxpass" class="tinp" size="20" />
Then - if you wish - set the focus to the input field.
<BODY onLoad="fitform()">
Put the JS at the end of the page.
<script type="text/javascript">
document.entry.fkpass.focus();
function fitform() {
document.getElementById('fkpass').autocomplete = 'off';
}
</script>
Now you have a conventional form field. What good is that?
Change the CSS style for that input so it uses a font that is all 'bullets' instead of characters.
<style type="text/css">
#font-face { font-family: fdot; src: url('images/dot5.ttf'); }
#font-face { font-family: idot; src: url('images/dot5.eot'); }
#font-face { font-family: wdot; src: url('images/dot5.woff'); }
#font-face { font-family: w2dot; src: url('images/dot5.woff2'); }
.tinp { font-family: fdot, idot, wdot, w2dot; color: #000; font-size:18px; }
</style>
Yes, you could 'tidy up' the code, and add .svg to it.
Either way, the end result is indistinguishable from the 'real' password input, and the browser won't offer to save it.
If you want the font, it's here.
It was created with CorelDraw and converted with an online webfont conversion utility. (dot_webfont_kit.zip 19.3k)
I hope this helps.

Remove <form> element. To keep form behavior you can listen keypress event for input fields to handle enter key pressed. Just in case I removed input type="submit" too. You can use button type="button".

Better than use JS to clear content - simply fake password field:
<input type="text" name="user" />
<input fake_pass type="password" style="display:none"/>
<input type="password" name="pass" />
A password type doubled put the browser in incertitude so it autocompletes only user name
fake_pass input should not have name attribute to keep $_POST clean!

The CSS display: none solutions mentioned here did not work for me (October 2016). I fixed this issue with JavaScript.
I don't mind the browser remembering passwords, but wanted to prevent a bad autofill. In my case, a form with a password field and no associated username field. (User edit form in Drupal 7 site, where the password field is required only for some operations.) Whatever I tried, Safari would find a victim field for the username of the autofilled password (the field placed visually before, for instance).
I'm restoring the original value as soon as Safari does the autofill. I'm trying this only for the first 2 seconds after page load. Probably even lower value is OK. My tests showed the autofill happens around 250 ms after page load (though I imagine this number depends a lot on how the page is constructed and loaded).
Here's my JavaScript code (with jQuery):
// Workaround for Safari autofill of the e-mail field with the username.
// Try every 50ms during 2s to reset the e-mail to its original value.
// Prevent this reset if user might have changed the e-mail himself, by
// detecting focus on the field.
if ($('#edit-mail').length) {
var element = $('#edit-mail');
var original = element.attr('value');
var interval = setInterval(function() {
if ($(document.activeElement).is(element)) {
stop();
} else if (element.val() != original) {
element.val(original);
stop();
}
}, 50);
var stop = function() {
clearTimeout(timeout);
clearInterval(interval);
}
var timeout = setTimeout(function() {
clearInterval(interval);
}, 2000);
}

I had the same problem suddenly in a SPA with React in Mobile Safari 10.3.1
I do not need any tricky workarounds before in all tested browsers, even Mobile Safari IOS 10.2
But since 10.3.1 username or password will be filled in fields mentioning the words 'password','email','username' in any forms after login with active remember option. It seems that the rendered DOM-Tree is 'analyzed' using a full text search and then the user agent fill in data without respecting any autocomplete="off" setting.
Happens funnyli also on placeholder text for a field. So you must be very carful with naming, when you don't want to have prefilled username or password in places where this data is not useful.
The only solution after hours of investigating was the solution here posted too.
Provide a input field named "email" and hideout the containing div with height: 0px, overflow: hidden.

You can disable it by adding this attribute to password input
autocomplete="new-password"

Chrome ignores autocomplete="off"

I've created a web application which uses a tagbox drop down. This works great in all browsers except Chrome browser (Version 21.0.1180.89).
Despite both the input fields AND the form field having the autocomplete="off" attribute, Chrome insists on showing a drop down history of previous entries for the field, which is obliterating the tagbox list.

Prevent autocomplete of 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 (might not work):
<input type="text" name="field" autocomplete="nope">
Explanation:
autocomplete still works on an <input>despite having autocomplete="off", but you can change off to a random string, like nope.
Others "solutions" for disabling the autocomplete of a field (it's not the right way to do it, but it works):
1.
HTML:
<input type="password" id="some_id" autocomplete="new-password">
JS (onload):
(function() {
var some_id = document.getElementById('some_id');
some_id.type = 'text';
some_id.removeAttribute('autocomplete');
})();
or using jQuery:
$(document).ready(function() {
var some_id = $('#some_id');
some_id.prop('type', 'text');
some_id.removeAttr('autocomplete');
});
2.
HTML:
<form id="form"></form>
JS (onload):
(function() {
var input = document.createElement('INPUT');
input.type = 'text';
document.getElementById('form').appendChild(input);
})();
or using jQuery:
$(document).ready(function() {
$('<input>', {
type: 'text'
}).appendTo($('#form'));
});
To add more than one field using jQuery:
function addField(label) {
var div = $('<div>');
var input = $('<input>', {
type: 'text'
});
if(label) {
var label = $('<label>', {
text: label
});
label.append(input);
div.append(label);
} else {
div.append(input);
}
div.appendTo($('#form'));
}
$(document).ready(function() {
addField();
addField('Field 1: ');
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<form id="form"></form>
Works in:
Chrome: 49+
Firefox: 44+

UPDATE
It seems now Chrome ignores the style="display: none;" or style="visibility: hidden; attributes.
You can change it to something like:
<input style="opacity: 0;position: absolute;">
<input type="password" style="opacity: 0;position: absolute;">
In my experience, Chrome only autocompletes the first <input type="password"> and the previous <input>. So I've added:
<input style="display:none">
<input type="password" style="display:none">
To the top of the <form> and the case was resolved.

It appears that Chrome now ignores autocomplete="off" unless it is on the <form autocomplete="off"> tag.

2021 UPDATE:Change <input type="text"> to <input type="search" autocomplete="off" >
That is all. Keeping the below answer around for nostalgia.
For a reliable workaround, you can add this code to your layout page:
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete"
name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Chrome respects autocomplete=off only when there is at least one other input element in the form with any other autocomplete value.
This will not work with password fields--those are handled very differently in Chrome. See https://code.google.com/p/chromium/issues/detail?id=468153 for more details.
UPDATE: Bug closed as "Won't Fix" by Chromium Team March 11, 2016. See last comment in my originally filed bug report, for full explanation. TL;DR: use semantic autocomplete attributes such as autocomplete="new-street-address" to avoid Chrome performing autofill.

Modern Approach
Simply make your input readonly, and on focus, remove it. This is a very simple approach and browsers will not populate readonly inputs. Therefore, this method is accepted and will never be overwritten by future browser updates.
<input type="text" onfocus="this.removeAttribute('readonly');" readonly />
The next part is optional. Style your input accordingly so that it does not look like a readonly input.
input[readonly] {
cursor: text;
background-color: #fff;
}
WORKING EXAMPLE

Well, a little late to the party, but it seems that there is a bit of misunderstanding about how autocomplete should and shouldn't work. According to the HTML specifications, the user agent (in this case Chrome) can override autocomplete:
https://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute
A user agent may allow the user to override an element's autofill field name, e.g. to change it from "off" to "on" to allow values to be remembered and prefilled despite the page author's objections, or to always "off", never remembering values. However, user agents should not allow users to trivially override the autofill field name from "off" to "on" or other values, as there are significant security implications for the user if all values are always remembered, regardless of the site's preferences.
So in the case of Chrome, the developers have essentially said "we will leave this to the user to decide in their preferences whether they want autocomplete to work or not. If you don't want it, don't enable it in your browser".
However, it appears that this is a little over-zealous on their part for my liking, but it is the way it is. The specification also discusses the potential security implications of such a move:
The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for him; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values.
So after experiencing the same frustration as everyone else, I found a solution that works for me. It is similar in vein to the autocomplete="false" answers.
A Mozilla article speaks to exactly this problem:
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
In some case, 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
So the following code should work:
autocomplete="nope"
And so should each of the following:
autocomplete="false"
autocomplete="foo"
autocomplete="bar"
The issue I see is that the browser agent might be smart enough to learn the autocomplete attribute and apply it next time it sees the form. If it does do this, the only way I can see to still get around the problem would be to dynamically change the autocomplete attribute value when the page is generated.
One point worth mentioning is that many browser will ignore autocomplete settings for login fields (username and password). As the Mozilla article states:
For this reason, many modern browsers do not support autocomplete="off" for login fields.
If a site sets autocomplete="off" for a form, and the form includes username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits this page.
If a site sets autocomplete="off" for username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits this page.
This is the behavior in Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11).
Finally a little info on whether the attribute belongs on the form element or the input element. The spec again has the answer:
If the autocomplete attribute is omitted, the default value corresponding to the state of the element's form owner's autocomplete attribute is used instead (either "on" or "off"). If there is no form owner, then the value "on" is used.
So. Putting it on the form should apply to all input fields. Putting it on an individual element should apply to just that element (even if there isn't one on the form). If autocomplete isn't set at all, it defaults to on.
Summary
To disable autocomplete on the whole form:
<form autocomplete="off" ...>
Or if you dynamically need to do it:
<form autocomplete="random-string" ...>
To disable autocomplete on an individual element (regardless of the form setting being present or not)
<input autocomplete="off" ...>
Or if you dynamically need to do it:
<input autocomplete="random-string" ...>
And remember that certain user agents can override even your hardest fought attempts to disable autocomplete.

TL;DR: Tell Chrome that this is a new password input and it won't provide old ones as autocomplete suggestions:
<input type="password" name="password" autocomplete="new-password">
autocomplete="off" doesn't work due to a design decision - lots of research shows that users have much longer and harder to hack passwords if they can store them in a browser or password manager.
The specification for autocomplete has changed, and now supports various values to make login forms easy to auto complete:
<!-- Auto fills with the username for the site, even though it's email format -->
<input type="email" name="email" autocomplete="username">
<!-- current-password will populate for the matched username input -->
<input type="password" autocomplete="current-password" />
If you don't provide these Chrome still tries to guess, and when it does it ignores autocomplete="off".
The solution is that autocomplete values also exist for password reset forms:
<label>Enter your old password:
<input type="password" autocomplete="current-password" name="pass-old" />
</label>
<label>Enter your new password:
<input type="password" autocomplete="new-password" name="pass-new" />
</label>
<label>Please repeat it to be sure:
<input type="password" autocomplete="new-password" name="pass-repeat" />
</label>
You can use this autocomplete="new-password" flag to tell Chrome not to guess the password, even if it has one stored for this site.
Chrome can also manage passwords for sites directly using the credentials API, which is a standard and will probably have universal support eventually.

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.

The solution at present is to use type="search". Google doesn't apply autofill to inputs with a type of search.
See: https://twitter.com/Paul_Kinlan/status/596613148985171968
Update 04/04/2016: Looks like this is fixed! See http://codereview.chromium.org/1473733008

Browser does not care about autocomplete=off auto or even fills credentials to wrong text field?
I fixed it by setting the password field to read-only and activate it, when user clicks into it or uses tab-key to this field.
fix browser autofill in: readonly and set writeble on focus (at mouse click and tabbing through fields)
<input type="password" readonly
onfocus="$(this).removeAttr('readonly');"/>
Update:
Mobile Safari sets cursor in the field, but does not show virtual keyboard. New Fix works like before but handles 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
By the way, more information on my observation:
Sometimes 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 autofills username into the nearest textlike-input field , that appears prior the password field in DOM (just guessing due to observation). As the browser is the last instance and you can not control it, sometimes even autocomplete=off would not prevent to fill in credentials into wrong fields, but not user or nickname field.

Chrome version 34 now ignores the autocomplete=off,
see this.
Lots of discussion on whether this is a good thing or a bad thing? Whats your views?

You can use autocomplete="new-password"
<input type="email" name="email">
<input type="password" name="password" autocomplete="new-password">
Works in:
Chrome: 53, 54, 55
Firefox: 48, 49, 50

[Works in 2021 for Chrome(v88, 89, 90), Firefox, Brave, Safari]
The old answers already written here will work with trial and error, but most of
them don't link to any official doc or what Chrome has to say on this
matter.
The issue mentioned in the question is because of Chrome's autofill feature, and here is Chrome's stance on it in this bug link - https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164
To put it simply, there are two cases -
[CASE 1]: Your input type is something other than password. In this case, the solution is simple, and has three steps.
Add name attribute to input
name should not start with a value like email or username, otherwise Chrome still ends up showing the dropdown. For example, name="emailToDelete" shows the dropdown, but name="to-delete-email" doesn't. Same applies for autocomplete attribute.
Add autocomplete attribute, and add a value which is meaningful for you, like new-field-name
It will look like this, and you won't see the autofill for this input again for the rest of your life -
<input type="text/number/something-other-than-password" name="x-field-1" autocomplete="new-field-1" />
[CASE 2]: input type is password
Well, in this case, irrespective of your trials, Chrome will show you the dropdown to manage passwords / use an already existing password. Firefox will also do something similar, and same will be the case with all other major browsers. [1]
In this case, if you really want to stop the user from seeing the dropdown to manage passwords / see a securely generated password, you will have to play around with JS to switch input type, as mentioned in the other answers of this question.
[1] A detailed MDN doc on turning off autocompletion - https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion

Autocomplete="Off" doesn't work anymore.
Try using just a random string instead of "Off", for example Autocomplete="NoAutocomplete"
I hope it helps.

I am posting this answer to bring an updated solution to this problem.
I am currently using Chrome 49 and no given answer work for this one.
I am also looking for a solution working with other browsers and previous versions.
Put this code on the beginning of your form
<div style="display: none;">
<input type="text" autocomplete="new-password">
<input type="password" autocomplete="new-password">
</div>
Then, for your real password field, use
<input type="password" name="password" autocomplete="new-password">
Comment this answer if this is no longer working or if you get an issue with another browser or version.
Approved on:
Chrome : 49
Firefox : 44, 45
Edge : 25
Internet Explorer : 11

Seen chrome ignore the autocomplete="off", I solve it with a stupid way which is using "fake input" to cheat chrome to fill it up instead of filling the "real" one.
Example:
<input type="text" name="username" style="display:none" value="fake input" />
<input type="text" name="username" value="real input"/>
Chrome will fill up the "fake input", and when submit, server will take the "real input" value.

No clue why this worked in my case, but on chrome I used autocomplete="none" and Chrome stopped suggesting addresses for my text field.

Writing a 2020+ answer in case if this helps anyone. I tried many combinations above, though there is one key that was missed in my case. Even though I had kept autocomplete="nope" a random string, it didn't work for me because I had name attribute missing!
so I kept name='password'
and autocomplete = "new-password"
for username, I kept name="usrid" // DONT KEEP STRING THAT CONTAINS 'user'
and autocomplete = "new-password" // Same for it as well, so google stops suggesting password (manage password dropdown)
this worked very well for me.
(I did this for Android and iOS web view that Cordova/ionic uses)
<ion-input [type]="passwordType" name="password" class="input-form-placeholder" formControlName="model_password"
autocomplete="new-password" [clearInput]="showClearInputIconForPassword">
</ion-input>

autocomplete="off" is usually working, but not always. It depends on the name of the input field. Names like "address", 'email', 'name' - will be autocompleted (browsers think they help users), when fields like "code", "pin" - will not be autocompleted (if autocomplete="off" is set)
My problems was - autocomplete was messing with google address helper
I fixed it by renaming it
from
<input type="text" name="address" autocomplete="off">
to
<input type="text" name="the_address" autocomplete="off">
Tested in chrome 71.

Some end 2020 Update. I tried all the old solutions from different sites. None of them worked! :-(
Then I found this:
Use
<input type="search"/>
and the autocomplete is gone!
Success with Chrome 86, FireFox, Edge 87.

autocomplete=off is largely ignored in modern browsers - primarily due to password managers etc.
You can try adding this autocomplete="new-password" it's not fully supported by all browsers, but it works on some

to anyone looking for a solution to this, I finally figure it out.
Chrome only obey's the autocomplete="off" if the page is a HTML5 page (I was using XHTML).
I converted my page to HTML5 and the problem went away (facepalm).

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

Up until just this last week, the two solutions below appeared to work for Chrome, IE and Firefox. But with the release of Chrome version 48 (and still in 49), they no longer work:
The following at the top of the form:
<input style="display:none" type="text" name="fakeUsername"/>
<input style="display:none" type="password" name="fakePassword"/>
The following in the password input element:
autocomplete="off"
So to quickly fix this, at first I tried to use a major hack of initially setting the password input element to disabled and then used a setTimeout in the document ready function to enable it again.
setTimeout(function(){$('#PasswordData').prop('disabled', false);}, 50);
But this seemed so crazy and I did some more searching and found #tibalts answer in Disabling Chrome Autofill. His answer is to use autocomplete="new-password" in the passwords input and this appears to work on all browsers (I have kept my fix number 1 above at this stage).
Here is the link in the Google Chrome developer discussion:
https://code.google.com/p/chromium/issues/detail?id=370363#c7

After the chrome v. 34, setting autocomplete="off" at <form> tag doesn`t work
I made the changes to avoid this annoying behavior:
Remove the name and the id of the password input
Put a class in the input (ex.: passwordInput )
(So far, Chrome wont put the saved password on the input, but the form is now broken)
Finally, to make the form work, put this code to run when the user click the submit button, or whenever you want to trigger the form submittion:
var sI = $(".passwordInput")[0];
$(sI).attr("id", "password");
$(sI).attr("name", "password");
In my case, I used to hav id="password" name="password" in the password input, so I put them back before trigger the submition.

I had a similar issue where the input field took either a name or an email. I set autocomplete="off" but Chrome still forced suggestions. Turns out it was because the placeholder text had the words "name" and "email" in it.
For example
<input type="text" placeholder="name or email" autocomplete="off" />
I got around it by putting a zero width space into the words in the placeholder. No more Chrome autocomplete.
<input type="text" placeholder="nam​e or emai​l" autocomplete="off" />

Instead of autocomplete="off" use autocomplete="false" ;)
from: https://stackoverflow.com/a/29582380/75799

In Chrome 48+ use this solution:
Put fake fields before real fields:
<form autocomplete="off">
<input name="fake_email" class="visually-hidden" type="text">
<input name="fake_password" class="visually-hidden" type="password">
<input autocomplete="off" name="email" type="text">
<input autocomplete="off" name="password" type="password">
</form>
Hide fake fields:
.visually-hidden {
margin: -1px;
padding: 0;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0 0 0 0);
clip: rect(0, 0, 0, 0);
position: absolute;
}
You did it!
Also this will work for older versions.

I managed to disable autocomple exploiting this rule:
Fields that are not passwords, but should be obscured, such as credit
card numbers, may also have a type="password" attribute, but should
contain the relevant autocomplete attribute, such as "cc-number" or
"cc-csc".
https://www.chromium.org/developers/design-documents/create-amazing-password-forms
<input id="haxed" type="password" autocomplete="cc-number">
However it comes with the great responsibility :)
Don’t try to fool the browser Password managers (either built into the
browser, or external) are designed to ease the user experience.
Inserting fake fields, using incorrect autocomplete attributes or
taking advantage of the weaknesses of the existing password managers
simply leads to frustrated users.

Update 08/2022:
I managed to get autocomplete to be respected by including
autocomplete="new-password"
on each individual input element regardless of type.
E.g.
<input id="email" type="email" autocomplete="new-password"/>

IE9 Textbox Autocomplition coming on outside on a textareabox

While using IE9 I found a strange problem on textbox entry the code is following
<input type="text" name="textbox" id="textbox_1" value="">
When after the first entry when I am going to put another value here then Autocomplition text is coming outside on a textarea. Is there any way to turn this off

The autocomplete="off" attribute works in everything but Opera. May be what you need.
I don't really see why autocomplete is a problem though. It is there to aid the user, therefore giving them a better experience. Removing this option just makes the users experience worse.

HTML - Will browsers autofill hidden fields?

My site suffers from a lot of spam bots. If I have the login form:
<input name="username" type="hidden" />
<input name="password" type="hidden" />
<input name="hidden_1" type="text" />
<input name="hidden_2" type="password" />
So the user actually see's the 'hidden' prefix fields, and the username/password named fields are actually the hidden ones. If the username or password field is submitted with values, we know bot filled them out and can ban them.
My question is, do browsers auto fill hidden fields? Is this quite a good technique? I know this isn't going to stop all bots that are semi intelligent, but if this even blocks 1 bot, without affecting any genuine users it's worth doing.

I think that not all bots just search for "username" and "password" names, but also type="password". So this might not avoid bot access at all.
You can use a capture like ReCAPTCHA. It is free and easy to use. Additionally you can create a banlist and show a 404 to bots via htaccess.

This article might help you:
http://www.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/
Your method is actually fairly decent, but you may still suffer from some spam, especially if forms are manually filled out

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

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

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

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.

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.

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.

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.

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

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.

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.

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.

Three options:
First:
<input type='text' autocomplete='off' />
Second:
<form action='' autocomplete='off'>
Third (JavaScript code):
$('input').attr('autocomplete', 'off');

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

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

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

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

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>

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!

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.

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.

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

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.

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.

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"

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

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

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.

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.

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

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>

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>

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.