Skip to main content

Autofill: What web devs should know, but don’t

By Jason Grigsby

Published on May 19th, 2016


Many people know that you can scan your credit card in Mobile Safari. But how many web developers know how to create a form that supports that feature?

Not many I’d bet.

Photo of someone scanning their credit card
Auto-Fill Credit Card Forms Using Your iPhone’s Camera in iOS 8. Used with permission.

It doesn’t help that Apple has provided zero documentation on how the scan credit card feature works.

But there is another factor at play here. The scan credit card feature is a subset of browser functionality that web developers have long ignored: autofill.

It’s understandable why web developers haven’t paid much attention to autofill. When you’re filling out forms with test data on a regular basis, autofill tends to get in the way.

But autofill is an important feature for our users. Google has found that “users complete forms up to 30% faster” when using autofill.

So let’s learn how autofill works, how to build forms that support cross browser autofill, and take advantage of new features like scanning credit cards.

Until recently, there were no standards when it came to autofill. Each browser implemented their autofill features differently and there was little documentation on how a browser determines what content a field expects.

Despite this chaotic situation, browsers seem to have settled on two main approaches:

Chrome, Opera and Safari have all taken the approach of identifying high-value form fields and providing a way to manage what the browser will autofill for those fields.

Opera Autofill Manager

For example, Opera provides autofill for addresses and credit cards. These can be managed in the preferences as shown above.

Chrome, Opera and Safari all differ on which fields they provide autofill for, but the basic fields needed to complete a checkout process are well supported.

Most users never have to see or edit these preferences in order to utilize autofill. The browser watches the person filling out forms and when it recognizes an address or a credit card, it will ask if the user wants them to save that information to reuse later.

If the previous approach is like a scalpel applied to preselected fields only, this second approach is a chainsaw cutting down every field in view.

When a form is submitted, Microsoft Edge and Firefox will store the value submitted along with the value of the name attribute. If the browser sees a field in the future with a matching name attribute, it will provide autofill options. Firefox also appears to look at the id in addition to the name attribute

Because there are security and privacy concerns with this approach, the autocomplete off value has long been supported to prevent the browser from storing and autofilling sensitive information.

While the second approach works for more fields, as a developer, I much prefer the pre-determined autofill fields approach.

It makes it much easier to figure out what information the browser has to autofill. It is also easier to set up test profiles.

Plus, with the second approach, you actually need to submit a form in order for the browser to store values to use with autofill. The browser won’t remember your answers without the form submission.

It also makes me nervous to think that the browser might store credit card information in a non-encrypted way if it can’t clearly identify the type of field.

Given how concerned Microsoft and Mozilla are about security and privacy, I’m certain they’ve put protections in place. But I personally feel more secure looking at an autofill preferences pane and seeing credit card information clearly separated and understood by the browser.

All that said, I don’t know what end users prefer. The second system works in more places, but I’ve seen quite a few support questions where people have been trying to remove their autofill options from the browser history.

It will be interesting to see how Edge and Firefox change when they began to support the new autofill standard.

Sometimes browsers require more than one field of a certain type before they will present you with autofill options.

For example, in the following animated GIF, Safari won’t offer to autofill the single cardholder field, but it will offer to autofill it once there is a second card number field.

Safari Autofill working with two fields, but not working with one field

However, if the only field being collected is the card number, then Safari will offer the autofill option.

My experience has been that creating isolated test cases for single fields can be challenging because of this behavior. At one point in my testing, I encountered Opera requiring three fields before it would autofill, but I can no longer recreate that behavior.

This should never be an issue for a user so long as your form is written to support autofill (more on this soon), but I note it here in case you’re attempting to troubleshoot autofill and encounter this behavior.

Thankfully, there is a way forward for autofill. HTML5 recently expanded the autocomplete attribute to provide hints to the browser about what content a field expects.

The autocomplete attribute has been around for several years. It started with two values: on and off. By default, the autocomplete attribute is set to on which means that the browser is free to store values submitted and to autofill them in the form.

However, some fields are poor candidates for autofill behavior. In that case, the autcomplete attribute can be set to off to tell the browser that this field should be not autofilled.

Recently, additional values have been added as options for the autocomplete attribute. These new options are called autofill detail tokens. These tokens tell the browser what information the field is looking for.

One type of token is called the autofill field names. The autofill field names tell the browser what type of information a field expects.

For example, one of the autofill field names is organization. The HTML5 specification says that organization refers to:

Company name corresponding to the person, address, or contact information in the other fields associated with this field

If you wanted to tell the browser to autofill the organization field, your code would look something like this:

