Prevent Chrome from prompting to save password from input box?

Question

Chrome was recently updated with an annoying popup that comes down from an icon in the address bar and prompts to save a password on the page when the user submits the form. There's no other input box on this page, and no other browser prompts to save this password, so I don't know why Chrome does. It is a password, therefore it shouldn't be visible as plain text in the input box, but it's not a password that should ever be saved - it's not login credentials. It's actually quite important the user of the computer does not know this password - someone else must enter it in for them - so if the browser saves it that would be bad.

How can you prevent Chrome (and all browsers) from prompting to save this password?

<form action="/..." method="post" onsubmit="return pwFormIsSubmittable();">
    <p>Password: <input autofocus="" type="password" name="1409_password" style="width:100px" tabindex="1" autocomplete="off"></p>
    <div class="tabSubmitButtons">
        <input type="button" name="event=default" value="Cancel" onclick="window.location='...'" tabindex="3">");
        <input type="submit" value="Submit" onclick="submitForm();" tabindex="2">
        <input type="hidden" name="begin" value="Yes">
        <!-- couple other hidden inputs -->
    </div>
</form>

Dressing

Do not send the form directly, prevent the submit and use an AJAX request, or change the type of the input from "password" to "hidden" could work. – Drooff

#30029115 – Skivvy

Answer 1

One solution or workaround is to add <input type="password" style="display:none"/> above the real password input box. Chrome only tries to save the first password it finds and if it's blank it won't throw up the dialog to save it.

Dressing

This didn't work for me. But setting content to empty string before JS redirect worked. Of course if it's a form submit you can't do that – Our

It didn't work for me too. – Nuzzle

Answer 2

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

Winchester

Word to the wise: --webkit-* styles are available in Safari and chromium browsers (Chrome, Brave, Opera, Edge, etc.). This answer won't work for IE, FF, or other browsers that don't use Webkit or Blink engines. More info: #3468654 – Excruciate

Answer 3

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.

Journey

Sure, there's other situations to consider though. Consider students who can take an online exam on any computer (including their own) around the world with the supervision of a proctor. Only the proctor knows the password, the proctor inputs it to start the exam, and oh now the password is saved to their browser for the student to share with their classmates. Not good! – Dressing

@Joey That wouldn't happen, because the proctor would not click the "remember my password" button. – Journey

Riiiight. We can trust thousands of proctors to read the message and not click a button or hit the enter key, not even on accident. – Dressing

Let's put the security of online testing in trusting all human proctors will click the right button. – Dressing

@Joey I would suggest that the model is wrong. A proctor should not be typing his password on my computer. And that's the fault of the web-site designer, not the browser. – Journey

New usecase: I have a user administration page that is attempting to save+autocomplete password fields to my browser for the user I'm trying to admin... which obviously does not make sense. There are pages where you can input a password, but it is not actually our current user credentials... especially if it's just looking at the first text input field on the form which isn't even the user's username... .... – Recuperate

What about a case when I want to use a password input on a subpage of my site, and that password protects just this one subpage? This even isn't a password for the site, so browser prompting me to "update my password" is plain wrong. I have many subpages like this, each with own password. How to go about this? – Archaeological

@Archaeological The problem is you might try to turn off saving of those passwords. If you don't want your browser to save those passwords then use the group policy to disable your browser from saving those passwords (other users might not feel the same way). Your other alternative is to make them INPUT type="text" – Journey

@Ian Body thanks. I can't use group policy, I don't want to disable remembering passwords for the whole site, just one subpage. Especially that for an authenticated user browser wants to update the site-level password - which will end up with this user not being able to log in again using the stored credentials. If I am left with text input in this case then it is really disappointing - masking the password is a huge pain. – Archaeological

@Archaeological Then we're left with you having to answer the unsolvable problem: How to prevent a web-site from setting autocomplete=off without the user's consent. Because while you may not want to have the password auto-complete, i do. If the web-site really and truly is only something that you use, then i suggest setting the input to text rather than password. – Journey

@Ian Boyd It is not that I don't want it. If a user decides to remember that password on my special subpage he will ruin his site-level credentials - browser will overwrite the site-level password (browsers can't store multiple passwords per domain, similar question: productforums.google.com/forum/#!msg/chrome/4pMa3sDvqF8/…). So with this in mind I want to avoid my users ruining their credentials, but keep using masked password input - and here I need that autocomplete=off. Or I need browsers to start supporting multiple passwords per domain. – Archaeological

@Archaeological Now we're getting into design work. Why does one user have multiple passwords; you should grant access to these areas of the web-site based on their authorizations (i.e. Andy is allowed in here). If it's like UAC (i.e. the user doesn't have authorization and you want to use your credentials over the shoulder to let them access a sensitive area), then you need to log them out, and login as yourself, and click No to updating credentials. If it's one-time FOB thing that lets them in now, then that is plaintext. – Journey

@Ian Boyd Thanks, I felt this will go this way :) There was an option to continue comments in a separate chat - but I can't see it. Anyway - let's do some design work then: it is not like UAC, but more like a one-shot password (without a login/username) so that anyone who knows that password can access the subpage. Maybe I should call it an "access code". But why would it be plain text? Can you also explain what you mean by "FOB thing"? – Archaeological

