What is the optimal default value for a credit card expiration date? The only value I've ever noticed in practice is either the current month or the earliest possible month (January 1900 or similar).

enter image description here

  • 54
    Why have a value at all? It will almost never be correct.
    – Matt Obee
    Feb 25 '15 at 15:08
  • 15
    The earliest possible month is the current month. If a card expires in January 1900, it's not useable anymore. Feb 25 '15 at 19:45
  • 5
    I hate it when forms prefill in the expiration date. It's useless and can introduce more work for a user.
    – jamesdlin
    Feb 25 '15 at 23:08
  • 4
    @jcuenod It's work that the user has to undo. The user might have to clear the field. If it's a drop-down list, instead of being able to have a habit of pressing the down arrow a fixed number of times to get to a particular month, now it's variable. It's pointless additional work.
    – jamesdlin
    Feb 26 '15 at 10:06
  • 3
    If the user has to select a month and year, by not pre-populating all you do is guarantee that s/he has to fill stuff in. In a dropdown changing the value is the same whether the default is a placeholder or not. No user memorises "5 down clicks for the month field" there's not enough consistency in all the interfaces that we come across to train ourselves like that. The only thing that may cause more work is if the user doesn't realise the values are wrong and submits the form but then you can quickly point the user to the fact that the expiration date is unchanged and was probably overlooked.
    – jcuenod
    Feb 26 '15 at 10:13

Entering a default month and date can be confusing to a user because you are presuming an answer.

As a result, the user may skip over the field, if she is in a hurry, or assume it has been auto-filled after she entered her credit card number.

A placeholder value is better, you can use:


This indicates to the user (a) what the format of the date is; and (b) that the field is still empty and needs to be filled out.

Alternatively you can also use blanks, which visually indicate the empty field (and are visually compatible with the empty text box to the left), but they are not as informative.

  • A placeholder text with one valid format is a good idea. But actually requiring all users to enter the exact same format is not such a great idea, because regardless of which format you chose, half the users will think your chosen format is stupid and wrong. I'd rather allow the users to enter the month in any format of their choosing, as long as it is unambiguous.
    – kasperd
    Feb 27 '15 at 12:27
  • @kasperd while this may be true of other use cases (e.g. entering a date for a calendar entry), I disagree in this case. Open formatting is not necessarily better for users, because a blank textbox that says "enter a date" (a) forces the user to think more than a format cue (cognitive load); (b) creates unnecessary semantic issues (e.g. if a user enters 1 Oct 2017 when the payment process just needs month and date, there is a semantic mismatch which leaves the user feeling disoriented); (c) creates language side effects that you now have to deal with (e.g.In russian: 1 октября 17)
    – tohster
    Feb 27 '15 at 19:34
  • I specifically said that a placeholder text with one valid format is a good idea. There doesn't have to be any suggestion to the user, that the form supports any other format. However if the user does enter an unambiguous date in a different format, I would consider it more user friendly to accept that input.
    – kasperd
    Feb 27 '15 at 23:52

I would have no usable default, so if the user skips it, the page doesn't post, and it indicates the expiration date in a red outline, bold type, or some other fairly obvious means, mainly so the user knows they missed a field, as opposed to typoing a CAPTCHA or something like that.

As stated above, I'd have MM-YY as defaults, and when the year elapses, remove any values that are not of this year. I'd even consider entering a value earlier than the month of the current year cause an immediate error (or at least prevent the page from being submitted.) This is mainly a sanity check.

Instead of typing in, I'd probably consider a pop-up menu. This way, someone typing in 01-2015 can be notified that the date they inputted in is a no-go, and to change it.

  • If you mean that somebody entering "January 2015" should receive a warning now that it's March, I agree. If you mean that the interface should start making quizzical looks at you and mouthing "Are you sure?" as soon as the user enters "January" and it's later in the year than that, everybody with a January-expiring card will hate you for eleven months of the year. Mar 1 '15 at 11:59

In most cases there are 2 main criteria that default value have to satisfy

  1. It must be valid. When user submits the form, fields with default values should not cause a validation errors.
  2. Value must be more common than the other values. For instance, if application is showing a monthly financial report and you are asking a user to pick the month, it is more likely that user will pick the current month.

In case of expire date, you can't have a valid value, it strictly depends on user, and all option are equally likely os there is not usual value.

  • It would be interesting to have statistical datas to confirm equal repartition of date. I presume the next 2 years will be definitely more represented. As for the months, I am curious if there is any significant seasonality (for instance, low frequency of summer months due to lower activity, or alternatively higher frequency due to people getting international credit card for holydays). From a UX perspective, I assume that having an arbitrary date as default would be more confusing than anything else and might require explanation (and/or critical mass) before reaching efficiency gain. Mar 6 '15 at 7:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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