<input type="text" name="foo" id="bar" autocomplete="organization">Code language: Bash (bash)

The HTML5 specification has a great table listing all 53 possible autofill field names, what their intended use is, and what type of input must be used with it.

That’s autocomplete at its simplest, but it gets more powerful and a bit more complex.

The value of the autocomplete attribute is actually a space-separated list of tokens. So for example, if you wanted to collect shipping information, you would prepend the autocomplete value with the “shipping” token like so:

<textarea name="shipping-address" autocomplete="shipping street-address"></textarea>
<input type="text" name="shipping-city" autocomplete="shipping address-level2">
<input type="text" name="shipping-state" autocomplete="shipping address-level1">
<input type="text" name="shipping-country" autocomplete="shipping country-name">
<input type="text" name="shipping-postal-code" autocomplete="shipping postal-code">Code language: HTML, XML (xml)

The billing token works exactly the same way as shipping.

Another token option applies to telephone, emails and instant messaging. For those services, there is an optional token to indicate if the autofill field name is referring to home, work, mobile, fax or pager.

For example:

<input type="tel" name="home-phone" autocomplete="home tel">
<input type="tel" name="work-phone" autocomplete="work tel">
<input type="email" name="home-email" autocomplete="home email">
<input type="url" name="chat" autocomplete="home impp">Code language: HTML, XML (xml)

The specification provides for both broad and narrow autofill field names for many of the types of information.

For example, in addition to the tel field which would be a single input containing a full telephone number, there are also:

  • tel-country-code
  • tel-national
  • tel-area-code
  • tel-local
  • tel-local-prefix
  • tel-local-suffix
  • tel-extension

The specification authors encourage you to use the broad autofill field names as often as possible:

Generally, authors are encouraged to use the broader fields rather than the narrower fields, as the narrower fields tend to expose Western biases. For example, while it is common in some Western cultures to have a given name and a family name, in that order (and thus often referred to as a first name and a surname), many cultures put the family name first and the given name second, and many others simply have one name (a mononym). Having a single field is therefore more flexible.

I agree with this recommendation. And as a practical matter, it means that it is important to pay attention to the table of values and make sure you’re using the right one for the field you’re working with.

The final feature of the new autocomplete attribute tokens is the ability to declare an arbitrary section to group fields.

A section is defined using a token that starts with section-. What comes after the dash is up to you. The specification provides this example of sections:

<legend>Ship the blue gift to...</legend>
<label> Address:
  <input name="bc" autocomplete="section-blue shipping street-address">
<label> City:
  <input name="bc" autocomplete="section-blue shipping address-level2">
<label> Postal Code:
  <input name="bp" autocomplete="section-blue shipping postal-code">

<legend>Ship the red gift to...</legend>
<label> Address:
<input name="ra" autocomplete="section-red shipping street-address">
<label> City:
<input name="rc" autocomplete="section-red shipping address-level2">
<label> Postal Code:
<input name="rp" autocomplete="section-red shipping postal-code"> </label>
</fieldset>Code language: HTML, XML (xml)

Put all together, we’ve now got a much more complex set of tokens for the autocomplete attribute. And the order of the tokens matters.

First, you’re either using on and off values OR you’re using autofill field names. You can’t use them at the same time.

If you’re using the autofill tokens, the order is:

[section-](optional) [shipping|billing](optional) [home|work|mobile|fax|pager](optional) [autofill field name]Code language: CSS (css)

And keep in mind that [home|work|mobile|fax|pager] only applies for the telephone, email and chat autofill field names.

The longest possible set autofill token might look something like this:

<label for="foo">Mobile phone for delivery</label>
<input type="text" name="foo" id="foo" autocomplete="section-red shipping mobile tel">
Code language: HTML, XML (xml)

I’m afraid not. My hope is that eventually all of the browsers will support the expanded autocomplete standard, but that’s not the current situation.

I tested browsers on mobile and desktop to see what attributes the autofill appeared to honor. This is what I found:

Browser Version OS ID Name Autocomplete
Chrome 50 OS X 10.11.4 No Yes Yes
Opera 35 OS X 10.11.4 No Yes Yes
Firefox 46 OS X 10.11.4 Yes Yes No
Edge 25 Windows 10 No Yes No
Safari 9.1 OS X 10.11.4 Partial Partial Partial
Safari 9 iOS 9.3.1 Partial Partial Partial

Thus far, only Chrome and Opera clearly support the new autocomplete features.

Safari appears to have partial support, but because they don’t have documentation, I can’t tell if this is intentional or simply a regular expression match that happens to be looking at the autocomplete attribute as well as name and other attributes.

