March 7, 2007

Forcing Firefox to obey autocomplete="off" for password fields

This is a very old article. Again I should stress that the point of this trick is not to wipe out the saved password for login forms. I use it for registration forms and preferences pages that allow users to change their password.  In these cases, auto-filling the password can cause problems for the user.  This is not a security fix.

I have a new technique now which is much simpler.  Create a hidden “honeypot” password field at the top of your form. Browser auto-complete features will only fill in the first password field that they hit. So, by having a dummy password field at the top of your form, you can trick the browser into filling out that field instead of the real password field. It looks like this:

<!-- honeypot fields -->
<input type="text" style="display: none" id="fakeUsername" name="fakeUsername" value="" />
<input type="password" style="display: none" id="fakePassword" name="fakePassword" value="" />
<!-- real fields -->
<input type="text" id="username" value="" />
<input type="password" id="password" value="" />


Autocomplete is a nice feature which fills in common form fields automatically for the user. However, in some cases you don’t want this to happen.  Some examples could be an account management page where you don’t want the admin password to be auto-filled in when you are creating and managing accounts.  Another example is any site that has a “My Account” page with a field allowing you to change your password.  Auto-complete can accidentally fill in these fields because it thinks it is a login form.

IE uses a non-standard attribute (autocomplete=”off”) that can be added to an entire form or one specific input control. Besides the fact that this attribute will make your HTML markup fail compliance tests, Firefox seems to consider this tag merely a “suggestion” and will disregard it at times.

In particular, Firefox will *always* populate certain password fields. There is seemingly no way to tell Firefox not to fill in a field if it really wants to do so. This can be a very bad thing if you are dealing with a user preference page or something sensitive where you don’t want autocomplete to ever occur under any circumstance. Setting value=”” is equally worthless because Firefox seems to populate this value just after the page is rendered.

The following code however will work. The concept is basically to set a timeout a fraction of a second after the page loads which clears the password field. Technically Firefox still populates the field, however this script code removes it almost instantly. As an added bonus, because you are not using autocomplete=”off” your HTML markup should still validate. This code should be placed at the bottom of your page beneath your form.

// this brutally clears a password field in firefox
// compliments of
function clearPwBox()
if (document.getElementById)
var pw = document.getElementById('MyPasswordFieldName');
if (pw != null)
pw.value = '';
window.setTimeout("clearPwBox()", 100);

This code could probably be made more generic by enumerating through the form elements and searching for a certain class name. This way you could have one script and simply append a classname to any field that you don’t want auto-complete to occur. This technique is similar to one posted on Chris Holland’s blog. Chris’s solution, however, is aimed exclusively at the Wc3 compliance issue. As you can see in his code he adds the autocomplete=”off” attribute, which allows the page to validate properly, but doesn’t solve the Firefox/Password field issue.

If you have a more graceful solution and/or decide to flesh this idea out, please post a comment and I’ll provide a link to your site.

36 Comments on “Forcing Firefox to obey autocomplete="off" for password fields

March 29, 2007 at 11:13 am

Thanks, that’s useful. Cheers.

May 5, 2007 at 12:47 am

Here’s something similar using jQuery — wipe all of the password fields on the page at once.

$().ready(function(){setTimeout(“$(‘input[@type=password]’).attr(‘value’, ”);”, 100);});

May 9, 2007 at 11:01 pm

thanks charles – i like that, nice and clean. i bet that code could be fairly easily ported to some other frameworks too – for people already including prototype, yui, etc, it could save some code.

Arjan van Bentem
May 14, 2007 at 5:40 am

> Setting value=”” is equally worthless because Firefox seems
> to populate this value just after the page is rendered.

…well: if Firefox somehow knows about some saved passwords (like when stored previously when autocomplete was not yet used) then it might still populate the password when the user enters the username. So: wait until page is loaded, wait some more, enter the user name and hit tab: voila, the password is there…

By the way: some folks want Firefox to offer the user the option to ignore the autocomplete setting:


May 14, 2007 at 11:23 am

hey arjan, that is a good point. i would say that 99% of the time this problem happens to me is on a “preferences” type of page where the user has the option to reset their password. But leaving the field blank keeps the password unchanged. Typically the user cannot change their username, so that doesn’t happen in my case – but i can see it is another situation to be aware of. It might be worth putting an onchange event in the username field to set the password to empty string.

