I have previously been using 4 fields for the credit card number, splitting up each set of 4 numbers to make it easier to enter.

I am now thinking about having one field, which inserts spaces after every set of numbers instead:

single field with spaces between groups of four digits, and old field with four separate boxes

For the one with 4 fields, the cursor jumps to the next field automatically.

Which format is preferred? Or are there any other better alternatives?

I only accept Visa, Mastercard and Discovery, with 16 and 17 digits.

  • 14
    What if the credit card number was less than 16 characters (amex) or longer than 16 characters (can't remember the card type that does that)?
    – gabe3886
    Commented Sep 6, 2016 at 12:15
  • 66
    What is wrong with a single entry field with no fanciness?
    – user42005
    Commented Sep 6, 2016 at 15:28
  • 96
    My bank's website has a 3-field input for sort code when setting up a bank transfer which auto-jumps to the next field once you've entered 2 digits. When I noticed that I'd made a mistake in the previous field, I hit SHIFT+TAB, which moved the focus back to the previous field onkeydown, but when I released the tab key, the site's onkeyup handler noticed there were two digits in that field and "helpfully" jumped the focus forward again! Argh! I had to find my mouse and click on the field. Horrible.
    – daiscog
    Commented Sep 6, 2016 at 15:31
  • 83
    Please please don't make it several boxes. I find this infuriating as I usually store my CC numbers in password database software which copy and pastes them in for me. This is totally broken when a website uses several boxes. Usually trying to paste it all into the first box.
    – Vality
    Commented Sep 6, 2016 at 22:48
  • 11
    @nigel222 That's an argument for displaying the number with separators, if you expect the user to need to read it. But for inputting?
    – user42005
    Commented Sep 7, 2016 at 10:51

10 Answers 10


I would generally always opt for the simplest solution. In this case, one single field for the user to type into.

With split fields, such as the 4-box one you propose it adds in an extra cognitive load to the user.

  • "Do I need to manually jump to each field?"
  • "Will the system do it for me?"
  • "What if I hit tab myself but the form automatically jumped - will it have jumped into the 3rd field instead...?"

All these extra questions - perhaps subconciously, perhaps more forefront in their minds - are not questions that would even be considered in a single field form.

Sure, 4-field options aid readability - so if the user entered their number wrong it's easier for them to re-read their entry to see what area they did wrong. But this can still be mitigated in a single field. Just as you showed above, you can render the user input with spaces in the single field.

Another consideration is mobile users. While it may well be simple on a desktop, a mobile has a keyboard it needs to open and close on entry of the field. Different devices and OS's behave differently, but it's quite likely that on the jump from field 1 to field 2 the keyboard will autoclose and autoopen, causing a jarring flash on screen, with the user possibly trying to click the 5th digit just as the keyboard closes, thereby moving the cursor into another area of the screen altogether, or just missing that digit from entry altogether.

This mobile issue is illustrated nicely on Baymard blog, where they also point out that mobile users tend to manually press into each field - something desktop users don't do as often.

Your proposal is a nice idea, but I think it falls into the category of 'overengineering'. Unless you're noticing significant user input errors on a single field I don't think you need to introduce an alternative. You could risk decreasing the usability instead of improving it.

  • 87
    @EshwarenManoharen Just let them type the numbers, and ignore any other characters they type (including spaces) but render the output with spaces in the appropriate place.
    – JonW
    Commented Sep 6, 2016 at 9:49
  • 34
    @EshwarenManoharen just throwing this in here, no matter what you do in HTML/JS to allow only numbers, make sure that you validate the input server side, HTML/JS can be easily manipulated by the user.
    – TMH
    Commented Sep 6, 2016 at 10:55
  • 25
    Joined just to give this +1. I get very frustrated with UIs that auto-jump, such that when I tab I end up skipping an input box.
    – AndyT
    Commented Sep 6, 2016 at 11:06
  • 6
    Bullet point 3 is a serious issue in lots of separated fields (phone numbers, social security numbers, credit card numbers); in "vanilla" forms, one gets used to pressing tab to jump to the next field, but when the "smart" form attempts to automatically move you, you wind up in the third field. The far more insidious (and related) "smart form" problem is the one that detects when a field has been completed and jumps you to the next field -- even when you click back into the field to make a correction.
    – Doktor J
    Commented Sep 6, 2016 at 14:01
  • 2
    Also, be prepared for people to type the whole number without looking at the screen. The easiest way to enter long numbers is to look at the card and type using the numeric pad. Commented Sep 11, 2016 at 7:57

This answer and this answer cover some of the points nicely but for some reason nobody is discussing auto-fill support.

Don't use 4 separate fields.

  • First, it's annoying, a lot of those reasons are covered in the other answers.
  • Also, a CC number isn't four 4-digit numbers, it's a single long number. Some credit cards don't even have groups of four, in which case your four field input doesn't even make sense, for example:

    enter image description here

  • The real one I want to add is some browsers give the option of filling out credit card info for you. Chrome, for example has this functionality, and Safari on iOS 8 will automatically add a camera-enabled "scan credit card" button to these fields if you craft them properly (see that article). And so the real "perfect" CC field from a UX perspective is a single field with the appropriate field name (like "Credit Card Number") and appropriate browser-specific trigger attributes (like autocomplete="cc-number" and id="cc_number").

Don't go trying to invent your own "convenient" input method for this. Stick to the same standard credit card number input methods that are already commonly in use (single field, appropriate name and attributes), because browser developers are already making an effort to improve the UX of these kinds of fields, so you let it be handled on the browser-side and give users something that they're familiar with instead of something inconvenient that also runs the risk of breaking all of the nice features their favorite browser normally gives them.

  • 6
    Great answer! I hope it gets its share of upvotes despite being late in the game. Here's mine. Commented Sep 6, 2016 at 15:41
  • 6
    When I make car payments, my browser (Chrome) tries to fill in my username in one of the credit card fields (split as four input boxes). This actually makes it more work than if it were one field. Developers really need to allow auto-fill to do its thing. Having one input field is the best choice. I'm also annoyed when my expiration date won't autofill because of some unusual jQuery plugin to select the month and year.
    – phyrfox
    Commented Sep 7, 2016 at 5:40
  • 1
    Great answer, to add to this, not all credit cards are 16 digits long; there are shorter and longer variants. I also wouldn't trust browser vendors to get it right, although you can certainly trust them more than a homegrown solution. In my experience, it is better to avoid any prohibitive validation (validation that will not allow the user to continue) and let the payment gateway make the final decision.
    – Ben
    Commented Sep 12, 2016 at 8:03

As someone who happens to use virtual credit cards, I'm strongly in favour of a single field. Every time I want to pay, there is a new card number generated for me by the banking app, and it's very tedious to have to copy-paste four times instead of one. I'm assuming here that your form won't fill the 4 fields if I paste 16 digits in the first one. Will it?

Also, I have seen several 4-field designs which were incredibly hard to use. Sometimes pressing Backspace was required to come back to a field with a typo, in other cases Shift+Tab was required. Sometimes the field you jumped to had its text pre-selected or cleared, so it was basically impossible to predict how the form would behave without observing it after each key-press.

Just give me one field where I can paste a card number into, and let me use Backspace to fix any typos if I happen to type the number manually. Here's something that looks acceptable:

$('#test_form').on('keyup', function(e){
    var val = $(this).val();
    var newval = '';
    val = val.replace(/\s/g, '');
    for(var i=0; i < val.length; i++) {
        if(i%4 == 0 && i > 0) newval = newval.concat(' ');
        newval = newval.concat(val[i]);
  • 15
    Similarly, I keep my credit card number in my password manager, so I want to be able to copy-and-paste it into a single field. Several times I've abandoned a purchase when a website expected me to break the number up into 4 digit chunks.
    – Johnny
    Commented Sep 6, 2016 at 16:15
  • 26
    @LightnessRacesinOrbit - Why is it an overreaction to not support a merchant that goes out of his way to make it harder for me to give him my credit card information? I'd also walk out of a brick and mortar merchant if they made me swipe my card in 4 different credit card readers. If the merchant will autosplit a pasted number across whatever fields they want, I'm fine with that, but I don't want to have to paste the number somewhere else on the screen, then copy-and-paste each chunk individually (or type it manually)
    – Johnny
    Commented Sep 6, 2016 at 21:32
  • 10
    @LightnessRacesinOrbit I have done the same thing as Johnny many times myself (for different reasons, but everybody has their own valid peeves). It's not like there usually isn't 1000 other merchants to buy the same thing from these days. Philosophically, I don't support stores that make me do frustrating things in order to give them my money. Personally, I'm sick to death of crappy web design.
    – Jason C
    Commented Sep 7, 2016 at 2:58
  • 8
    No, it's not an overreaction; the website is asking you to do extra, fiddly, error-prone work because they've made entering the number more complex than necessary. Frustration is a good reason to resent design. If only websites supported contactless payments ...
    – pjc50
    Commented Sep 7, 2016 at 11:39
  • 5
    This functionality would piss me off immediately. I can think of more than one occasion in which I missed digits 5-8 of my credit card due to my cat attacking my face, child spilling juice on my back, or I get caught up swinging my sword at dragons. Anyways, the point is that now I must delete digits 9-16 if I wish to type in my missing digits or else your code will put my cursor to the end of the text field on EVERY SINGLE KEYSTROKE
    – MonkeyZeus
    Commented Sep 7, 2016 at 19:15

The simplest, if not necessarily the absolute best, solution is a single credit-card field that lets a user input any string of digits and spaces. It should be trivial for the server-side logic to strip the spaces out of the submitted string before checking whether the resulting string of digits is or is not a valid credit card number. If the user chooses to enter leading or trailing spaces or to break the digits in different places to what is on the card, so what?

Automagically inserting the spaces for the user may be slightly more user-friendly but is a lot more work.

Multiple fields with auto-tab from one to the next is OK, but if you take cards other than Mastercard/Visa then it is a lot of work to adjust the field lengths for the card type (e.g. 4,6,5,0 for Amex) on the fly (i.e in a browser-side script). On a card-company website that by definition only ever takes one sort of card, it's clear and easy. [Edit: OK-ish. Other answers indicate why it is a dis-benefit for some users ]

Refusing to let the user enter spaces is user-hostile. Allowing the user to enter spaces and then rejecting the (correct!) card number as invalid after submission is truly abominable, to the extent that I might refuse that retailer my custom at that point and instead buy from whoever was formerly my second choice.

  • 11
    Yes indeed. Requiring the user to remove the spaces from the credit card number is an example of lazy and harmful UX design. It is fine to store the credit card number without spaces, but requiring the user to perform the conversion by hand when the computer can easily do it is lazy. It is harmful because the spaces are there for a reason: to reduce data entry errors.
    – David42
    Commented Sep 7, 2016 at 12:52
  • 5
    +1 for making the system do some of the work. (-1 for auto-tab.) Commented Sep 7, 2016 at 12:54
  • This solution is by far the best. No possibility of confusion or unexpected reactions. No unexpected results from typing tab or space. Fully compatible with various browsers' autofill. The only thing I might add is putting the phrase "spaces optional" next to it.
    – Tenfour04
    Commented Sep 7, 2016 at 13:57
  • 1
    It is very bad for spaces not to be allowed for entry, yes it should be a single field. If you are a financial institution the first 4,6 or 7 numbers may denote a particular BIN, product, sub-product respectively and these may be more important to you under the covers so you yould define an object with these mapped. The operator does not need to know in most cases. Also, despite PCI, some cards are swiped through a reader for entry, it is nice to dress the number.
    – mckenzm
    Commented Sep 8, 2016 at 3:58
  • 6
    also, don't hard limit the length of the field to just 16 characters, if they paste a credit card number with spaces, some numbers are cut off, giving validation errors later
    – Ferrybig
    Commented Sep 9, 2016 at 14:38

Luke Wroblewski, a UX expert with great insights on building efficient forms, answered this question: use a single numeric input field (here’s a video of how this works).

As you can see in the video above of Zachary’s demo, a single input field is used to capture credit card number first. If the credit card number is invalid an error is displayed that prevents the user from moving forward. If the credit card number is valid, the generic credit card icon changes to reflect the type of card entered. This removes the need for a separate credit card “type” drop down or selector and reassures someone that their entry has been understood.

Once the credit card number is validated, it slides over to the left leaving only the last four trailing digits for reference and the next set of inputs appear in the mask: expiration date, CVV (security) code, and ZIP code. Since these are all numeric inputs, a 0-9 set of soft keys is all that is needed to keep people moving along on the keyboard.

Since the expiration date on a credit card can’t be in the past or far future, the input mask one again helps keep people away from errors. Invalid months or years simply won’t be accepted. After a valid expiration date has been added, Square’s design features another excellent enhancement. The credit card icon changes to reveal where the CVV code is located on the specific card being used to pay. This small detail helps clue people in to what information is required next.

Because CVV and ZIP are also numeric entries, there’s no reason to ever leave the dial-pad throughout the payment input process: no jumping between multiple form fields required. Zachary’s also made sure that people can use their keyboard (tab and shift-tab) and mouse to move between the various parts of this payment input mask.

  • Brad Frost has implemented a single-field solution on this donation site. Try it out! Commented Sep 7, 2016 at 12:43
  • 2
    @KenMohnkern I don't tend to enjoy using forms where the placeholder is all that's there to tell me what data they expect. It makes it hard for me to review my input to see if the data is correct. Looking back at that credit card info in the link you shared, it takes a bit more contextual evaluation to determine which fields are which because there are no remaining visible labels. Commented Sep 7, 2016 at 14:07
  • 2
    @maxathousand - Absolutely right. Those labels need to move out of the input field. Commented Sep 7, 2016 at 14:22

Please follow the advice of others and do not attempt to reinvent the wheel. Not unless you have read and understood the ISO standard ISO/IEC 7812 that governs Payment card numbers, which, by the way, range from 13 to 19 digits and usually (but not always - read the spec) include a check digit that you can use to validate the input.
Inserting spaces where there are none is almost always a bad idea. Think of all the possible combinations you will have to deal with; auto-filled, used to populate auto-fill. Pasted in with no spaces, pasted in with spaces, cut for use elsewhere (should the cut include the spaces?), typed in, edited, and at the end of the day, what is the problem you are trying to solve?


I think Card.js is my favorite user experience when it comes to adding cards. Not only it lets you type in very quickly (single fields etc.), they also show you where those fields are on your particular cards so you don't have to wonder where's expiration date or CVV. I recommend you check it out.

  • 6
    It's buggy if you modify the credit card number in the middle. Commented Sep 6, 2016 at 13:10
  • 2
    @Insane Delete a few characters and type some in the middle of the number. Sometimes the cursor jumps to the end of the input. Sometimes backspace doesn't delete the character before the cursor. Commented Sep 6, 2016 at 21:13
  • 2
    @Insane github.com/jessepollak/card/issues/257 sounds like the same issue and is 3 months old. Commented Sep 6, 2016 at 21:19
  • 2
    @CodesInChaos Guess the project needs a contributor
    – Insane
    Commented Sep 6, 2016 at 21:32
  • 3
    @Insane That, or people should stop trying to make fields "smart" when there's no need for them to be. Give me a plain input field with nothing active attached to it (except maybe instant validation) and I'll be happy. Commented Sep 8, 2016 at 19:55

Please, for the love of God do not do the second option.

one HUGE UX flaw is (which the majority of sites do when implementing this shutter) you can't go back to edit the numbers previously, because it auto forces you to go to the next field since you filled out the data.

Let's not forget that creating multiple fields make it appear as though you are filling different bits of information. In your design, it makes it look like potentially the last field will be for the "security code".

Making it one field implies one chunk of numbers (but please do what you did in option one: indenting because that shows the exact same format as your card).

When filling out credit card details, you want to come close to what the design of the actual physical card is because users will then be able to scan the card and look up to add the information they have just scanned. Jumbling anything up will cause confusion and frustration (from my experience in working in the ecommerce world for years).


A minor extra point I don't believe is addressed elsewhere: A single box is more accessible, especially on systems without a full suite of accessibility tools:

  • It scales if the window is zoomed (just zooming a browser window still leaves the cursor a thin line which can be hard to find - one pixel if I test on this page in firefox/windows)
  • Tabbing between fields behaves reasonably (don't forget shift-tab).

  • This may not be true any more, but some screen-readers used to struggle with unlabelled input boxes -- this may still be the case for speech input technologies, but I haven't used them.

I'm not saying you can't make an accessible (and standards-compliant) input with separate boxes, but a single box is easier for you and users who need (or want) atypical interfaces.


My solution in the end, was to use one field. Then every 4 digits, it adds a space. Therefore it creates less potential confusion, yet also allows you to clearly view the credit card numbers, in the same format as the card.

The potential issues that arose are:

  • Different number of credit card numbers, e.g. 16 or 17
  • When deleting numbers, it must also delete the spaces when necessary
  • What to do when use clicks on a number and adds or deletes, how will that affect spacing?
  • Typing too fast - javascript can not always react fast enough

If you can get around these issues, then I believe this the most intuitive.

I have created a form here https://jsfiddle.net/9apu6ux3/ as you can see it splits up the numbers nicely, but is difficult to make bullet proof.

  • 2
    When your form is auto-filled (or pasted into), spaces are added at the end, but that's minor. What's worse is when you try to navigate the filled form with arrow keys, it keeps adding those spaces. Commented Sep 7, 2016 at 8:19
  • I have made another jsfiddle which I like better, and put into my answer. Mind to take a look? Commented Sep 7, 2016 at 8:34
  • 3
    You might be introducing confusion to people with 17 digit cards who see the last digit hanging out by itself and not matching their card. Not everyone knows that the spaces between digits are meaningless.
    – Tenfour04
    Commented Sep 7, 2016 at 13:52
  • 6
    Sorry, but I struggle to get around the issues when what I type is not what I get, but only sometimes. Inserting a space if, but only if I typed the fourth digit slowly enough is disconcerting. Consider reformatting on loss of focus instead.
    – Paul Smith
    Commented Sep 8, 2016 at 14:42
  • 4
    Not all credit card companies separate their credit card numbers into 4-digit blocks. This does not seem like a good solution to me.
    – user428517
    Commented Sep 8, 2016 at 23:27

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.