Prevent Chrome from prompting to save password from input box?

Instead of using input type password, use type text with style set to style="-webkit-text-security: disc;" which will replace the characters with dots.

<input type="text" id="password" style="-webkit-text-security: disc;"> 

There are other options to using the dot:

input { -webkit-text-security: none; } input { -webkit-text-security: circle; } input { -webkit-text-security: square; } input { -webkit-text-security: disc; /* Default */ } 

Answer found here: how to disable save password prompt in chrome

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.

• Bugzilla Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager (archive.is)
• Reddit discussion (archive.is)
• Chrome's announcement when they began ignoring autocomplete=off (archive.is)
• IE11 fixed the bug of not being able to auto-complete passwords (archive.is)

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
• Edge ignores it
• Firefox ignores it

Microsoft even had to explain before IE11 that it wasn't a bug in the browser - that the web-site was broken: Why Won’t IE Remember My Login Info? (archive.is)

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

We need to prevent governments, corporate polcies, security auditors, PCI, HIPPA from trying to prevent users from saving passwords. There is no valid use case to prevent a user from saving their credentials.

• If you have a password reset screen: the password should be entered in an unmasked plaintext box
• If you want a 2FA password: the password should be entered in an unmasked plaintext box
• If you have a one-time password: the password should be entered in an unmasked plaintext box

You are free to suggest an alternative that:

• allows a web-site to prevent saving of passwords
• as long as it can never be used to prevent a user from saving any passwords

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

It's not your job to over-rule the user's wishes. It's their browser; not yours.

Current state of the Web-App vs. Browser Developer war:

Setting the password input's type and text is no longer adequate as of August 2021. Furthermore, Chrome prompts for password even if no form submission takes place. Simply detaching the password input element generates the prompt. Fer crying out loud. (Possibly triggered by a navigator fragment-only state transition used to route the browser back button onto the dialog's cancel button, which doesn't do a form submit either. There is no form element).

