The UX for entering the month and year of a credit card expiration date can be tricky. I tried a few services (Netflix, Lyft, Uber) and found they were all buggy. Amazon avoids this by using drop-down fields. Cash App (from Square) avoids this by disallowing any edits except for backspacing from the end.

I've looked at related threads on this site and articles they link to, such as https://ux.stackexchange.com/a/98983 and The most intuitive way to input credit card expiry dates.

Some principles are widely accepted, such as automatically adding the / after the user types the first two digits. But I can't find anything addressing my question.

Suppose the user types in an expiration date like 06/30, representing June of 2030. Then the user realizes they meant to type in 07 for the month. They put the cursor right after the 6 and backspace. What do they see? I think the two main options are:

  1. 0/30
  2. 03/0

These represent two different philosophies. #1 would treat month and day as separate fields that can be edited independently of each other. #2 would treat the expiration date as a single text field with a / after the second character.

Which is better UX? They both seem odd to the user, and would need less restrictive validation in editing than when originally typing.

If I was editing a phone number or social security number, I would use #2. It's clearly one field. In something like the Square Cash App, where credit card number and expiration and CVV are all displayed in a single row, those are clearly separate fields and I would expect #1 (although again, in their case, they don't allow moving the cursor and editing previous characters). If the month and year were physically in separate fields, they should be edited independently. But this case seems ambiguous.

If it matters, this is for an Android app.

What's better UX? #1, #2, or something else?

  • 2
    Steam uses two textboxes and adds the slash as regular text between them. Which needs pretty much no validation in UI except numebrs-only and avoids drop downs
    – jaskij
    Commented May 8, 2019 at 19:00

2 Answers 2


Treat it like two number fields.

This way editing will be simple and obvious and entry will take minimal effort.

Some implementation details I'd add to make it nicer:

  • Use two fields, separated by a / character, but style them to look like one area.
  • User-entered /, \, -,. characters advance to the year field.
  • After filling the month field with two digits e.g. 03, advance to the year field so the user can complete the date with 20
  • User input of 0320, 03.20, 3.20 and 03 [tap] 20 should all yield the same result.
  • Make sure it works with password managers/autofill; many users won't have to do any of this!

No, not drop-downs

A drop-down is a very tedious way to enter numbers in a field, especially on a phone where I could have a number pad. If the field types are set to numbers, Android should show the number pad.

While a credit card expiration only has 12 months and a few possible years, you'll want all date entry fields to be consistent, and you definitely shouldn't have a drop-down with 31 numbers in it.

  • I'm not sure if dropdowns are really a "no-go" in this case. For inputs where users can not be 100% sure what the required format is, it gives them more security to see the available options in a dropdown, rather than having to assume that it'll work. Admittedly, two separate number fields are not very hard to understand, just putting it out there that dropdowns can be a valid option in such cases.
    – Big_Chair
    Commented Nov 21, 2019 at 13:55
  • Dropdowns have more versatility as they allow you to either select from a list, OR type to select (like an input field). E.g., with a dropdown, I can type "03", hit tab and type "2021" for entry - OR I can select from the dropdown. But as you point out they are best when there is a limited number of entries. Fortunately there's no need for 31 with a CC date dropdown, as it's just month and year.
    – Tim Holt
    Commented Nov 21, 2019 at 20:16
  • Fair point for desktop, but on mobile, a dropdown would force you to spin through the list which I find more tedious than tapping the two numbers. And while there aren't 31 numbers in this particular case, a key tenet of UI design is to keep it consistent. If the app has, or ever would have a full date field, that one should be exactly the same, forcing you to use the dropdown again or break consistency.
    – cloudworks
    Commented Nov 22, 2019 at 8:37

I think you answered your own question right here...

Amazon avoids this by using drop-down fields

You'll vastly simplify your problem with that solution.

The only real UX caveat for a drop down is that it should show values that match what cards show - which is a MM/YY style (e.g., 09/22). So the drop down shouldn't have month names instead of numbers. Some people know the number of every month off the top of their head, but some people don't.

  • True. But in my case I'm required to make it a text field. Also, in my Googling I did find several assertions that it's better to make every field a text field, rather than have the user switch between drop downs and typing. I'm not sure if that advice holds true for apps as well as desktop though. Commented May 8, 2019 at 22:05
  • 1
    Why is this a requirement?
    – Tim Holt
    Commented May 8, 2019 at 22:33
  • 1
    You say "...better to make every field a text field, rather than have the user switch between drop downs and typing." If the drop-downs are designed well, the user doesn't have to "switch" anything. They should still be able to enter the info they want with a keyboard, tab to the next field, enter the data with a keyboard, tab to the next field, and so on.
    – Doug Deden
    Commented May 9, 2019 at 19:46

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.