Format the ‘Expiration Date’ Fields Exactly as the Credit Card (40% Get it Wrong)

This is the 6th in a series of 8 articles on checkout usability that combine findings from our checkout usability study and benchmark of the 100 largest e-commerce sites.

During our usability studies we’ve observed customers needlessly struggle to decipher expiration date fields when the values are formatted differently from the credit card. The solution is of course obvious: format the expiration date values the same way they are formatted on the card. In this article we’ll look at how to do just that.

When benchmarking the top 100 e-commerce sites in the US we found that 40% formatted the expiration date fields in ways that doesn’t match the majority of credit cards out there. Luckily, that also means 60% had chosen one of the two optimal ways of formatting the expiration date fields.

How You Shouldn’t Format the Expiration Date Fields

If the goal is to match the credit card formatting, then you should avoid using month names (with one exception noted later) and the year should preferably be two digits long instead of four. This is because most cards have the expiration date printed as numbers (as defined by ISO7813), and so the correct way to format your expiration date fields is to show numbers only. This minimizes confusion and misreading because the customer can easily verify the value on their screen against the value printed on the physical card.

Macy’s approach with month names and 4-digit year makes it needlessly difficult for the customer to match the values in the virtual fields with those on the physical card

During our e-commerce checkout test sessions some users started counting the months on their fingers when presented with a “month name only” drop-down to make sure that the “09” month they saw on their credit card did in fact translate correctly to the “September” selected on their screen. This behavior was confirmed in our recent mobile e-commerce usability study as well.

Here a test subject is confronted with month names on Macy’s mobile site, so the subject starts counting the months as he wants to be completely sure which month name the “07” digits on his credit card corresponds to.

The Optimal Way to Format the Expiration Date Fields

The correct way to format the month field is to use numbers and to prefix all single-digit numbers (i.e. 1 to 9) with a 0, so that they appear exactly as they do on most credit cards (e.g. “03” for March). The correct way to format the year field is to use just two digits, to match the number on most credit cards (e.g. “14” for 2014).

Some card issuers choose to print the expiration date differently so you can’t match every single card out there perfectly – instead the idea is to match the vast majority of them.

Net-a-Porter formats the expiration date values to match the way they are printed most credit cards. (Note: month/year labels would improve this implementation.)

The ISO7813 standard specifies the characteristics of “Financial Transaction Cards”. In section 6.2, the standard specifies MM/YY or MM-YY as the correct way to emboss the expiration date on credit cards. Hence designing your expiration date fields to match these values will allow the customer to very easily enter the correct input because they don’t need to translate the numbers on their card to the corresponding month name, or worry whether they’re supposed to enter another set of values altogether.

Hayneedle postfix the month digits with the month name. During our usability tests we’ve found this to be an acceptable way to format the month values too.

During our usability test sessions we’ve identified a second acceptable way to format the expiration date fields: you can include the month name as long as comes after the month digits. The test subjects showed no difficulties when month name was appended to the digits so “03 – March” is an acceptable format, but “March – 03” is not (it hurts scannability). When the digits are front-loaded, the immediate value matches what’s printed on most cards which makes it easy for the customer to instantly identify the correct option.

Getting the Details Right

There are a couple of small details you can implement to further improve the design of the expiration date fields.

One thing you can do is add labels below the expiration date fields to explicitly state the value they represent. In fact, some cards have small “Month” and “Year” labels printed below or above the expiration date digits, although it is not as common as the ISO-specified “MM/YY” embossing.

FTD makes it absolutely clear what the drop-down values represent by adding “Month” and “Year” labels below each field.

Another benefit of this implementation is that you avoid any confusion as to which field represents months and which represents years – although starting next year (2013), this won’t be an issue for another 80 or so years. (Note: if you’ve opted for the “02 - February” month representation the importance of labeling each field this way of course go down drastically as the value itself will function as an indicator.)

If you’re really looking to perfect the expiration date layout, you can add a forward-slash or dash between the two fields (ISO7813 define both as acceptable, although in our experience the forward-slash is the most common card design). This will further increase the resemblance between the values printed on your customer’s card and the design of your expiration date fields.

Safeway adds a forward-slash to further increase the resemblance to the customer’s card layout.

This is however not an invitation to go over the top with a skeuomorphic form design and decorate your payment form as an actual credit card. Instead what we’re advocating is that you ensure the values the customer has to select in your payment form match the values printed on her credit card – allowing her to select those values with greater ease and confidence.


