The Definitive Guide to Form Label Positioning

Jessica Enders
A jumble of conference tags (or labels)

Photo: nightthree

When it comes to the design and development of forms, one of the most popular topics is the positioning of labels.

There are a range of different options, but many articles on the subject touch on only some of the advantages and disadvantages of some of these options.

How do you put all that disparate information together to make a good decision, especially if you’re in a hurry?

It was clearly time to bring everything together in one place. Read on for the different options for form label positioning, and the complete list of advantages and disadvantages for each.

If you haven’t got time for that, the main thing you need to know is:

The most usable and accessible option is to have labels always visible, and located above or beside the field.

There’s also a handy guide to choosing between these options.

Options for positioning form labels

For English-based forms, the main options (1) are:

  1. Label on top of the field
  2. Label to the left of the field, and flush left
  3. Label to the left of the field, and flush right
  4. Label inside the field
  5. Label as a tool tip

Five options for positioning form labels

Some of these choices are much better than others. Here’s the complete list of advantages and disadvantages for each approach.

1. Label on top of the field

Option 1: Label on top of the field

Advantages

  • On small screens, when focus is in-field, label can still be seen (despite zoom).
  • User may be able to see the label and the field within one glance.
  • Label length can be longer than field length.
  • Allows for different label lengths when form is translated into other languages.
  • Form is narrower compared to having labels beside fields.
  • Longer labels that wrap are easier to read, as there is a consistent left edge for the eye to return to.
  • Labels are in close proximity to their corresponding fields, so it is easy to see which goes with which.
  • Label is visible even as its corresponding field is being filled out, so the user doesn’t have to remember what the label was, and can cope with interruptions.
  • At any time, users can compare their answers to the labels.
  • Easy to implement well.
  • In HTML, does not require the use of the placeholder attribute as a proxy for label, helping maintain accessibility.
  • It’s easy for users to see where they have to enter information.
  • Works regardless of field type (e.g. text box, radio buttons, check boxes or drop downs).
  • Works with touch interfaces.

Disadvantages

  • Form is twice as long compared to forms with labels beside fields.
  • Labels are harder to scan, as they are separated by fields.

2. Label to the left of the field, and flush left

Option 2: Label to the left of the field, and flush left

Advantages

  • Form is shorter compared to having labels above fields.
  • Label length can be longer than field length.
  • Labels are easier to scan, as they are not separated by fields.
  • Label is visible even as its corresponding field is being filled out, so the user doesn’t have to remember what the label was, and can cope with interruptions.
  • At any time, users can compare their answers to the labels.
  • Easy to implement well.
  • In HTML, does not require the use of the placeholder attribute as a proxy for label, helping maintain accessibility.
  • It’s easy for users to see where they have to enter information.
  • Works regardless of field type (e.g. text box, radio buttons, check boxes or drop downs).
  • Works with touch interfaces.

Disadvantages

  • On small screens, when focus is in-field, label may not be visible (because of zoom).
  • User is unlikely to be able to see the label and the field within one glance.
  • When form is translated into other languages, labels may no longer fit into allocated space.
  • Form is wider compared to having labels above fields.
  • Labels may be far away from their corresponding fields, so it can be hard to see which goes with which (zebra striping can help to minimise this issue).

3. Label to the left of the field, and flush right

Option 3: Label to the left of the field, and flush right

Advantages

  • User may be able to see the label and the field within one glance.
  • Form is shorter compared to having labels above fields.
  • Label length can be longer than field length.
  • Labels are easier to scan, as they are not separated by fields.
  • Labels are in close proximity to their corresponding fields, so it is easy to see which goes with which.
  • Label is visible even as its corresponding field is being filled out, so the user doesn’t have to remember what the label was, and can cope with interruptions.
  • At any time, users can compare their answers to the labels.
  • Easy to implement well.
  • In HTML, does not require the use of the placeholder attribute as a proxy for label, helping maintain accessibility.
  • It’s easy for users to see where they have to enter information.
  • Works regardless of field type (e.g. text box, radio buttons, check boxes or drop downs).
  • Works with touch interfaces.