Since the release of iOS 8’s credit card scanning feature, web developers have been reading tea leaves trying to divine what combination of markup Safari is looking for.

Some suggest that you have to have specific values in the name field. Others found values in ids work. Even labels seem to matter:

The Cardholder’s name is quite a bit more tricky. We messed around with various IDs for a long time and almost gave up. We couldn’t figure out an ID that would cause Card Scan to populate it. After much frustration we finally discovered that the TEXT of the label associated with the field matters. Setting the label text to “Name on card” was the magic trick.

I’ve done quite a bit of testing, and I’m still not confident that I understand fully what Safari is doing. However, I’ve seen enough to be able to draw some basic conclusions:

Safari recognizes the form I created that only includes autocomplete attributes. The moment I start typing in the first field, it offers to fill in the form with my contact information.

Safari offering to autofill my contact information on a form that only uses autocomplete attributes.

This all works as expected with a couple of caveats.

First, it is unclear what Safari is using to make decisions about what information to autofill from my contact in the Mac’s address book. My job title is filled in, but the company I work for isn’t.

Second, it doesn’t give users the option to select which information they want to use. My contact contains both my home address and my work address. Safari only wants to autofill my home address. I’m out of luck if I want to ship something to the office.

When it comes to the payment fields, Safari’s behavior changes completely. The autocomplete attribute is ignored.

Instead, there is some sort of magical heuristic that Safari is using. And because I’m not an Apple magician, it has been difficult to discern what Safari is actually doing:

Video of me struggling to figure out why some labels for payment fields work and some fail.

In the video above, I edit the labels of two fields. Both have autocomplete set as well as name and id which should help Safari identify the field.

And yet, Safari doesn’t recognize the fields until the labels are changed to Name on Card and Credit Card Number. As mentioned earlier, Safari needs to see more than one field to trigger autofill.

Then I try changing the label to CCNumber which continues to work. However, changing it to CC Number breaks the autofill.

Basically, Safari has an unpublished list of terms that it is searching for. Fortunately, Jacques Caron was able to extract a list of strings from the iOS Simulator that Safari appears to be looking for:

  • card number
  • cardnumber
  • cardnum
  • ccnum
  • ccnumber
  • cc num
  • creditcardnumber
  • credit card number
  • newcreditcardnumber
  • new credit card
  • creditcardno
  • credit card no
  • card#
  • card #
  • cvc2
  • cvv2
  • ccv2
  • security code
  • card verification
  • name on credit card
  • name on card
  • nameoncard
  • cardholder
  • card holder
  • name des karteninhabers
  • card type
  • cardtype
  • cc type
  • cctype
  • payment type
  • expiration date
  • expirationdate
  • expdate
  • month
  • date m
  • date mo
  • year
  • date y
  • date yr

In my experiments, both:

<input type="text" name="nameoncard">
<input type="text" name="ccnumber">Code language: HTML, XML (xml)


<label for="foo">Name on Card</label>
<input type="text" id="foo" name="foo">
<label for="bar">Credit Card Number</label>
<input type="text" id="bar" name="bar">Code language: HTML, XML (xml)

will trigger Safari’s autofill and the scan credit card feature on iOS. However, putting the same values into the autocomplete attribute will not work.

Given what we’ve learned, is it truly possible to build a form that supports autofill across browsers? I think it is.

Or at least, we can get very close by taking these four steps.

This is the future of autofill. Browsers that don’t recognize the values will ignore them.

This is progressive enhancement at its best.

To take advantage of autofill for Firefox and Edge users, you have to hope that the values you pick for the name attribute match what developers on other sites have used.

One way to do this would be to survey popular sites and see what they use and then use the same values.

Or perhaps use the same values as the autocomplete field in hopes that as more web developers become familiar with the standard that they will start using those names for their fields.

Unfortunately, there is no way to guarantee that your Firefox and Edge users will have previously visited a form that uses the same name values as your form does.

Using the list that Jacques Caron was able to extract, you can modify the values for the name attribute or the label to match what Safari expects.

Lately, I’ve been asking audiences to raise their hands if autofill is part of their test plans. No one does.

I’ve been working on the web since 1996, and I have yet to see autofill as part of the test plan.

I suspect that autofill is a blindspot for web developers and designers. Therefore, it is critical we test our products to ensure that they work well with autofill.

Here is a sample form that supports autofill on Chrome, Safari, Opera, Firefox and Edge:

See the Pen Cross Browser Autofill Form — Selected Fields by Jason Grigsby (@grigs) on CodePen.

