Which arguments should someone consider when designing a new system and has to either store the name of a person as one field or separately as first/last name?

Pros for single field:

  • Simpler UI
  • No ambiguity when trying to enter the name of a person, who has a very long name (often non evident which is the last name / first name..)
  • Less complexity when handling titles (e.g. no need for separate field to enter "M.D" or "Dr.")

Pros for split field:

  • Personalised communication is possible "Dear Mr X" or "Dear Julie"
  • If a consumed web service needs the first / last name separately, it can be provided easily.
  • Better choice for any industry with strict identification requirements (e.g. medical, government, etc.)
  • Safer choice, as you can always go back to the single field alternative

Do you see any additional argument that is not listed above?

Update: the question is, what additional (=not listed in the question) arguments can be listed for each solution. I think giving opinions instead of possible pros and cons drives the discussion in the wrong way. Each developer has to make his/her decision about this problem, the aim of this question is to assemble a list of non-trivial arguments that can be evaluated if needed.

  • 11
    What are you trying to do with those names? Do you have legal requirements? Is there any consequence other than display for the user's name?
    – Darkhogg
    Commented Aug 1, 2017 at 11:03
  • 9
    Firstname/lastname distiction does not support people with only a single name like "Cher".
    – JacquesB
    Commented Aug 1, 2017 at 13:37
  • 78
    I advise you to read the following article: kalzumeus.com/2010/06/17/… it's a real eye opener when thinking about names.
    – Pieter B
    Commented Aug 1, 2017 at 13:57
  • 10
    You might consider asking this question on User Experience, the community there might be able to offer a different perspective on this essentially user interface problem.
    – 11684
    Commented Aug 1, 2017 at 15:04
  • 9
    @PieterB Some of the points in that article are questionable and sometimes you have to make assumptions to get things done. That article doesn't provide useful advice on how to handle names. If a name contains non-unicode characters, what do you do, allow the user to upload a picture? What if there are non-visual aspects - allow a video with sound? What if a name is performance art and can only be performed at midnight in Hong Kong? At some point you have to get real and get on to solving problems instead of revelling in theoretical corner cases that your user base will never encounter. Commented Aug 1, 2017 at 15:15

7 Answers 7


First name and last name are not useful concepts. Names work differently in different countries. In most Asian countries, the family name is written first, but it is still used for sorting—so you may put it in first name, and sorting will be wrong, or in last name, and display will be. And then there are countries like Iceland where they don't use family names at all, but instead father's given name. So they simply sort by given name.

The terms “given name” and “surname” (or “family name”) are better in this regard, but I would still avoid them unless absolutely necessary (i.e. official documents like passports do have them, so then you need them), because they just make things more complicated.

  • Personalised communication is possible "Dear Mr X" or "Dear Julie"

Except you have no idea whether to call given person by their first name, or last name or what. And don't get me started on the languages that have vocative—you can't derive vocative from nominative in general. No, it's better if you simply ask the user what to call them.

  • If a consumed web service needs the first / last name separately, it can be provided easily.

If. If you depend on another service, you are locked to their bad choices. It is no advantage for your own designs.

  • Better choice for any industry with strict identification requirements (e.g. medical, government, etc.)

No, it is a wrong choice for these. Official documents generally use the terms “given name” and “surname” (or “family name”), which are less ambiguous.

  • Safer choice, as you can always go back to the single field alternative

Actually, due to the ambiguity with Asian names, it is not so clear you can.

  • 2
    If the app is used in different parts of the world, the field labels would need to be localized along with how they're combined/used.
    – JeffO
    Commented Aug 1, 2017 at 11:43
  • 5
    @JeffO, the real issue is that these days you are rather likely to have people from different countries in the same system, so you need to create a system and find a way how to insert names from different cultures into it so it works reasonably consistently. Don't enter that rabbit hole unless you really need it.
    – Jan Hudec
    Commented Aug 1, 2017 at 12:17
  • 4
    @IstvanDevai there was a legal case in California where a contract was declared void because credit laws required "last name". The person had a dual Hispanic surname, but when asked for last name, the first (paternal) surname was given, which is common. The other party lost their collection case because the name on the contract was not his "last" name, i.e. the one at the end of his full name. An example of how first/last invites confusion, and is not entirely synonymous with given names/family names.
    – user95851
    Commented Aug 1, 2017 at 21:22
  • 7
    @Casey - middle names should be included in given names field, because that's what they are: secondary given names. If I had a dollar for everytime I've seen a Hispanic person who has no middle name, but a dual surname get their first (and most important) surname shoved in a middle name field, I'd be retired already. If you want to know what to call a person, have a field for that, separate from name. Then Bartholomew Frank Edward Smith Wellington can tell you to call them Bart. We may speak English, but there are people here from non-English speaking places, and their names get entered too.
    – user95851
    Commented Aug 1, 2017 at 23:01
  • 4
    -1. While the answer itself is not totally wrong, it does not make much sense for the question at hand. The OP looks for more arguments for either using either one field or two fields for human names. Whether it is called "first/last" or "given/sur" is not the focus, it's just the labels the OP had in mind. All other points seem highly opinionated to me, and in my personal experience with creating and deploying applications for large customers, the assumptions of the OP are completely normal and just do happen that way. This answer just tries to argue the parameters of the question away.
    – AnoE
    Commented Aug 2, 2017 at 11:44