@Archaeological A FOB is one of those RSA token; a 6-digit number that rolls over every minute. In your case it sounds like it's not an access code that rolls over every minute; but is actually more like a single secret PIN. The point of making the input box plain text is that the browser won't offer to save a password when it's not a password field (it's a plain text field). That is, change input type=password to input type=text. – Journey

OTP (one-time password) fields another important use-case for password fields that should never be saved. Using a normal text field with -webkit-text-security to hide the characters using CSS is not enough, since it does not solve the problem where screen readers blab out blind users' OTPs. – Whey

@Whey Don't confuse your preference with the user's. You should be using a normal text field, with the text not hidden. That ways screen readers will blab out the blind user's OTP. – Journey

@IanBoyd My point was that OTP should not be spoken out loud or shown as text when entered. Just like passwords. That's why we have type="password", and not just CSS for password fields. – Whey

@Whey My point was that a one-time password is not a "password"; it was sent to me right there as an e-mail, or as a text message, or on a fob, or on the card that i received from the IRS. Passwords are secret and remain in my head. A OTP is not that - it's not secret. If it is, then it's a password, and should be saved. – Journey

It simply does not follow that "because it's a secret it should be saved". Nor is it true that OTPs are not secret. If they are not secret (at least until expiry), they are useless as a security measure. The fact that they have to be shown to the user in an email or such is mitigated by the fact that they have such a short expiry time. OTP authentication works on the premise that by the time the OTP leaks out, it will most probably have expired. – Whey

@Whey You're free to come up with a solution: as long as it does not prevent users from saving the OTP. – Journey

@IanBoyd if I'm not mistaken, you didn't respond to the point raised by Izzy regarding users who administer other users, including resetting their password. I have that situation now. The system will be used by a handful of users most of whom are not at all technical and many don't even have an email address, so password reset via a link in an email is not an option. I, as a developer, should be able to tell the browser not to offer to save these passwords as it is not at all helpful to me or to other admins. – Heydon

@Heydon I did; the very last picture; along with a latter comment reminding people to change the Reset Password text box to be input type=text. – Journey

@IanBoyd Fair enough, I was looking for a comment directed at Izzy. Anyway, I decided to go for a text input with class password and just use CSS to change it to discs. It's only a handful of users using the system as a whole - admin will likely just be me anyway but I find it frustrating to have to keep clicking "Nope" every time I edit a user profile. – Heydon

OMG! What a rant. Here is a scenario. The website has a login page where we do want to store credentials if needed. But there is also an area where the user enters a pin for a smart card. There is no username, but chrome still asks to store this. It just gets in the way. – Elliellicott

@PaulJohnson What happens if you change it to input type=text? – Journey

New use case: Single-page web app for an IOT device; the field contains the WPA passphrase for a wireless access point, which is NOT the password for the site. So you really do not want to save it. Not only do you override the password for the main site; you also save a password that the browser cannot ever use. – Morph

Legitimate use case: Chrome prompts for password save when you DETACH a password input. So the user clicks the cancel button in a react dialog, and gets prompted to save the password. – Morph

@RobinDavies What does it mean to "detach" an input box? – Journey

@Ian Boyd: detach: to remove it or one of it's parent elements from elements that are descendants of the document. A common enough operation in pretty much any HTML dialog implementation in a single-page web app. – Morph

@RobinDavies Can you post a minimal jsFiddle example? – Journey

Auto-fill passwords, no issues with that. But this has been a pain in the butt, when trying to create an administrator / one shot password forms, etc. Plenty of reasons not to save passwords in the browser. Fair enough ignoring autocomplete, but autocomplete="new-password", I mean that's been very specific, it's not like it's been done accidentally, so the IE11 not a bug argument doesn't wash here. Oh, and the What if I'm a special snowflake?, seems a bit insulting. Just to clarify, someone having a different POV is not a snowflake, ironically not accepting others is. – Aurel

@Aurel "But this has been a pain in the butt, when trying to create an administrator / one shot password forms" The solution for that case is easy: do not mark the input box as type=password. That way Chrome will not try to remember it. And since it's not really a password - it's safe to leave the input as cleartext as you enter the "password". – Journey

I think your not getting it at all,. Seen as you can't / won't understand the reasoning, I'll leave it at that. – Aurel

@Aurel It sounds like you are using an administrator page in order to (for example) create a user account or set/reset a user's password, and you don't want your browser to offer to remember the password that isn't yours, and would never be valid to have the browser ever auto-populate that password ever again. – Journey

Answer 4

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.

Morph

Answer 5

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>

Skivvy

Answer 6

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

Urinate

It doesn't seem that issue is directly relevant. It now ignores autocomplete (terrible behavior), but this question is how you can prevent it from prompting the user to save it and remember it - I'll add a screenshot. – Dressing

Answer 7

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.

Intenerate

Answer 8

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>

Brocatel

Why the same is not working in ASP.net MVC View or .CSHTML page? – Pyrophoric

This solution stopped working after browser upgrade. On one of the (may be few) versions it works. – Brocatel

Answer 9

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

Prepossessing

Answer 10

To stop Chrome from asking to save your passwords:

1. Click the Chrome menu 3 dots in the toolbar and choose Settings.
2. Click Autofill > Passwords.
3. Turn off “Offer to save passwords”.

Source : https://support.1password.com/disable-browser-password-manager/

Lenni

That's for your own browser, not for people on their own browsers using your website – Jacqulynjactation