To see it in action, you’ll need to view it on CodePen under https or the browser won’t fill in the credit card information.

I’ve also built a form with all 53 fields in the autocomplete specification. No browser currently supports all 53 fields.

There is a lot of movement from browser makers towards tackling the problem of web payments. The Payment Request API is being co-authored by Mozilla, Microsoft, Google and Facebook.

Apple is participating in the Web Payments Working Group which is where the Payment Request API is being hashed out. So it appears that Apple is at least nominally onboard with the Payment Request API.

Plus, rumor has it that Apple Pay will be available on mobile web for the holiday shopping season which makes it feel like this new momentum around web payments might be real this time.

This renewed focus on streamlining the web checkout process has me optimistic that support for autofill detail tokens will grow in the near term. And these tokens make creating forms that work with autofill so much simpler.

And most importantly, supporting autofill will make filling out forms less tedious for our users and lead to increased sales for e-commerce sites.


Jon Humphrey said:

Brilliant work Jason! Developing forms have always been a pet peeve of mine due to the inconsistencies across browsers in both display styling and applied attributes!

I hope you don’t mind but I’m going to fork your pens to keep for reference and hopefully others will do the same!

PS. I do find it slightly it slightly ironic that this comment form doesn’t support any of the prefills or the latest input types! ?

Francois Jordaan said:

Excellent article, thanks. I’ve shared it with the team here. Two questions:

Is autofill affected by attempts to improve the usability of credit card inputs using JavaScript? They separate the number into groups of 4 by inserting spaces, amongst other things. Stripe’s well-regarded payment form does this, and here’s a library for it: I’ve tested the latter on iOS and it does bring up the “Scan Credit Card” option.
You’ve not made any recommendations regarding HTML5 input type attributes, and in your example you have the credit card form as type=”text”. Shouldn’t we try to invoke the numeric soft keyboard? Using type=”number” accomplishes this, although you may also need ‘step’ and ‘pattern’ attributes

Šime Vidas said:

From what I’ve read about the upcoming Web Payment APIs, the key idea will be frictionless payments, meaning that forms and autofill will not be part of the process. Instead, the user will have payment apps (digital wallets) installed on their system, and the browser will act as an intermediary, which connects web apps to these wallet apps.

An example: A web app presents the user with a “Buy” button; when the user presses that button, the web app tells the browser which payment methods are supported; then, the browser checks which payment apps the user has installed on their system and if there’s a match, presents the users with the appropriate dialog; the user chooses a payment method and confirms the payment. So, all in all, the frictionless payment involves about 3 taps on a touch device (or 2 taps + touch sensor).

Replies to Šime Vidas

Jason Grigsby (Article Author ) replied:

Correct. My optimism about Payment Request API and what it might mean for autofill is because the the browser makers are focusing their attention on reducing friction on filling out forms. I was in a session today at Google I/O where the subject was the Payment Request API, and they led off talking about autofill. So even if they aren’t directly related, they seem to be related when browser makers talk about forms and checkout.

Martin Spierings said:

So what if you translate the field names. Will Safari then not apply autofill?

Ben Boyle said:

Very cool! Reminds me of when I had to use ‘city’ in name attribute (it’s more common to say “Town or suburb” here) when I discovered addresses only partially autofilling. The other gotcha I’ve seen a few times is websites that tie all their validation detection to keyboard or change events and flag filled fields as being incomplete… Autofill definitely needs to be on the form developers checklist, thanks for the brilliant article to refer people to! 🙂

zigotica said:

Nice article, thank you.

It would be nice to explain that Safari will not use maxlength restriction when autofilling.

So, for instance, if email field has maxlength=10 and autofilled email data is > 10 characters, Safari will use it regardless of maxlength. This is a very old bug (as old as Safari 4). I haven’t seen this described in either, where it actually states it is fixed from version 5.1 onwards.


Duke Vukadinovic said:

Online shopping is of major interest for Apple, with many studies revealing that the iPhone and iPad are winning this particular battle and I really liked how you said in conclusion that supporting autofill will definitely make filling out forms less tedious for our users.

Benxamin said:

FYI: Just got back a security audit from a major financial company and autocomplete=”off” is the only acceptable value for B2B software.

ivan said:

The Autofill spec is very interesting and it’s a pity that Firefox still doesn’t support it like Chrome and Opera.

My biggest concern is about the credit card number and its data. It’s true that the browser saves it safely, but many times it happens that a browser is shared by multiple people like in an internet point, hotel, friends or others. If the browser saves that data (like Firefox and IE) without asking and later shows the previous data, another person could see and retrieve those information without the knowledge of the first user.

