Why do so many credit card forms ask for the expiry date using select boxes?

I'm busy building yet another credit card form for a website, and it occurred to me that quite a lot of sites ask for the expiry date value using select boxes (Ryanair and Amazon are two off the top of my head).

As far as I know the date is always displayed in the format "MM / YY" on the card, so what purpose does having the user select "06" or "06 - June" (or worse the other way around) from a select box rather than having them type it in? They have already typed in one 16 (or 19) digit number, so another 4 can't hurt.


I guess a lot of these are due to trying to restrict the user input and not wanting to have to do validation. So given something like jQuery Payment which restricts the user input, are there any advantages in using select boxes?

  • I would hypothesize that it's for security. Should the machine have some dodgy keylogging software surreptitiously installed it would be able to log what was typed in the fields, but can't do this for picking items from dropdowns. I believe that's why several banks request only X characters from your 'secret word' and make you input them from A-Z dropdowns rather that free-text.
    – JonW
    Commented Oct 21, 2013 at 14:25
  • 4
    @JonW Logging user clicks and what they clicked on is just as easy. Commented Oct 21, 2013 at 19:14
  • @Danny Varod Not really because if the scroll or window position varies a bit, your click logging becomes useless, also, I've seen systems in which they give you a virtual keyboard to click the letters/numbers but they are laid out in an random order
    – aleation
    Commented Oct 23, 2013 at 8:36
  • @aleation You can screen capture the image around the click area or use the Windows' handle to try and analyze the UI element and its content. The real reason is enforcing input from the range. If you have a combobox that lets you select text by typing e.g. type "05" to select value "05" then this doesn't limit fast keyboard only input (doesn't require moving hand off tab+alphanumeric to arrows). Commented Oct 23, 2013 at 10:15
  • Well the security could be just one of the reasons. I'm aware that you still can log the mouse but you have to recognize that is not as easy and usual as key logging. I've read somewhere that nothing is 100% secure, but adding measures lowers the chances of being trespassed, if not ... why don't we just skip the security?
    – aleation
    Commented Oct 23, 2013 at 11:10

5 Answers 5


You are making an assumption that everyone using the web are as computer-literate or technical experts as you. But as a UX designer you should also cater for those who are the complete opposite (and there's an accountable amount of them out there).

Selects put strict constraints on the input, by that reducing errors. Experts won't mind selects of this type as much as novices could hate input fields.

Consider supa-granny:

A photo of a grandmother

She looks cool, but her sight is short, only 3 cells are functional in her working memory, and she struggles with any technology that emerged after 1969. A computer keyboard looks to her like a cockpit; when you ask her to press the back button, she will reply "I can't reach my back love, but I'm pretty sure there's no button there. Now, where did I put my tea cup?". Select boxes are safe-heaven to her.

Just think of the amount of errors supa-granny can make on an input field:

  • type month instead of year.
  • type a year in the past for expiry date, or a year in the future for start date.
  • try to type letters instead of numbers.
  • skip the leading zero.
  • put 2013 where there's only place for 13.
  • try to enter the forward slash (including spending a minute finding it on the keyboard).
  • by the time she starts typing forget whether it's month before year or the other way around (placeholder's gone).

None of these will happen with select boxes.

The JQuery widget you present is super-cool (and it does handle most of these errors) but it has a few usability flaws I feel should be mentioned:

  • There's no feedback for wrong input (someone trying to press J for January).
  • It translates really badly on mobile devices - where you have to type in numbers on the numeric keyboard, instead of selecting from a pre-defined list.
  • Recent statistics shows that around 1.3% of people have javascript disabled.

The point is that constraints reduce errors. The price you pay is often in speed, and it is experts who pay this price. Ideally, an input as such should smartly allow both text input (neatly behaving like the widget you have shared), but also constrained selection for people like supa-granny.

  • I know it's not centrally related to your answer, but could you please site the "javascript disabled" statistic? Commented Oct 24, 2013 at 0:44
  • 2
    @supersam654 see this related question
    – Izhaki
    Commented Oct 24, 2013 at 9:01
  • And also: Browser statistics on JavaScript disabled
    – unor
    Commented Nov 2, 2013 at 12:28
  • 1
    Completely disagree with this response. Typing 4 digits, exactly the same way as represented on a credit card is far easier for many people than selecting an item from a drop-down list. People with dexterity problems can push a key on a keyboard easier than clicking something with a mouse. Consider also that credit cards do not indicate the month in words; they indicate it in numbers. Having to translate from a number to a month (oh, let's see, 08, oh that's August) is far more error prone than seeing 08 on a credit card and typing 07 and not noticing the error.
    – Bill Dagg
    Commented Nov 20, 2013 at 23:46
  • My answer does not mention easiness (although each method will have its pros and cons in this regard, which will also be context dependent). But the constraints to reduce error principle holds (and is actually a key principle in design). Your last point is valid, but can be solved by displaying months as 10 Oct.
    – Izhaki
    Commented Nov 21, 2013 at 2:02

There aren't really any disadvantages in using select elements for this purpose. select elements are simply a list of pre-defined and desired user input. If designed correctly a user with a keyboard wouldn't need to move their hands away from the keys as they should simply be able to tab into the select and type to select a value.

select elements asking for date input should always be in MM/YYYY format (unless otherwise clearly stated) and should always be in numerical order. This way if a user typed "199" they'd end up with "1990" instead of just "19" or any other year from 1991 to 1999 - this is something a user's browser should handle for them.

A select element should be used over a generic input element as users may be unsure what type of data the field is collecting. You'd potentially have to do extra validation to convert an input of "Jan", "January" or "1" to "01", and a pre-defined list of options would rule this out this extra requirement.

If you're unaware that you can type to select options within a select element, here is a JSFiddle example of a select element with options 01 through to 12.

  • Also, listing the month-name first in the MM dropdown means that September is a single S keystroke rather than nine zeros or 1+Up. But it should be clear from the outset that it is listed like that or typing digits is fruitless. Commented Oct 21, 2013 at 14:41
  • @AndrewLeach listing the months by name would just annoy users with an expiry month of July as "J" would select January and "Ju" would select June (and that's not necessarily something users would remember when quickly filling out a form). Not to mention that it would restrict the form's language to English. Commented Oct 21, 2013 at 14:43
  • Each to their own. I'm happy with JJJ for July rather than 0000000, provided that I know it's expecting letters rather than digits. Commented Oct 21, 2013 at 14:49
  • 1
    Why would you need to type "0000000"? If the option's text was "07" you'd simply type "07". This is default behaviour for most browsers. Commented Oct 21, 2013 at 14:51
  • 2
    No credit card actually prints the month in words on it. They all show XX/XX as the format. Changing that on the web frontend to convert it to Jul means the user has to do some cognitive work to translate what the number on their credit card means in words. This is an unnecessary mental overhead - if the card says 01/15 then they should be able to enter 01/15, not "January 2015, Jan 2015, Jan 15..."
    – JonW
    Commented Oct 21, 2013 at 14:59

the MAYA principle from design school states that the designer should choose the "Most Advanced Yet Acceptable" design solution. If you're boss has no understanding of the mechanics of UI design then your boss will only accept the most common solution as the best. So in a word "inertia" is the reason.

P.s. remember when every button at the bottom of a form said "submit" instead of "post your answer" or "add entry" or other more usable language?


You can also use the keyboard with select elements. So you have the advantage of not leaving the keyboard plus sanitized input data.

Also in international situations, the order of month/day is not consistent. I think that you see the select elements because they balance forced constraints with native accessibility features.

Hope my opinion is beneficial.

  • This is true but this has issues too (see my comment on @james-donnelly's answer). Commented Oct 23, 2013 at 14:34

Using the drop-downs gives the site the ability to control exactly what users can select, avoiding errors (like entering 201303 or 03twothousandandthirteen, etc).

Not to mention the mistakes users in other countries could potentially incur when using these sites!

By doing that, sites are actually helping users, and increasing the user satisfaction by not letting them make mistakes - is there a design category/definition for that type of UX approach?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.