Is it good idea to put form labels inside input boxes? In this case, the labels slide out of the way when the user clicks on the box.

screenshot of sliding labels

See here live example of form


12 Answers 12


The sliding labels are completely gratuitous. Instead of sliding out of the way, why don't they simply stay out of the way all the time?

If there's not enough room for them to stay outside the field, they could stay in the field but disappear when you focus in the field.

Your sliding labels example suffers from the same problem as every other clever label-moving/fading hack: It doesn't work if you drag text into the field. Try it - what a mess.

  • 1
    The labels are a bit excessive, but I really like them. They're shiny. :) I'm sure there are some situations where they'd work well. Jul 7, 2010 at 9:09
  • 1
    @sgnewson - but they are not saving any space. Jul 7, 2010 at 11:31

In terms of evidence arguing one over the other? I don't know of any.

In terms of opinion/what I've seen...if data being entered is readily identifiable (ie, email addresses look like email addresses) then I'd say it's OK.

I've used it on very long forms to help visually shorten the appearance of the form but even then only in fields or groups of fields where the data becomes rather self-identifiable such as an address block. Apple uses this format in their checkout forms.

If you do go that route, be sure to use actual LABEL tags to retain full accessibility and then position them inside the fields via CSS and (likely) a bit of JavaScript. Do not pre-populate the field value.


At the time I wrote the answer, I wasn't aware of any data, but we recently had some user testing done and we came back with some surprising data. We found that there was an overwhelming majority that were indifferent to whether the labels were in the fields vs. above the field and that neither was significantly better/worse than the other.

Again, we're using it in very specific scenarios (namely blocks of data that can readily be identified via their contents) and we're not doing the sliding thing that was originally propose in this thread (which I agree is rather pointless). But we were surprised that it really didn't matter, at least in our test group.


Based on nathan's question, I should probably clarify the method we're using.

By default, we're rendering standard markup. That means a proper LABEL tag and input tag:

<label for="myField">Label Text</label>
<input type="text" id="myField"></input>

Then, via CSS we position the label on top of the input (which gives an appearance of the label inside the form field).

Via javascript onclick, we fade back the label and on key press, we hide is to one can type in their data.

If they delete the data, we return the the label.

In otherwords, we're not pre-populating a value in the input itself to act as a label...which is something I would recommend not doing.

  • Was anyone in your test group using a screen reader? Was there anyone who didn't speak English (Im assuming) as a first language? Might have changes your results a little bit... What if javascript is turned off? (The javascript issue alone could impact as much as 5% of your users)
    – Nathan-W
    Jul 9, 2010 at 21:23
  • 1
    We weren't testing accessibility, so will want to do that. However, we are using standard LABEL tags with proper FOR attributes, so they should work just fine with a screen reader. If no JS, it degrades fine into a standard Label-above-field.
    – DA01
    Jul 9, 2010 at 21:34
  • It saves space. - that's good
  • When you click on it, I assume the label disappears..one could forget what field it was after clicking (it happens). - that's bad.
  • It's a richer interaction - that's good.

I don't like the button labeled "Submit" personally. Unless it's a bondage S&M site.

Overall, I think it doesn't matter that much. Graphic designers should have it in their palette of choices.

  • and what about accessibility, screen reader point of view? Jul 4, 2010 at 17:35
  • "When you click on it, I assume the label disappears" no it will to outside the label, if JavaScript is enabled. see here example csskarma.com/lab/plugin_slidinglabels Jul 5, 2010 at 3:28
  • I havent seen that effect before. I like it.
    – Glen Lipka
    Jul 5, 2010 at 18:45
  • 7
    Hmm, I see, however I don't see the point, usability-wise. If the labels end up on the left side anyways you don't save any space and scnanning through a half-filled form will mean that you have to switch your gaze from left to right constantly to find out what to fill in the fields.
    – Jozef
    Jul 6, 2010 at 9:14
  • 5
    This is an example of overkill. Users need to see the labels when they are filling in the form, so hiding the label on focus isnt feasible, and moving the label removes any space saving. It would be a nightmare to design, and create all sorts of usability and accessibility issues. Just. Dont. Do. It.
    – Nathan-W
    Jul 6, 2010 at 20:39

1) My concern would be the label tags that aren't being shown. They technically could be styled way off screen so that screen readers use them but sighted users don't see them. They must be there linked to the ID, else they fail accessibility.

2) Glen's concern, that they have to be scripted to not show the value on focus, else for me, it fails

It looks clean, but you'd need to take the extra coding steps to make it usable and accessible. I'm OK with submit because most users have seen it over and over, but I prefer other terms.

  • If it is worth your while to answer a question, please consider voting for the question, too. Questions with more votes float to the top of the list, so more people will read your answer.
    – JeromeR
    Jul 6, 2010 at 4:38

The idea and many of the responses to it miss the point.

Users don't like forms. They only fill them out to get to something else: a product or a service. So our aim, as designers and developers should be to get them through the form as quickly, easily and painlessly as possible.

Research shows that people's behaviour when filling out forms is very different to other web-based interactions. Form-fillers are field focused (SlideShare presentation). They only look at surrounding text as much as they believe they have to, in order to be able to provide a good-enough answer.