Disadvantages

  • On small screens, when focus is in-field, label may not be visible (because of zoom).
  • When form is translated into other languages, labels may no longer fit into allocated space.
  • Form is wider compared to having labels above fields.
  • Longer labels that wrap are harder to read, as the left edge is ragged, making it more work for the eye to find the start of each line.

4. Label inside the field

Label inside the field

Advantages

  • On small screens, when focus is in-field, label can still be seen (despite zoom).
  • User may be able to see the label and the field within one glance.
  • Form is narrower compared to having labels beside fields.
  • Labels are in close proximity to their corresponding fields, so it is easy to see which goes with which.
  • Works with touch interfaces.

Disadvantages

  • Label length has to be less than field length.
  • When form is translated into other languages, labels may no longer fit into allocated space.
  • Labels are harder to scan are they are contained within fields.
  • Doesn’t allow for longer labels that wrap.
  • If label disappears completely once the field is being filled out, the user has to remember what the label was, and will be derailed by interruptions.
  • If label disappears completely once the field is being filled out, the user can’t later compare their answers to the labels.
  • If the label stays as is, even when the field is being filled out, the user has significantly less room to enter information. It’s also very hard for users to distinguish labels from answers, and there is no real space-saving.
  • Difficult to implement well.
  • In HTML, use of the placeholder attribute as a replacement for label reduces accessibility.
  • Because fields look like they’ve already been filled out, it’s difficult for users to see where they have to enter information, so error rates are higher.
  • Doesn’t work with field types other than text boxes and possibly drop downs.

5. Label as a tool tip

Label as a tool tip"

Advantages

  • Allows for different label lengths when form is translated into other languages.
  • Form is somewhat narrower compared to having labels beside fields.
  • Labels are visually associated with their corresponding fields, so it easy to see which goes with which.
  • It’s easy for users to see where they have to enter information.

Disadvantages

  • Atypical design, so likely to confuse and frustrate users.
  • Breaks the conversational pattern that is central to successful form filling: ask the question before collecting the answer.
  • On small screens, when focus is in-field, label may not be visible.
  • User unlikely to be able to see the label and the field within one glance.
  • When form is translated into other languages, labels may no longer fit into allocated space.
  • Form is somewhat wider compared to having labels above fields.
  • Labels are impossible to scan as they are hidden.
  • If label disappears completely once the field is being filled out, the user has to remember what the label was, and will be derailed by interruptions.
  • If label disappears completely once the field is being filled out, the user can’t later compare their answers to the labels.
  • Difficult to implement well.
  • Reduces accessibility.
  • Doesn’t work with field types other than text boxes and possibly drop downs.
  • Doesn’t work well with touch interfaces.

Deciding on position

Even if you don’t actually read the text in the bullet points above, it’s clear that there are many more disadvantages than advantages for:

  • label inside the field
  • label as a tooltip.

So in most cases, these are going to be poor choices. Instead, go with one of the following:

  • label on top of the field
  • label to the left of the field, and flush left
  • label to the left of the field, and flush right.

To decide between these three options, ask the following questions:

Question to ask about the form How answer impacts label positioning
Will this form be filled out on small screens? Best choice for small screens is label above field.
Will the form be accessed via touch? Avoid labels inside fields or as tool tips.
Are the labels mostly short? Labels beside fields works best when labels are short.
Are the labels full questions (e.g. “When do you want your new policy to start?”)? With full questions, labels can be either above or beside the field, but should be flush left.
Will the form be translated? Labels above fields gives the most flexibility for translation.
What types of fields does the form have? If there are fields other than text boxes, you can’t put labels inside fields. Labels as tool tips is also a poor choice.
What resources are available for development? Labels above fields take the least development time, closely followed by labels beside fields.
At what skill level are the developers? Labels inside fields or as tool tips should only be attempted by expert developers with plenty of time.

Consistency

Within a form

Like all elements of an interface’s design, consistency with label positioning helps users and minimises errors. This is because the brain is wired for patterns; when positioning is consistent the brain will rapidly learn where to look for labels. This means it’s best if you can stick just one approach per form.

Across forms

If users may encounter more than one form from your organisation, usability and accuracy are further aided by using consistent positioning across forms. Sometimes this means going for the next-to-best choice for an individual form, for the sake of overall usability.