To sum-up, let us quickly go over some common formattings and separate the good from the bad.

Bad. How not to format the card expiration fields (yet what 40% of top retailers do):

  • March / 2012 · Completely off. Month names are difficult to decipher and year should preferably be two digits instead of four.
  • March - 03 / 2012 · Difficult to scan month digits due to varying lengths of the 12 month names.
  • 3 - March / 2012 · Month digit isn’t 0-prefixed.
  • 3 / 2012 · Month digit isn’t 0-prefixed.

Good. Two optimal ways of formatting the expiration date fields:

  • 03 / 12 · This is the most common card layout resulting in 1:1 mapping between virtual fields and physical card, but remember to clearly label each field with “month” and “year”.
  • 03 - March / 12 · Adding the month name lowers the chance of mixing up month and year, but this comes at the cost of 1:1 resemblance with the credit card.

Tip: remember to make the “year” range update dynamically so you don’t end up with a ‘2008’ option in year 2012.

This article presents the research findings from just 1 of the 642 UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.

Post a comment or Share:

User experience research, delivered twice a month

Join 19,000+ readers and get Baymard’s research articles by RSS feed or e-mail:

Due to spam, you need JavaScript to do that.

(1-click unsubscribe at any time)

Note: by using text fields instead of drop-downs (see Aéropostale and CVS) you can of course ignore most of the formatting concerns outlined in this article as the user can simply type the values as they are printed on her card.

However, such implementation has problems of its own with increased chances of mistyped input and complex server-side logic to decode the many different types of input formatting customers may use.

Article series

  1. Don’t Use ‘Apply’ Buttons
  2. Don’t Require Seemingly Unnecessary Information
  3. Visually Reinforce Your Credit Card Fields
  4. Accordion Style Checkouts – the Holy Grail of Checkout Usability?
  5. Why Your Checkout Process Should Be Completely Linear
  6. Format the ‘Expiration Date’ Fields Exactly as the Credit Card
  7. Add Descriptions To Checkout Form Labels
  8. A Holistic View on the Current State of Checkout Usability

Related Articles

See all 49 ‘Cart & Checkout’ articles

More E-Commerce Research

Free Research Content:

Products & Services:

Comments (20 so far)

Jessica Enders October 24, 2012

Don’t you just slap your forehead that articles like this even need to be written? I empathise!

But on a more serious note, do you know if it would be possible to use the card number to detect what card type it is (i.e. American Express, Visa, Mastercard etc) and then, knowing that, format the date fields to match exactly as on the card? Obviously this would be the ideal with all the trimmings – so not /necessary/ – but I’m curious whether it’s possible.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute October 24, 2012

Hi Jessica,

Yes it is possible to detect the card typed based on the first 6 characters of the card number (called the IIN range). E.g. VISA start with 4. Most AMEX 34 or 37 and so on. But the IIN range contains much more info than that. It is also tied to the issuing bank.E.g. a card starting with “454305” would be a VISA card issued by Royal Bank of Scotland.
Where your idea gets a bit more difficult to execute is knowing exactly how each issuing bank format their expiration date and then tie that to their IIN range. (Someone should do such a list.. you, me, the card organizations? – is it worth it?)

But on a more basic level you could use the IIN range to change the description for the security code field accordingly. As you know VISA and MC is 3 digits on the back, AMEX is typically 4 on the front. With clever use of the IIN range customers entering a VISA card number won’t see a Security code form description that reads “VISA/MC: 3 digits on the back. AMEX: 4 digits on the front” but only what applies to them, and vice versa. Like this:

Due to spam, you need JavaScript to do that.

[Anonymous] August 17, 2016

Jessica Enders Great Response!

Due to spam, you need JavaScript to do that.

Martin Sansom October 24, 2012

A superb article – one thing that isn’t clear though in your article is whether payment cards in America use the US standard way of displaying at date rather than the UK version.


US = Month, Day, Year
UK = Day, Month, Year

There are many websites which allow users to switch prices to their preferred currency, but I’m guessing that 99% of those sites fail to switch the date layout at the same time.

Does your research indicate whether this could be a problem, or are users smart enough to figure it out?

I’m assuming that labelling the input boxes helps, but many people would just follow blindly what it says on their Visa card.

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute October 24, 2012