This "sliding label" approach — as well as the placement of labels inside fields — hampers this user behaviour:

  • the field isn't empty, ready for them to fill out
  • they have to be distracted by the unnecessary animation, as they move between fields
  • they have to wait for the animation to be complete to be able to read the label.

Moreover, there is plenty of evidence — for example, "Don’t Put Hints Inside Text Boxes in Web Forms" on UX Matters — that people will often mistake the label for completed field, leading to loads of validation errors.

None of this even touches on all the implementation and accessibility issues.

In short, you might think it looks slick, sexy or cool, but it creates a worse experience for the user than current convention. So, unless you're designing or developing something just for yourself, you shouldn't consider it.

  • Then what do you say about HTML5 placeholder Apr 17, 2012 at 3:14

I don't think it's a good idea. The problem I see is that when the user finishes filling up the form and scans it for eventual errors, he won't be able to know which field meant what.

It is of course obvious for most of the fields, and would probably work without problems on simple forms, but on the more complicated ones it could be a potential issue.

Also, bear in mind that if you have anything else in the form besides text input fields, you will have to put labels on them. This will result in a loss of consistency. (If you have labels on left then there will be blank spaces and the user will have to shift the gaze from left to right to actually know what he is filling in. If you have labels on top then you will end up in a weird spacing between fields.)

  • Labels don't disappear, they slide off to the left - see the demo link: csskarma.com/lab/plugin_slidinglabels
    – Robin Balmforth
    Jul 5, 2010 at 15:14
  • 1
    When you answer a question but don't vote for the question, fewer site visitors will see the question—and your answer. Please consider voting for any question that you found interesting enough to read—and especially for those that you took time to answer.
    – JeromeR
    Jul 6, 2010 at 4:40
  • 3
    @robin in that sample, I find it a pointless bit of eye candy. If room still needs to be allotted for the labels along the left, why not just have them there in the first place?
    – DA01
    Jul 6, 2010 at 14:05
  • Versions I've seen/used fade-back the label on focus of the field, remove it upon commencing of typing, and put it back if you blank-out the field.
    – DA01
    Jul 6, 2010 at 14:06

Fad its not worth worrying about - put two identical form structures up, one with and one without and multi variant test for evidence in the specific site you want it to work in. If you see a higher completion rate with one you could claim, although its tentative at best, that’s the one you should go with.

Evidence is king here, I think it looks and feels a bit naff but that’s just subjective. If your users are lots of people like me you’re on to a looser. What would be really interesting is if you push the engagement beyond needing the form in the first place. But hay we must ask questions and a form seems like a simple way to do it.


I have seen an interesting approach here:



Here's an insightful article that talks about what you should do if you want to pull off putting labels inside textboxes successfully. Well-worth reading.



Quicken was the first application to use this technique. They used it for a fill-able check form.

I remember building a Delphi custom control to mimic this behavior back in 2002.

Personally, for the web, I don't like it, for the desktop, I don't see a problem with it.


I understand this question is more about theory and is probably looking for data supporting a answer, but I just wanted to add that if you do go for the ghosted, suggestive label, JLabel, a jquery plugin, will get you the functionality based on good standards with some nice added options (like a nice fade) so you can at least test it on your future/current users (which is probably the best way to answer your question anyway, right?)

Good luck :)


I like the clean aesthetic and visual mapping of putting a field's label right in the field itself.

I think this is great for reducing clutter and visual noise.

However, I have found that if the label is not always visible, somewhere, that some more inexperienced users/visitors will often get frustrated because there is nothing to visually remind them of what type of input is expected in the field that currently has focus.

So, since the label is critical only before the user clicks (or tabs) inside the form field, I solved my issue by simply moving the label, permanently to the right side of the form field. UNless they empty the field, in which case I simply move the label back to the left.

The text is lighter in color than the user's entered value and so it does not collide with the user input. This works only if you do not have form fields that are really narrow. Although, I have found that form fields using this technique are at least no longer than their traditional label-on-the-outside bretheren, so it does work in most cases.

As always, there is no one single solution for all cases... but I love the fact that my forms can now be much more visually organized and less cluttered.

Also, for those who are wondering right now about how to also tell the user what structure their input should take.... I ALWAYS make sure that I use javascript to take the weight of this from the user and put it where it should be... in code. I love letting people type in their phone number in any way they want, as long as there are enough digits to be a valid phone number, then why not do it in code and save the user the frustration of reading a small note of "Valid phone numbers must be (XXX) XXX-XXXX)"... blech.

Here is a link to a short form that shows what I am talking about.

It works for long forms as well, but then it will not work for ALL long forms.


  • @exoboy. Thanks for the answer. but if user's name or email will be longer than your available width , it will overwrite on form labels. after a good research I realized standard way is better uxmatters.com/mt/archives/2010/11/… Nov 2, 2010 at 3:23
  • As I said above, I am aware of this and the way I do it, it either does not overlap, or it allows the user's input t eclipse the label. Thanks for the comment, though.
    – exoboy
    Nov 2, 2010 at 6:04

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.