For example, it may be that labels above fields are the ideal choice for the form you are currently working, but most other forms within your organisation work better with labels beside fields.

Summary

Form label positioning is a hotly-debated topic, with many people quick to declare one approach is a clear winner. In reality, the situation is more nuanced. But that doesn’t mean that deciding on positioning has to be hard. Using the questions and advantages/disadvantages above, you can easily determine what’s going to be best for your particular situation (and hopefully use that approach consistently).

What’s been your experience with label positioning? Are there any advantages and disadvantages that have been missed? Tell us in the comments.

Further reading


  1. Strictly speaking, other options include: putting the label to the right of or beneath the field; and float label, where the label begins inside the field but floats to the top of the field upon focus. For languages that read left to right, top to bottom, putting the label to the right of or below the field makes no sense. It would essentially mean questions are being asked after answers must be given. The float label approach has some of the benefits of putting the label above the field, but also some of the problems of putting the label inside the field. It has problems of its own too, namely: introducing unnecessary animation; and that the floated label is very small and thus hard to read.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • bl4de

    Great summary. I am web developer for 7 years now and to be honest I don’t think about labels in such way as you present here. I have to bookmark this article for further purpose :)

    • Formulate

      Glad I could help provide some food for thought and a useful reference.

  • http://jeditux.wordpress.com/ Fernando Basso

    Superb article. Thanks.

    • Formulate

      Glad you found it valuable.

  • Formulate

    That float label approach has a lot of promise and you’re right about it addressing some of the disadvantages of option #4. The size of the label after data entry concerns me a little, and I’d really like to see some data on rigorous usability and accessibility testing. But it’s an important step in the conversation. Thanks for sharing.

    • M S

      It seems very small to me too.

      I really hate when some of the text on a page is normal size, and some is microscopic.
      You end up having to zoom the whole page until it look sgrotesque.

      Anyone who does this, just wait until YOU also are over 40, then you will get your comeuppance…

      • Mike Ritter

        True! And don’t forget line-spacing.

  • Sai Pc

    Beautiful article, a lot of people dont even think twice before designing forms, they think that only having the fields and labels is enough, but this article shows that even minute changes can have large impact on the user base..thank you :) +1

    • http://alfy.me/ Ahmad Alfy

      > a lot of people dont even think twice before designing forms

      I upvoted you for this. As a frontend developer I have had a lot of bad days because of people like these

      • Formulate

        Thank you, Sai and Ahmad, for your feedback. Glad you liked it!

  • M S

    But what about having the label to the right of the field, flush left?

    |_________| Last Name
    |_________| Age
    |_________| Preferred hat-size (*required)

    This way everything aligns nicely, even when you mix very short and very long labels.
    And it easy to scan both columns.

    This used to be popular a couple of years ago, but you never see it, or even see it mentioned in articles like this one, now.

    • Mike Ritter

      still one of my preferences

  • M S

    I really hate the stupid fashion with pre-filled fields that are supposed to be labels.
    Especially when combined with bad evaulation.

    SO many times i try to submit a form, and it complains that i haven’t filled in everything,
    yet ALL the fields clearly has content in them.
    …but of course some content is one of those fake labels.

    • Alex Walker

      I’m not defending this practice, but I would have thought most form feedback indicates which field isn’t filled. As in “You didn’t enter your *surname*”. Ideally it visually highlights the offending field too.

      Regardless, it certainly takes more ‘cognitive petrol’ to read that message and then relate it back to the form field.

      • M S

        Yes, if its done right its less of a problem.

        But often you have to go though at least one extra loop.
        clicking submit … page-load … “you didnt…” … etc.
        And, worst case, they require you to refill password or capcha too.

        The sites that do the labels wrong this way, are often the ones that do the evaluation wrong too.

  • Mike Ritter

    I’ll mix-and-match in an application: on top for mobile w/ full-width fields, inside for small fields (like a search form), left for full-width forms. I will say I dislike labels that are flush with their field because the jagged left edge is disorienting (would prefer placing it after the field).

    • Formulate

      Hi Mike. While some mixing of positioning is OK – e.g. many sites have labels inside fields for search, but labels outside fields for longer forms – every change you make will increase the burden on the form-filler and lead to worse outcomes for them and you. Thanks for commenting.

  • M S

    I don’t see how this would mean that you read right-to-left.
    You read the labels left-to-right, and any content in the fields left-to-right too.

    When a form is empty, the column with labels are the only thing you read.
    And when its filled it seems more natural to read whats filled in, and then check the label for a clue if its correct.
    For that use the label would need to be to the right, for it to not be called reading right-to-left then?

    And the world around us is filled with labels and signs that are to the right of the items they are for.

    And what about check-boxes and radio-buttons?
    There it seems much more popular to have the labels to the right.

    But more important, are there any actual tests that has been done?
    All the tests i have found only compare all the other variants except this one.

    • Formulate

      You make good points MS, but the main behaviour when filling a form is reading the label, then providing the data, reading the next label, then providing the next data, and so on. The layout you describe doesn’t support this direction of eye movement as much as labels above or to the left of the field.

      When it comes to radio buttons and check boxes and their labels, unfortunately we are stuck with a convention that was established when our faculties for laying out web pages were in their infancy. The paper form convention is for the check box label to be to the left of the checkbox (again, to support the left-to-right reading in English). Here we have convention overruling “ideal” design for usability. So it is for much of technology.

      Finally, I’d say sure, there may be other labels and signs in the world that are to the right of the thing they relate to. But they are not forms. Just as a poster’s layout doesn’t suit a novel, and vice versa, context and purpose should have a strong influence on our designs.

      Thanks for contributing to the discussion.

  • Tim Dawson

    Helpful article, and I do my best…But how best to cope when there are relatively short text inputs and radio buttons and then a far wider text area where there’s no room for a label on the left ? In my usage the label for a text area tends to be longer, too. I’ve compromised by putting that label on top.

    • Formulate

      Hi Tim. I’m not sure I understand the problem you’re describing. Could you post an illustration somewhere?

  • jono

    Good article. But what about the validation error messages too? At the side of the label, underneath the label or at the top of the form?

    • http://alfy.me/ Ahmad Alfy

      Great point, a lot of people don’t take that into account when they design forms.

      I think according to the space available to you. If it is a single column form with plenty of space on the side, it can be placed to the right of the field. If not, it could be placed below it. Yet, a lot of designers don’t pay attention to the vertical spacing and they design compact layouts that makes placing an error below the field a nightmare that could wreck the design. If so, a floating error message like label number 5 makes sense.

  • Formulate

    In the example you’ve shared, you’re following a label-above-the-field approach, which is fine.

    Perhaps there is some confusion between label for the *question* (which is above the field throughout that form) and the label for each *radio button or check box option* (which you have to the left of the field, also OK). My article was focusing on labels for questions, not radio button/check box labels.

    Also, the “Please add any comments in the box” is a *tip* not a label (the label is “Other information and Comments”). I hope to write something soon about placement of tips, but I think how it’s done in the example is fine. I might question the need for it, though, as the label is pretty self-explanatory.

    Finally, unless you’ve run usability testing on the form, be careful about concluding people don’t have problems completing it. Many people will quit a form before starting, just because of how it looks, and many others will have a great deal of trouble completing a form, but never complain about it. Both cases are quite “invisible” without usability testing.

    • Tim Dawson

      Thank you for your reply. It’s good to know my form doesn’t rate too badly. I take your point about knowing whether people have problems or not. All I can say is that quite a few of our guests volunteer that the booking process was easy. As a small B&B we can be full all season on less than 100 bookings, so the scope for usability studies is limited. Perhaps I should ask on the form ?

      • Formulate

        If you’re happy with the situation as it is currently — i.e. your form is getting you plenty of bookings — then I wouldn’t bother changing the form.

  • Shruti

    Thank you for this informative article. We assume these things to be obvious but by explaining their advantages and disadvantages was really helpful and a good argument was made. I was wondering how one would go about labeling a matrix of check boxes. I m struggling with 508 compliance regarding labels.

    Anybody who can answer this, please go ahead and reply on this thread.
    Thanks again !