Hi Martin,

Great question. The credit card expiration date is for most cards only a month and a year. And luckily in both the US and UK format you mention the year comes last, so MM/YY won’t be a problem in that regard.

Outside the context of credit card forms you are however on to a great point. We’ve recently seen a test subjects order a flight for a completely wrong date (!) because the site used US format (MM/DD/YY) and the subject was used to DD/MM/YY. For this reason we’d recommend that you always write the month as a name whenever you display a specific date (January 5th, 2012 instead of 05/01/2012 or 01/05/2012).

Due to spam, you need JavaScript to do that.

Joe December 7, 2012

Thank you for this article! And thank you Jessica ( for bringing it to my attention.

I ask people all the time if they notice this but to be honest, they tend to gloss over it. They’re focussed past it, for when the site confirms the transaction and they can get on with their lives. However, when testing sites in a controlled environment I do get people asking why it is asking for a name-month when the card is a number-month. I can understand someone thought it might be helpful but it is clearly a case of “thought it might help” instead of “proved it might help”. Your analysis clearly shows it doesn’t help.

To be exact, the form isn’t asking for the “month” at all, it is looking for a value from you that it can supply to the payment gateway that helps that gateway process the order. So if it has 03/13 on the card, we really should be capturing 03/13 in the form, regardless of all these other influences. it could equally be supplying two letters, what matters is the process requires two numbers so we should comply with that. The separator is a moot point, since we don’t need to enter that and can regex it out of the way anyway.

Asking the user to translate 06 to 6 – June is completely unnecessary and in some cases, interferes with the process.

Out of curiosity. how does the 60% who use one of your two optimal solutions break down? I’m hoping it is a majority for number only, but not holding my breath.

Due to spam, you need JavaScript to do that.

Kashish Sharma April 2, 2015

How would you update the ‘year’ range dynamically or using html

Due to spam, you need JavaScript to do that.

Scott Taylor November 14, 2015

Do you have any idea why the standard embossing isn’t defined as “MM/YYYY” with four-digit years? That would push out the month/year ordering issue from “80 years” to basically never. (I’m surprised that the four-digit year representation hasn’t become the norm after the Y2K debacle….)

Due to spam, you need JavaScript to do that.

nobody December 29, 2015

Anyone have an idea on what the best practice is on number of fields for the expiration date?
I think two fields with dropdowns (one for months, one for years) is simpler for the user while another person I work with thinks a single field where the user has to input the months and date via keyboard is simpler. Thoughts?

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute February 1, 2016

We have tested “text field vs. drop-down” specifically in our upcoming study on e-commerce checkout usability which will be out later this year.

Due to spam, you need JavaScript to do that.

Ben Ruggeberg October 19, 2016

I look forward to seeing that! We have been discussing it a lot at my organization as well.

Due to spam, you need JavaScript to do that.

Ben January 13, 2017

I am also looking forward to seeing the results. In particularly with respect to mobile user.

Due to spam, you need JavaScript to do that.

Mega Weise June 29, 2018

Do you mind linking to that article?

Due to spam, you need JavaScript to do that.

Christian, Baymard Institute July 4, 2018

Hi Ben and Megan, at Baymard we release approx. 5% of all our findings as free articles (like this article on expiration date). 95% of the research findings are available in Baymard Premium;

If you have full access to our research catalog, the guideline that contain our test findings on the expiration date field is

Due to spam, you need JavaScript to do that.

Diesel January 30, 2016


Due to spam, you need JavaScript to do that.

George@ February 18, 2016

Are we there yet

Due to spam, you need JavaScript to do that.

eric hutchinson August 19, 2017

when i click on to the month
of the expirey date a bar drops down with numbers 01 to 09 i need 11 how do i do this ?

Due to spam, you need JavaScript to do that.

Lois Knight August 23, 2017

|I have a product which the expiry date is listed as EXPSE201g. Perhaps that’s September 20th but what year and what does the g stand for?

Due to spam, you need JavaScript to do that.

Btlejuice September 5, 2017

How do I enter exp date if on card exp states 8-31-2018

Due to spam, you need JavaScript to do that.

Erik bryan September 16, 2017

How do I enter ending date 06/20 urgh in 4 digits

Due to spam, you need JavaScript to do that.

Post a comment!

Due to spam, you need JavaScript to do that.