The only argument that matters is what are the requirements of your system?

Do you need to deal with just one culture? If so, conform to that culture. Otherwise plan for internationalization (as others have pointed out).

Do you need to get data to deal with government forms, healthcare or other legal / system requirements? Follow whatever those dictate. If that means first and last name, do it. If it means something different, do that.

Do you have a requirement for an API with first and last name (or is it reasonably likely, enough to warrant ignoring YAGNI)? Do what makes sense there.

If you need personalized communications, is it reasonable to just ask someone their preferred name and store that?

The requirements of your system should determine what you do. Do what you have to and YAGNI the rest.

  • 10
    There is no such thing as "one culture" any more. Even the smallest communities have mixed cultural norms and languages. Commented Aug 1, 2017 at 15:22
  • 7
    @BobDalgleish True, but sometimes it doesn't matter. Sometimes the cost of supporting multiple cultures makes the business people just say no.
    – Becuzz
    Commented Aug 1, 2017 at 15:30
  • 9
    @BobDalgleish Presumably whichever culture is dominant in the market for which the application is being developed? I don't think this is actually that mysterious or rare.
    – Casey
    Commented Aug 1, 2017 at 20:16
  • 3
    @BobDalgleish - "culture" is irrelevant. No one asks about your culture when you are issued documents. If I needed to support only Serbia (where I'm at the moment) I would include first and last name as those are defined on every document issued in this country, and that's it. It doesn't matter what your culture is. Your passport, drivers licence etc will have first and last name, period. Commented Aug 2, 2017 at 10:37
  • 2
    @icirellik Wrong in what way? Are those things (length limits, etc.) wrong if you are trying to perfectly model the universe? Certainly. But I have never been asked to perfectly model the universe and every possible way someone could want to pick a name. Do I account for Klingon names? No. But why not? Someone might do that someday (honestly wouldn't surprise me if someone did that now). But there comes a point at which you just know there will be some things that just won't work with your model. And the extra dev time to handle every possibility just isn't worth it. (cont...)
    – Becuzz
    Commented Aug 2, 2017 at 15:01

I agree with a lot of what @JanHudec said, although I'd like to expand on that a bit:

  • You need to know what your real requirements are, but it is easier to combine information than it is to split it apart once it is combined again.
  • Sorting will always be a challenge, as the rules can differ across locales and cultures.
  • Many cultures don't match yours, which leads to bad assumptions. (This is Jan's biggest point)

Terminology is Important

Terms like given name and surname or family name have semantic meaning, and your database should always reflect the semantics of your data. Terms like first name and last name have positional meaning, usually based on English and American ideas of how names work. Use the proper terminology for the semantics of your data.

How far do you need to break it down?

There are concepts of title (Mr. Dr. Mrs. etc.) or ordinal (Jr., Sr., III, etc.), and even certifications (PhD, MS, PCAM, etc.) which can be important depending on the context and purpose.

Many locales have the concept of multiple family names (paternal and maternal), and some have none. When filling out forms, sometimes people have to make hard choices as to which name to use, for example using the paternal family name for the "surname" in an American form, or coming up with a last name based on the father's name (Janson).

While in America it is common to have one or more middle names, it's often ignored outside of your family.


It helps to have a dedicated field for sort name. That way you can disambiguate the rules when you create the record. It also ensures you have the names sorted in the correct order across international boundaries.

Common Practices

Your real requirements dictate how correct you need to be about names. If you are creating a government or banking web site, then you have more requirements for storing and handling names than something informal like Facebook.

Informal Guidelines

  • Have one field that describes how the user wants to be known
  • Sort and display uses that one name

Semi Formal Guidelines

  • Have one field for a nickname, or how the user wants to be addressed
  • Have two fields, one for given name and one for surname (surname should be optional)
  • Calculate a sorting field based on locale and the given/surname combo
  • Use the nickname when addressing the user directly
  • Use the formal name when listing people

Formal Guidelines

  • These are dictated by existing policies and procedures for the entity you are supporting
  • You need as many fields as the maximum number of name parts you will be supporting, named semantically for what they are.
  • Include a sorting field that handles the sorting as you would in the semi-formal case
  • Display also is usually dictated by existing policies and procedures. You need to familiarize yourself with them.
  • Would the downvoter care to elaborate? Perhaps I missed something? Commented Aug 2, 2017 at 12:55
  • This seems to me to be comprehensive and the most pragmatic advice given here. Commented Sep 18, 2018 at 17:37

If you have more than one way to display and/or utilize the name(s), then you'll probably need separate fields. Along with the data entry, you could provide feedback to show the user how it will be utilized. How you combine them, could lead to converting to a single field in the future.

Have some labels that show: Greeting or Display Name: First Name + Last Name Organizing/Sorting: Last Name, First Name

When you're not sure how this will be used in the future, start with split names and then you can combine them into a single field when you realize that's all you really need. It's not that it is difficult to write an algorithm to split up a single name field into first and last name, but you will make a mistake on a few and people really don't like mistakes with their names. With split fields, users can adjust how they enter their name when they see how it is used. Combining them in a permanent single name field is less risky.


Apart from what @JanHudec has pointed out and with which I agree, it's also worth noting that in many countries people have more than one last name, so single last name field might be irrelevant. E.g. in Spain people have two last names, and they use only one or both of them depending on situation.

Besides you shouldn't personalize communications based on your assumptions as in some cultures you may seem to be rude when calling people by their last names and in case of others it might be the opposite.

Also, some cultures put an emphasis on forms like 'Mrs' vs 'Ms', and they may also combine this word with first or last names depending on a particular case.

So I would lean towards a solution where you have a single name field and maybe additional fields that the user fills that hint how to turn to the user - something similar to what many airlines do when you buy a ticket online. This may also solve the problem of how to split the names if you need it for an external web service you've mentioned.

  • 1
    Presumably if you are actually localizing you can use a different template for different languages
    – Casey
    Commented Aug 1, 2017 at 18:19

At add even more to what @JanHudec and @KjMag have pointed out, even in cultures/languages very close to English this becomes a problem. Take German for instance. You have the concept of Vornamen, First names, Nachnamen, Last names, and Rufname, the name you are called. Take my father for example, he has 3 first names, on his birth certificate they are listed in the order Christoph Stephan Andreas. And he has one last name. What do you think the name is he is called by?

The correct answer: Andreas. That is his Rufname, in America he puts that as his first name to fit the American template. So you might assume in Germany the last of your first names is the name you are called but then you have my brother: Christoph Sebastian Herbert Maria. (Now I have given away we are Bavarian) Or my sister Christine Gabriele. What do you think are the names that they are called? Sebastian and Christine respectively.

I would third the answers that say one field for a full name. And I would add to that: maybe add another field for a Surname/family name and pose the question: by what name would you be sorted in a list? And then a final field for: how do you want to be addressed?

  • 1
    "Last name" is just another name for "surname," not literally the word that appears last in sequence. The last name of Nakayama Taro is "Nakayama."
    – Casey
    Commented Aug 1, 2017 at 18:21
  • 2
    To add another case: My grandfather was called "Antoon Leendert van Ingen Schenau" => given name(s): "Antoon Leendert"; called: "Leen"; family name: "van Ingen Schenau" to be sorted under "Ingen". Neither the calling-name, nor the correct sorting can be derived easily from a first-name/last-name entry. Commented Aug 2, 2017 at 8:37
  • 1
    @Casey according to who? in japan it is "upper name", for instance, not "last name".
    – eis
    Commented Aug 2, 2017 at 8:42
  • 1
    @eis In Japan it is 名字. But here in the English-speaking world, "last name" is a synonym for "surname" and not literally "the last word in someone's sequence of names."
    – Casey
    Commented Aug 2, 2017 at 10:12
  • 1
    @eis I'm not sure what point you want to make. The users won't know the difference if you call the database field last_name instead of surname; one is just a synonym of the other. If your concern is presenting the software to non-English speakers, then it's irrelevant because both "surname" and "last name" are English terms and you should use the term in whatever language you mean to localize the page into. If the concern is you want people who don't know English to be able to use the English page, well, that seems like a pretty half-hearted way to address the actual problem.
    – Casey
    Commented Aug 2, 2017 at 13:23

If one is going for a global application, one would probably model a person's name as an array of strings. For example, consider the president's name in the movie Idiocracy:

  • Dwayne Elzondo Mountain Dew Herbert Camacho

That's his full name. The name contains 6 elements in the array. For US culture, the first name is the first element in the array (Dwayne) and the last name is the last element in the array (Camacho). But that is not always the case.

One could apply culture specific rules to determine the "first" name if the first name is actually the last element and so forth depending on how names work in different cultures/locales.

Also, in the US case, we have cases when the last element is not the last name such as:

  • Dwayne Elzondo Mountain Dew Herbert Camacho Jr.

So, maybe a name suffix field or one would have to parse the last element looking for known suffixes based on the culture to get the correct last name.

So, your always better off storing the name in one element (The full name) and then applying a "standardization/sanitation" routine against it to parse out the specific elements as needed. A similar strategy exists for addresses. They are usually collected as one string and then sent to a service to parse the parts.

  • 3
    Single field and then "parsing" is a really bad idea. Consider a person whose surname is "Senior": how do you parse that? What about "de la Jolla" as a surname? Commented Aug 1, 2017 at 15:21
  • I mentioned parsing or a name Suffix field. If a generic solution is needed one would need a name parser so you could handle the each case like "Senior" and "de la Jolla". One could use AI and train it how to recognize names. I bet if one fed it a large enough data set it would be able to recognize the "de la Jollas" of the world. But that is one possible solution. Certainly collecting discrete parts is possible as well but that has it's downsides.
    – Jon Raynor
    Commented Aug 1, 2017 at 15:59

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.