As for the bug report – I would be happier if they added a an option to actually obey autocomplete consistently! I think the people who want auto-complete ignored might be unpleasantly surprised when they start seeing firefox change settings and such for them in random web applications. For example, auto-filling in their real email address on a public forum preference page. he he!

Dave Cardwell
August 31, 2007 at 4:21 am

You don’t need the timeout if you’re using jQuery’s .ready() function:

jQuery(function($) { $(‘input:password’).val(”) });

Nick Sutherland
September 6, 2007 at 5:57 pm

Another alternative (workaround that works 100% without jQuery)

It seems as if FF is looking for type=”password” to trigger the autosave password troll to activate.

So, why not prevent the save of the password to begin with…

(very rough example…)

function hideFromPassTroll(formObj, keycode)

Nick Sutherland
September 6, 2007 at 5:59 pm


Nick Sutherland
September 6, 2007 at 6:00 pm

form id=”loginform” action=”post”
input type=”text” id=”username” onKeyDown=”hideFromPassTroll(this.form,event.keyCode);”
input type=”password” id=”field2″ onKeyDown=”hideFromPassTroll(this.form,event.keyCode);”
input type=”button” id=”submit” value=”submit”
input type=”hidden” id=”password”

September 6, 2007 at 6:38 pm

Hey Nick, That seems to be a good idea too – If i understand, you’re using a hidden field for the real password and the visible password input is cleared onSubmit so that Firefox never receives the password – thus never saves it.

I hadn’t heard the term “password troll” before, he he, is that your own term?!

Nick Sutherland
September 6, 2007 at 7:25 pm

yeah, I figured it sounded more accurate than “autocomplete feature”.

I spent a few hours today trying to figure out how to trick FF and that’s what I came up with… seems to work reliably, but will require another method to set the “type” attribute for IE since it doesn’t seem to support direct access to it like I’ve used. I personally like that this method prevents the save in the first place.

Any simpler methods of doing this I wonder?

Nick Sutherland
September 6, 2007 at 8:10 pm

Ok, the simplest method that I could figure out, for changing the “field2” type attribute of “password” to “text” is by killing off the entire “field2” input.

So I wrapped the “field2” HTML input element with a SPAN, then I modified things so that essentially:

formPassParentObj = document.getElementById(“field2″).parentNode;

should now work in almost any browser that can modify innerHTML… maybe… probably… *shrugs*

Sydney Web Design
November 3, 2008 at 2:35 am

Hi, thank you very much for this – it’s been a headache! :)

August 17, 2009 at 2:50 am

hi, here is my solution:

Steven Kuck
September 23, 2009 at 12:42 pm

This trick works with the latest (at time of post) FF, IE, Chrome, Safari, and Opera. It’s ugly, but it works: add a non-displayed password input that you ignore. It has to be the first “password” field in the form.
<input style=”display:none” type=”password” name=”foilautofill”/>

It shows up if the user disables page styles, but it does leave the other password fields unaltered by autofill.

November 15, 2011 at 11:52 am

thanks steven, your trick is neat.

Falk Hoppe
July 20, 2015 at 3:38 am

This solution is “beautiful” but sadly still no real solution. At least if you wish to increase the page security with forced autocomplete suppression. The PW field still is there and provides access to the saved user-pw for an attacker, sitting in front of the users PC

December 10, 2015 at 8:47 pm

That is true, I do say at the top of the article this is not a security feature. It’s really not even intended for login pages at all – but for admin pages where there may be a password fields for ANOTHER user who is NOT YOU! And you do not want your browser auto-filling that user with your own password. Sometimes there are other masked fields that are not even a password at all – an API Key, or just any private field. The browser doesn’t know this and just fills them in with your own password.

It seems I have difficulty explaining this properly, if someone knows a better way to explain it, I’m all ears!

It’s unfortunate that browser vendors don’t see any reason to allow a website to disable auto-complete, so we are stuck with hacks until they do.

Stephen Embree
November 23, 2009 at 9:54 am

Thanks Steven, your trick seems to work!

January 11, 2010 at 3:20 pm

Fantastic, thank you for that simple solution.

January 14, 2010 at 1:48 am

@Steven Kuck