The following code is from a react app, but applicability should be obvious.

 let passwordInput = this.refPassword.current; if (passwordInput) { passwordInput.setAttribute("value",""); // overwrite the password. passwordInput.setAttribute("type","text"); // change the type of the input element. } // delay dismissing the dialog. setTimeout(()=> { // dismiss the dialog. this.props.onCancel(); }); 

Without the setTimeout call, Chrome 92.0.4515.159 currently prompts to save the password with the value of the password input before the value was set to "" if the input control is detached immediately by, for example, pressing the "Cancel" button. The setTimeout call is required to prevent this behavior. Personally, I prefer this solution to using the -webkit styles, because it is -- for the meantime -- relatively portable.

For those who would defend browser developers' actions, this is the use case. The application is a single-page web app developed with react framework. The dialog in question is the configuration dialog for the Wi-Fi access point on an IoT device. The password box contains the WEP passphrase for the Wi-Fi access point (it has a visible/non-visible password decoration, and code to display "(Unchanged)" if the password has not yet been edited so that stored passwords never get sent back to the web app). The code in question prevents a password save prompt in the case where the user has clicked the cancel button, even if the password input is in error state because the password doesn't meet the the minimum-length of 8 characters required by WEP!

Clicking on save for the WEP passphrase overwrites the actual site password with the WEP passphrase. Clicking on "Never" disables saving of the main site password. So in terms of respecting user intent, the purpose here is to PREVENT the user from doing something catastrophic such as clicking the "Never" button, which will prevent password saving for the actual login dialog, where it's needed.

Is there some security motivation going on here that has caused browser developers to escalate this battle so severely? I just can't imagine what the security consequences of NOT saving a password would be.

You can change the type of the password field to text before submitting the form:  

<script type="text/javascript"> function validate() { return true; } function copyPass() { document.getElementById("hidPassword").value = document.getElementById("passwordField").value; if (document.getElementById("passwordField").value != "") { var passwordLength = document.getElementById("passwordField").value.length; document.getElementById("passwordField").value = "•".repeat(passwordLength); } document.getElementById("passwordField").type = 'text'; } function changeType() { document.getElementById("passwordField").type = 'password'; document.getElementById("passwordField").value = document.getElementById("hidPassword").value; } </script> <form method="post" action="yoururl" runat="server"> <input type="text" name="username" /> <input type="password" id="passwordField" name="passwordField" onfocus="javascript:changeType()" onblur="javascript: copyPass()" /> <input type="hidden" name="hidPassword" id="hidPassword" value="" /> <input type="submit" runat="server" name="btnsubmit" value="Submit" onclick="javascript:return validate()" /> </form> 

I found out that whatever you do, recent browsers save the value of input field which is of type="password". I found a workaround. What i did was, i turned the password field type into text field (type="text") and masked the value. Now chrome wont save your password field as now it is a "text" field.

@font-face { font-family: "password-font"; src: url(data:font/woff;charset:utf-8;base64,d09GRgABAAAAAAusAAsAAAAAMGgAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABHU1VCAAABCAAAADsAAABUIIslek9TLzIAAAFEAAAAPgAAAFZjRmM5Y21hcAAAAYQAAAgCAAArYmjjYVVnbHlmAAAJiAAAAEEAAABQiOYj2mhlYWQAAAnMAAAALgAAADYOxVFUaGhlYQAACfwAAAAcAAAAJAqNAyNobXR4AAAKGAAAAAgAAAAIAyAAAGxvY2EAAAogAAAABgAAAAYAKAAAbWF4cAAACigAAAAeAAAAIAEOACJuYW1lAAAKSAAAAUIAAAKOcN63t3Bvc3QAAAuMAAAAHQAAAC5lhHRpeJxjYGRgYOBiMGCwY2BycfMJYeDLSSzJY5BiYGGAAJA8MpsxJzM9kYEDxgPKsYBpDiBmg4gCACY7BUgAeJxjYGScwDiBgZWBgSGVtYKBgVECQjMfYEhiYmFgYGJgZWbACgLSXFMYHIAq/rNfAHK3gEmgASACAIekCT4AAHic7dhl0zDVmUXh5+XFHYK7E0IguFtwt4QQgmtwd3d3d7cED+4SXIO7u7vbsNfaUzU1fyGcu66u1adOf+6uHhgYGGpgYGDwL37/iyEHBoZZcWDQLzUw9NK/7A5if/DA8OwPOfQknBky+0P8/PPPOcd1UJ785frr/Dq/zq/z6/w3zsCgoX/xX74GRsxbcYpRB1iDB/7PGvT/DFGDenBwe8hKD1XpoSs9TKWHrfRwlR6+0iNUesRKj1TpkSs9SqVHrfRolR690r+p9BiVHrPSY1V67EqPU+lxKz1epcev9ASVnrDSE1V64kpPUulJKz1ZpSev9BSVnrLSU1V66kr/ttLTVPp3lZ62/KJSerpKT1/pP1R6hkrPWOmZKj1zpWep9KyVnq3Ss1d6jkrPWem5Kj13peep9LyVnq/S81d6gUr/sdILVnqhSi9c6UUqvWilF6v04pVeotJLVnqpSi9d6WUqvWyll6v08pVeodIrVvpPlf5zpVeq9F8qvXKl/1rpVSr9t0qvWunVKr16pdeo9JqVXqvSa1d6nUqvW+n1Kr1+pTeo9N8rvWGlN6r0xpXepNKbVnqzSm9e6S0qvWWlt6r01pXeptLbVnq7Sm9f6R0qvWOld6r0zpXepdK7Vnq3Su9e6T0qvWel96r03pXep9L7Vnq/Su9f6QMqfWClD6r0wZU+pNKHVvqwSh9e6SMqfWSlj6r00ZU+ptLHVvq4Sh9f6RMqfWKlT6r0yZU+pdKnVvq0Sp9e6TMqfWalz6r02ZU+p9LnVvq8Sp9f6QsqfWGl/1Hpf1b6okpfXOlLKn1ppS+r9OWVvqLS/6r0lZW+qtJXV/qaSl9b6esqfX2lb6j0jZW+qdI3V/qWSt9a6dsqfXul76j0vyt9Z6XvqvTdlb6n0vdW+r5K31/pByr9YKUfqvTDlX6k0v+p9KOVfqzSj1f6iUo/WemnKv10pZ+p9LOVfq7Sz1f6hUq/WOmXKv1ypV+p9KuVfq3Sr1f6jUq/Wem3Kv12pd+p9LuVfq/S71f6g0p/WOmPKv1xpT+p9KeV/qzSn1f6i0p/WemvKv11pb+p9LeV/q7S31f6h0r/WOmfKv1zDfI26KKHED1Y9JCihxI9tOhhRA8rejjRw4seQfSIokcSPbLoUUSPKno00aOL/o3oMUSPKXos0WOLHkf0uKLHEz2+6AlETyh6ItETi55E9KSiJxM9uegpRE8peirRU4v+rehpRP9O9LSify96OtHTi/6D6BlEzyh6JtEzi55F9KyiZxM9u+g5RM8pei7Rc4ueR/S8oucTPb/oBUT/UfSCohcSvbDoRUQvKnox0YuLXkL0kqKXEr206GVELyt6OdHLi15B9Iqi/yT6z6JXEv0X0SuL/qvoVUT/TfSqolcTvbroNUSvKXot0WuLXkf0uqLXE72+6A1E/130hqI3Er2x6E1Ebyp6M9Gbi95C9JaitxK9tehtRG8rejvR24veQfSOoncSvbPoXUTvKno30buL3kP0nqL3Er236H1E7yt6P9H7iz5A9IGiDxJ9sOhDRB8q+jDRh4s+QvSRoo8SfbToY0QfK/o40ceLPkH0iaJPEn2y6FNEnyr6NNGniz5D9JmizxJ9tuhzRJ8r+jzR54u+QPSFov8h+p+iLxJ9sehLRF8q+jLRl4u+QvS/RF8p+irRV4u+RvS1oq8Tfb3oG0TfKPom0TeLvkX0raJvE3276DtE/1v0naLvEn236HtE3yv6PtH3i35A9IOiHxL9sOhHRP9H9KOiHxP9uOgnRD8p+inRT4t+RvSzop8T/bzoF0S/KPol0S+LfkX0q6JfE/266DdEvyn6LdFvi35H9Lui3xP9vugPRH8o+iPRH4v+RPSnoj8T/bnoL0R/Kfor0V+L/kb0t6K/E/296B9E/yj6J9E/K/2/v/npoocQPVj0kKKHEj206GFEDyt6ONHDix5B9IiiRxI9suhRRI8qejTRo4v+jegxRI8peizRY4seR/S4oscTPb7oCURPKHoi0ROLnkT0pKInEz256ClETyl6KtFTi/6t6GlE/070tKJ/L3o60dOL/oPoGUTPKHom0TOLnkX0rKJnEz276DlEzyl6LtFzi55H9Lyi5xM9v+gFRP9R9IKiFxK9sOhFRC8qejHRi4teQvSSopcSvbToZUQvK3o50cuLXkH0iqL/JPrPolcS/RfRK4v+q+hVRP9N9KqiVxO9uug1RK8pei3Ra4teR/S6otcTvb7oDUT/XfSGojcSvbHoTURvKnoz0ZuL3kL0lqK3Er216G1Ebyt6O9Hbi95B9I6idxK9s+hdRO8qejfRu4veQ/SeovcSvbfofUTvK3o/0fuLPkD0gaIPEn2w6ENEHyr6MNGHiz5C9JGijxJ9tOhjRB8r+jjRx4s+QfSJok8SfbLoU0SfKvo00aeLPkP0maLPEn226HNEnyv6PNHni75A9IWi/yH6n6IvEn2x6EtEXyr6MtGXi75C9L9EXyn6KtFXi75G9LWirxN9vegbRN8o+ibRN4u+RfStom8TfbvoO0T/W/Sdou8Sfbfoe0TfK/o+0feLfkD0g6IfEv2w6EdE/0f0o6IfE/246CdEPyn6KdFPi35G9LOinxP9vOgXRL8o+iXRL4t+RfSrol8T/broN0S/Kfot0W+Lfkf0u6LfE/2+6A9Efyj6I9Efi/5E9KeiPxP9uegvRH8p+ivRX4v+RvS3or8T/b3oH0T/KPon0T9rYND/AOaSEScAAHicY2BiAAKmPSy+QEqUgYFRUURcTFzMyNzM3MxEXU1dTYmdjZ2NccK/K5oaLm6L3Fw0NOEMZoVAFD6IAQD4PA9iAAAAeJxjYGRgYADirq+zjOP5bb4ycLNfAIowXCttkUWmmfaw+AIpDgYmEA8ANPUJwQAAeJxjYGRgYL/AAATMCiCSaQ8DIwMqYAIAK/QBvQAAAAADIAAAAAAAAAAoAAB4nGNgZGBgYGIQA2IGMIuBgQsIGRj+g/kMAArUATEAAHicjY69TsMwFIWP+4doJYSKhMTmoUJIqOnPWIm1ZWDq0IEtTZw2VRpHjlu1D8A7MPMczAw8DM/AifFEl9qS9d1zzr3XAK7xBYHqCHTdW50aLlj9cZ1057lBfvTcRAdPnlvUnz23mXj13MEN3jhBNC6p9PDuuYYrfHquU//23CD/eG7iVnQ9t9ATD57bWIgXzx3ciw+rDrZfqmhnUnvsx2kZzdVql4Xm1DhVFsqUqc7lKBiemjOVKxNaFcvlUZb71djaRCZGb+VU51ZlmZaF0RsV2WBtbTEZDBKvB5HewkLhwLePkhRhB4OU9ZFKTCqpzems6GQI6Z7TcU5mQceQUmjkkBghwPCszhmd3HWHLh+ze8mEpLvnT8dULRLWCTMaW9LUbanSGa+mUjhv47ZY7l67rgITDHiTf/mAKU76BTuXfk8AAHicY2BigAARBuyAiZGJkZmBJSWzOJmBAQALQwHHAAAA) format("woff"); } .myPassword { font-family: password-font; }

<input type='text' autocomplete="off" class="myPassword" />

It seems in the later versions of Chrome, they have decided to ignore autocomplete="off" for passwords... See:

https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/zhhj7hCip5c/PxbtDtGbkV0J

Here's another person answering this question with a hacky solution you might be able to try, if it's a project requirement:

Chrome Browser Ignoring AutoComplete=Off

I found a way to make Chrome ignore password/username combination even they all in that name.

<input name='username' type='text'> <input name='password' type='password' onblur='this.type="password"' onfocus='this.type="text"'> 

The keypoint is to set onblur and onfocus with type change.

You can do it also by:

$('input[name="password"]').blur(function(){ $(this).attr('type', 'password') }) $('input[name="password"]').focus(function(){ $(this).attr('type', 'text') }) 

Don't know why. I guess it's a bug.

I fixed with the following markup

#txtPassword { -webkit-text-security: disc; }

<form autocomplete="off"> <input type="text" name="id" autocomplete="off"/> <input type="password" id="prevent_autofill" autocomplete="off" style="display:none" tabindex="-1" /> <input type="password" name="password" id="txtPassword" autocomplete="off"/> <button type="submit" class="login100-form-btn">Login</button> </form>