427

When using the xhtml1-transitional.dtd doctype, collecting a credit card number with the following HTML

<input type="text" id="cardNumber" name="cardNumber" autocomplete='off'/>

will flag a warning on the W3C validator:

there is no attribute "autocomplete".

Is there a W3C / standards way to disable browser auto-complete on sensitive fields in a form?

Kos
  • 3,847
  • 8
  • 29
  • 34
matt b
  • 132,562
  • 64
  • 267
  • 334
  • 10
    Are you sure that messing with the user's autocomplete setting is what you want to do? If they have it turned on, they probably like it. Autocomplete is a completely browser-side feature, much like the button that allows the user to change font size, etc. You shouldn't interfere with their wishes – rmeador Feb 24 '09 at 16:25
  • 113
    Even for something as sensitive as Credit card number? I can't think of very many people who would want that remembered - especially since auto-complete is on by default in most browsers. If they want it remembered that bad, they can use something that fills out forms like Google toolbar. – matt b Feb 24 '09 at 19:16
  • 13
    My use case is slightly different - I am rolling my own autocomplete and I don't want it to clash with the browser's. I only just discovered that autocomplete="off" is invalid, but it seems there's no other simple solution (injecting it with js is just silly) – thepeer Feb 11 '10 at 17:27
  • 13
    @rmeador because sometimes we want to provide a more user-friendly alternative to the standard auto-suggest box. @corydoras please don't push your OSX weight around, it's not helpful to the resolution of this question. – Josh M. Mar 07 '11 at 21:54
  • 1
    I need to turn it off in situations where I use OTP generated passwords from tokens in my forms. This number is never the same and autocomplete is totally unneeded there... – ante.sabo Sep 04 '11 at 23:26
  • 12
    The problem is that the banks will hold the merchant liable if a fraudulent transaction took place... even if its the customer's fault at 100%. Therefore, in some circumstances, it is legitimate to disable the feature for the customer. – Anon21 Oct 23 '11 at 18:52
  • 7
    @rmeador The problem that led me to this question was that I have an admin interface to change someones password, but my browser is auto-filling the 'new password' field with my password, which is obviously not what I want. – rjmunro Dec 15 '11 at 10:26
  • 1
    It is not working on firefox 6. I tried setting `autocomplete=off` for form and also for the input fields but none of them seem to work. Though it works for the first input of the form, doesn't work for the second input of the same form – Sadiksha Gautam Sep 23 '11 at 06:29
  • 3
    HTML 5 autocomplete atrribute: http://www.w3schools.com/html5/att_form_autocomplete.asp – Alfredo Osorio Jun 13 '11 at 16:43
  • 1
    @AlexandreH.Tremblay It is never legitimate, period. The reckless behavior of bank is another issue. – curiousguy Sep 14 '13 at 11:11
  • 3
    @curiousguy your comment is wrong. It is legitimate whenever there is a business need for it. You can't possibly think about all use cases of an html element. My client for example is specifically requesting to disable it for certain fields of his intranet as it doesn't make sense there (the text is always different by definition on those fields). – Durden81 Mar 16 '14 at 22:07
  • 1
    @Durden81 I do agree that it is a nice to disable history/autofill for a CAPTCHA form field, as by definition value don't repeat. Nice to have for the user, as the feature is pure distraction, but not necessary in any way (the user can ignore the history) and not having the `autocomplete=off` option it is not harmful for security. – curiousguy Mar 17 '14 at 00:19
  • 4
    @curiousguy it can be harmful for security in the case where multiple users are sharing the same computer in a small office. Consider the case where an eye doctor has one computer in the office and web based practice management software. The receptionist who also uses the computer shouldn't get the option to login to the practice management software with the doctors credentials. That would be wrong and also could be a HIPAA violation. Of course they shouldn't be using the same account at the OS level but this is the real world. – schmidlop Mar 18 '14 at 20:17
  • It's ridiculous that this is even a discussion. I'm building a form that requires entry of address info for clients around the country. When I start typing my own state name, the browser "helpfully" suggests my complete address history (including alternate shipping addresses I've used in Amazon), instead of the js-based typeahead suggestion of, you know, the NAME of the state. Why is it even a question which makes more sense? – Brian Moeskau Mar 12 '15 at 20:01

18 Answers18

424

Here is a good article from the MDC which explains the problems (and solutions) to form autocompletion. Microsoft has published something similar here, as well.

To be honest, if this is something important to your users, 'breaking' standards in this way seems appropriate. For example, Amazon uses the 'autocomplete' attribute quite a bit, and it seems to work well.

If you want to remove the warning entirely, you can use JavaScript to apply the attribute to browsers that support it (IE and Firefox are the important browsers) using someForm.setAttribute( "autocomplete", "off" ); someFormElm.setAttribute( "autocomplete", "off" );

Finally, if your site is using HTTPS, IE automatically turns off autocompletion (as do some other browsers, as far as I know).

Update

As this answer still gets quite a few upvotes, I just wanted to point out that in HTML5, you can use the 'autocomplete' attribute on your form element. See the documentation on W3C for it.

Community
  • 1
  • 1
Nick Presta
  • 26,924
  • 6
  • 51
  • 73
  • 41
    Looks like Firefox doesn't turn off autocomplete on https, but that's a useful piece of knowledge. Thanks! – matt b Feb 24 '09 at 16:17
  • 3
    Safari does not respect the autocomplete="off" attribute. See http://stackoverflow.com/questions/22817801/how-to-disable-auto-fill-in-safari-7 – Skurpi Jun 09 '14 at 14:01
  • 1
    `autocomplete` may be used [not only on `form` element](http://www.w3.org/TR/html5/forms.html#attr-fe-autocomplete), and `off` value works at least in `chromium-40.0.2214.115` – x-yuri Mar 03 '15 at 21:29
  • The w3c seems to be expanding the standards for autocomplete in HTML5.1 (in draft as of this comment) http://w3c.github.io/html/single-page.html#autofilling-form-controls-the-autocomplete-attribute – Justin Nafe Apr 19 '16 at 17:23
  • 1
    If nothing works, Use textarea instead of textbox to turn off autocomplete. – Bsienn May 11 '16 at 12:56
64

I would be very surprised if W3C would have proposed a way that would work with (X)HTML4. The autocomplete feature is entirely browser-based, and was introduced during the last years (well after the HTML4 standard was written).

Wouldn't be surprised if HTML5 would have one, though.

Edit: As I thought, HTML5 does have that feature. To define your page as HTML5, use the following doctype (i.e: put this as the very first text in your source code). Note that not all browsers support this standard, as it's still in draft-form.

<!DOCTYPE html>
BlaM
  • 26,721
  • 31
  • 89
  • 104
Henrik Paul
  • 63,711
  • 30
  • 82
  • 93
  • 7
    All browsers expect older versions of Konqueror support it. Even IE6 supports it. It's the doctype to go. – BalusC Aug 10 '10 at 16:48
58

HTML 4: No

HTML 5: Yes

The autocomplete attribute is an enumerated attribute. The attribute has two states. The on keyword maps to the on state, and the off keyword maps to the off state. The attribute may also be omitted. The missing value default is the on state. The off state indicates that by default, form controls in the form will have their autofill field name set to off; the on state indicates that by default, form controls in the form will have their autofill field name set to "on".

Reference: W3

driconmax
  • 895
  • 1
  • 15
  • 25
RuudKok
  • 5,217
  • 2
  • 23
  • 26
32

No, but browser auto-complete is often triggered by the field having the same name attribute as fields that were previously filled out. If you could rig up a clever way to have a randomized field name, autocomplete wouldn't be able to pull any previously entered values for the field.

If you were to give an input field a name like "email_<?= randomNumber() ?>", and then have the script that receives this data loop through the POST or GET variables looking for something matching the pattern "email_[some number]", you could pull this off, and this would have (practically) guaranteed success, regardless of browser.

Phantom Watson
  • 2,568
  • 2
  • 22
  • 36
  • 6
    This would make automatic testing harder. – David Waters Feb 24 '09 at 16:16
  • 14
    Would make automatic testing harder, only if your testing software cant cope check for / read fields that might have a random number appended to them. Might be time to upgrade your automated testing software. – corydoras Nov 23 '09 at 06:15
  • 8
    The autocomplete info would still be saved in the browser's data directory, would it not? – Joey Adams Jan 03 '11 at 21:39
  • 2
    Presumably. But it wouldn't be expected to ever actually appear again to the user. – Phantom Watson Jan 05 '11 at 17:25
  • 1
    Chrome now uses the type="password" attribute rather than the name attribute for a particular site. I have name="newpassword" autocomplete='off' type="password" and it gets autofilled! If I change the type, no autofill – Enigma Plus Apr 28 '14 at 14:57
  • To remove autocomplete and enable automated testing use a random value for `name` and put the name in a `data-*` attribute. – Jankapunkt Dec 10 '19 at 12:42
31

No, a good article is here in Mozila Wiki.

I would continue to use the invalid attribute. I think this is where pragmatism should win over validating.

atiquratik
  • 1,154
  • 3
  • 22
  • 30
David Waters
  • 11,581
  • 7
  • 37
  • 74
23

How about setting it with JavaScript?

var e = document.getElementById('cardNumber');
e.autocomplete = 'off'; // Maybe should be false

It's not perfect, but your HTML will be valid.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Greg
  • 295,929
  • 52
  • 357
  • 326
  • 8
    Using javascript as a workaround to validation errors is like sweeping dust under the rug. While the HTML document may become valid, the resulting HTML+JS page will not be. – fregante Sep 03 '12 at 01:43
19

I suggest catching all 4 types of input:

$('form,input,select,textarea').attr("autocomplete", "off");

Reference:

Raptor
  • 48,613
  • 43
  • 209
  • 344
Malartre
  • 1,136
  • 1
  • 10
  • 8
11

If you use jQuery, you can do something like that :

$(document).ready(function(){$("input.autocompleteOff").attr("autocomplete","off");});

and use the autocompleteOff class where you want :

<input type="text" name="fieldName" id="fieldId" class="firstCSSClass otherCSSClass autocompleteOff" />

If you want ALL your input to be autocomplete=off, you can simply use that :

$(document).ready(function(){$("input").attr("autocomplete","off");});
Raptor
  • 48,613
  • 43
  • 209
  • 344
Totoche
  • 119
  • 1
  • 2
  • 4
    Just using HTML5 doctype is easier and better. – BalusC Aug 10 '10 at 16:46
  • 5
    this isn't really valid html anyway, it's just setting the (invalid) `autocomplete` attribute in a different way other than in the html – matt b Aug 10 '10 at 20:35
  • This code doesn't work for me; I've used `$('input.autocompleteOff').val('');` which seems to be OK. – dqd Aug 31 '11 at 11:50
  • 5
    Using javascript as a workaround to validation errors is like sweeping dust under the rug. While the HTML document may become valid, the resulting HTML+JS page will not be. – fregante Sep 03 '12 at 01:44
8

Another way - which will also help with security is to call the input box something different every time you display it: just like a captha. That way, the session can read the one-time only input and Auto-Complete has nothing to go on.

Just a point regarding rmeador's question of whether you should be interfering with the browser experience: We develop Contact Management & CRM systems, and when you are typing other people's data into a form you don't want it constantly suggesting your own details.

This works for our needs, but then we have the luxury of telling users to get a decent browser:)

autocomplete='off' 
Enigma Plus
  • 1,316
  • 17
  • 28
8

autocomplete="off" this should fix the issue for all modern browsers.

<form name="form1" id="form1" method="post" autocomplete="off"
   action="http://www.example.com/form.cgi">
  [...]
</form>

In current versions of Gecko browsers, the autocomplete attribute works perfectly. For earlier versions, going back to Netscape 6.2, it worked with the exception for forms with "Address" and "Name"

Update

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 forcing the no-autocompletion is to assign a random string to the attribute, for example:

autocomplete="nope"

Since this random value is not a valid one, the browser will give up.

Documetation

Emilio Gort
  • 3,382
  • 2
  • 27
  • 43
6

Using a random 'name' attribute works for me.

I reset the name attribute when sending the form so you can still access it by name when the form is sent. (using the id attribute to store the name)

opznhaarlems
  • 61
  • 1
  • 1
5

Note that there's some confusion about location of the autocomplete attribute. It can be applied either to the whole FORM tag or to individual INPUT tags, and this wasn't really standardized before HTML5 (that explicitly allows both locations). Older docs most notably this Mozilla article only mentions FORM tag. At the same time some security scanners will only look for autocomplete in INPUT tag and complain if it's missing (even if it is in the parent FORM). A more detailed analysis of this mess is posted here: Confusion over AUTOCOMPLETE=OFF attributes in HTML forms.

kravietz
  • 8,571
  • 1
  • 30
  • 24
3

Not ideal, but you could change the id and name of the textbox each time you render it - you'd have to track it server side too so you could get the data out.

Not sure if this will work or not, was just a thought.

Kieron
  • 24,968
  • 14
  • 72
  • 113
2
if (document.getElementsByTagName) {
    var inputElements = document.getElementsByTagName("input");
    for (i=0; inputElements[i]; i++) {
        if (inputElements[i].className && (inputElements[i].className.indexOf("disableAutoComplete") != -1)) {
            inputElements[i].setAttribute("autocomplete","off");
        }
    }
}
Tomer Cohen
  • 376
  • 5
  • 12
Jack
  • 1,790
  • 1
  • 17
  • 26
2

I think there's a simpler way. Create a hidden input with a random name (via javascript) and set the username to that. Repeat with the password. This way your backend script knows exactly what the appropriate field name is, while keeping autocomplete in the dark.

I'm probably wrong, but it's just an idea.

Snakes and Coffee
  • 8,255
  • 2
  • 35
  • 60
0

I MADE THIS WORK IN 2020!

I basically create a css class that applies -webkit-text-security to my inputs.

Here's the link to a more recent discussion: https://stackoverflow.com/a/64471795/8754782

Thales Kenne
  • 1,765
  • 6
  • 20
-1

This solution works with me:

$('form,input,select,textarea').attr("autocomplete", "nope");

if you want use autofill in this region: add autocomplete="false" in element ex:

<input id="search" name="search" type="text" placeholder="Name or Code" autcomplete="false">
Laura
  • 5,088
  • 3
  • 26
  • 37
Hưng Trịnh
  • 555
  • 8
  • 18
-5

Valid autocomplete off

<script type="text/javascript">
    /* <![CDATA[ */
    document.write('<input type="text" id="cardNumber" name="cardNumber" autocom'+'plete="off"/>');
    /* ]]> */ 
</script>
  • 13
    surely if a user had JS switched off though, they can't complete an order as they can't enter their card number? Better to supplement the attribute via JS I'd say - worst case, JS off gives the card number field with the potential for auto-complete, but at least they can place an order... just a thought :) – Terry_Brown May 19 '10 at 11:25