Thats a neat little trick. How does it work?

January 19, 2010 at 9:03 pm

@Steven Kuck

Awesome! Just what I was looking for to solve several password troll headaches on our site.

Mikey Benny
March 4, 2010 at 11:25 am

Who are you to tell me I can’t save *my* password on *my own* computer?

This is a little bit of control-freakishness and nanny-complex if you ask me.

March 4, 2010 at 3:40 pm

Mikey Benny :
Who are you to tell me I can’t save *my* password on *my own* computer?
This is a little bit of control-freakishness and nanny-complex if you ask me.

haha. yea, these freaking nanny computer programmers are trying to control everything! stick it to the man!

seriously though, this post wasn’t geared towards end-users and it isn’t really meant for wiping your login form. for example a “change password” form – you clearly don’t want the browser to auto-fill the fields.

September 20, 2010 at 10:08 am

Again to Mikey Benny:
Who am I to tell you you can’t save your password? I’m somebody programming for an application that BY DESIGN will be running on SHARED computers, such as in an internet cafe, a school computer lab, etc etc (though these two are the most common).

So sometimes it really is important to prevent saving of passwords. No reason to be calling us nannies.

Steven Kuck:
This is the best solution in our situation. Thank you very much. Seems Firefox (others too, probably) will only try to auto-fill the FIRST password input, so that’s an excellent non-javascript/jquery, valid HTML solution.

March 8, 2010 at 11:27 am

Here is a Mootools version:


Now, I’m not sure if adding a domready or load event is necessary, so use your best judgment. I just happened to come across this site looking for something else.

January 21, 2013 at 7:10 am

this doesnt work for already stored passwords

March 6, 2013 at 10:09 pm

Look guys, when Firefox disregards the autocomplete=”off” tag, it is because the user has deliberately set it up to do so. Typically by downloading and enabling an add-on module specifically designed to do so, such as

Now, I am both a web developper and a web user, mind you. If, as a user, I choose deliberately to force storage of a password against a sites wishes, thats my problem and my reponsibility as a user. As a developper, I do not think that it is appropriate or even permissible to override such an override.

So much of this world’s misery is caused by people wanting to protect other people from themselves… Stop trying. You have no right

On the other hand, users using override have no grounds to complain, even to themselves, if their security is compromised.

It is about users being adults and web developpers treating them so.
With due respect…

March 7, 2013 at 12:31 am

Hey Daniel, thanks for being the third person to comment without actually reading even the first paragraph of the article – where I explain appropriate situations for doing this.

I didn’t write this to prevent people from saving their passwords – I wrote it for admin screens where you don’t want fields to get auto-filled, for various reasons. One being that you are not editing your own data and you don’t want to auto-fill some other user’s password with your own personal info.

June 11, 2013 at 2:33 am

yup, this code-snippet is clearly malicious to the user

June 15, 2013 at 1:59 am

At this point I can’t even tell who is joking anymore.

August 4, 2014 at 4:16 pm
Nancy Wichmann
December 8, 2015 at 8:00 am

The government requires that screen readers for blind users be able to acceptably navigate the page. Hidden fields have specific requirements and I don’t think this will meet them.

December 10, 2015 at 8:40 pm

I don’t think adding the addition of a hidden field would prevent any screen readers from functioning, though it may need to be named in such a way to help indicate that they can ignore this field. Forms tend to have a lot of hidden fields so I’d imagine those on a screen reader would be familiar with having to ignore internal and system hidden fields that are not really meant to be viewed or edited.

But as I have said many, many times on this post – this “trick” should only be used for a specific purpose of preventing a password field from being auto-filled. This is not to force people to re-enter passwords, it’s more likely on an account admin page where you do not want your OWN password auto-filling a field that is intended for you to manage SOMEONE ELSE’S password. I would think if you are an administrator working with a screen reader, you especially wouldn’t want your browser automatically putting your password into a form that was intended to edit another person’s account (customer, client, etc).

February 19, 2016 at 3:59 am

It really worked. Nice

April 6, 2016 at 5:19 pm

I wish I had the power to make this post have more “google juice” so that other programmers wouldn’t have to waste hours and gray hair like I did trying desperately to solve this problem. Thank you, Jason, for your solution.


Leave a Reply

Your email address will not be published. Required fields are marked *