This is a huge security and privacy problem, which is making me thinking if I should really set the autocomplete=”cc-number” instead of autocomplete=”off”, and also for the cvc/csc, which is also supported by the spec but for example the Stripe’s guys suggest to not use it (

What are your thoughts about this?

Replies to ivan

Jason Grigsby (Article Author ) replied:

As mentioned in the article, I strongly prefer the Chrome, Opera and Safari method of autofill where they recognize the types of fields and only store the sensitive information after prompting the user and asking if they want to store the information.

I’m optimistic that Microsoft and Mozilla will change their implementations.

Replies to Jason Grigsby
ivan replied:

Sure, but until then – and after most of users of old versions have migrated to a newer version – it shouldn’t be suggested to use the autocomplete (ie. autocomplete=”off”), otherwise more or less half of users would risk that privacy/security problem, don’t you think?

Replies to ivan
Jason Grigsby (Article Author ) replied:

More or less half of users is quite a jump from the number of computers in internet cafes and other public locations. I can’t fix everyone’s site so the real onus is on the browser makers and the owners of cafes to make sure people can use shared computers in a safe way.

Whether or not one single site uses autocomplete isn’t going to make someone using a cafe more secure.

But that’s just my opinion, others have to decide for themselves. And everyone should put pressure on Microsoft and Mozilla to change the way they handle autofill.

jasper said:

Just had to check for the autofill on your comment box 😀 . Preaching without doing it yourself would be weird wouldnt it be? :). I agree totally on this point . Auto fill is so much handy, and wondering when it would be going to mobile devices as well. As the typing on that kind of keyboard is so wonky. And “handy” .

Replies to jasper

Jason Grigsby (Article Author ) replied:

Yes, the WordPress comment box doesn’t support autofill by default and we haven’t modified it. We’re in the midst of a public redesign so our energy is on the new site, not fixing things on the old site.

I also cannot vouch to whether we’ll fix the comment form on the new site or not immediately. But it will happen eventually.

Regarding autofill on mobile, it does work. At least in Chrome and Safari. I can’t remember if I tested Firefox or Opera on mobile, but I would be stunned if it behaved differently. All of my Microsoft Edge testing was done on a Surface so depending on your definition of mobile, that may count as well.

Max Chadwick said:

Thanks for this. My company mainly builds and maintains Magento sites, so I’m going to share it with my team. While mainly relevant to the front end devs I think this is required reading for all.

Some of this stuff seems like a nightmare (apples black box, no standard for input names) but it’s important we do the best we can.

Galia said:

Autofill is bad to begin with – a malicious website could have invisible fields that’d collect too much information on you.
Want to post your name only? An invisible field named address and one named phone could be filled by autofill, it not knowing that these are not fields you wanted to fill.

Steve said:


FYI the CodePen example fails for Chrome on iOS (v51, June 2016). YMMV!


Francisc said:

Thanks for posting.

I have two questions after reading it.
Do label elements need to use the for attribute in combination with an id on the input element or does nesting the input inside the label work the same? So:

<span>Name on card</span>
<input type="text" .../>

And does hiding labels in various ways (display:none, large text-indent, opacity etc) hinder autocomplete from happening?

Of course, I could test all this, but maybe you already did. 🙂

Replies to Francisc

Jason Grigsby (Article Author ) replied:

Do label elements need to use the for attribute in combination with an id on the input element or does nesting the input inside the label work the same?

Nesting works

And does hiding labels in various ways (display:none, large text-indent, opacity etc) hinder autocomplete from happening?

I didn’t test this. FWIW, the autocomplete spec explicitly talks about when an input is hidden how autocomplete changes to “wear” the autofill anchor mantle. There is an example in the documentation on how the autofill anchor mantle might be used by a user agent.

But as noted above, not every browser supports the spec, and even if they support the spec, it is far cry between reading the docs and testing the behavior which I haven’t done yet.

If you test it, let us know!

Alejandro said:

Thanks for the article. Today I learnt something new and very useful. I’m just trying to do some examples to see it working and I’m only trying with a unique input field to write the username, but after submit the form I do not see any option to autofill.

<form class="" action="" method="post">
<label for="name">Name</label>
<input type="text" id="name" name="name" autocomplete="name">
<input type="submit" value="Submit!">

bty890 said:

OK, so what can’t I find any information to personally verify my auto-complete in Microsoft Edge prior to using?! I have been searching, searching, searching for how to do this! Chrome makes is so easy! Microsoft is so into collecting personal information they forgot about actually using their product! Thanks!