Line-Height Doesn’t Work As Expected On Inputs

Line-Height Doesn't Work As Expected On Inputs

This post will take 1 minute to read.

While Chrome and Safari respect line-height values on inputs, Firefox, Internet Explorer, and Opera do not. I found out about this when experimenting with this little :focus trick I recently discovered.

So why don’t all browsers behave the same way? Inconsistent behavior like this is very frustrating for a web designer. Ideally, I’d like all browsers to behave as Chrome and Safari do in this case and respect line-height values on inputs. Unfortunately, this is not the case, although at least Firefox explicitly state what they will be doing in their user agent style sheet:

input {
    line-height: normal !important;

Who has the time to look through each browser’s user agent style sheet though? Also, using the value ‘normal’ is unreliable as that depends on the typeface and can roughly range from 1 to 1.2. Each browser also renders ‘normal’ slightly differently. See this article by Eric Meyer for more information.

Now I assume that Firefox, Internet Explorer, and Opera don’t feel that it’s necessary to respect line-height on inputs because they only contain one line of text, and most of the time this is fine, but if you are working with a strict baseline, or doing something similar to the example I linked to earlier, then problems arise.

So what can we do?

If we want reliable input heights no matter the browser, then we must declare a height as well as using line-height. This is important; if we just used line-height, the results would be inconsistent as each of the browsers that don’t allow altered line-heights on inputs render the ‘normal’ value slightly differently.

So while this won’t work in Firefox, Opera, or Internet Explorer:

input {
    line-height: 2;

This will:

input {
    line-height: 2;
    height: 2em;


As mentioned by Neil in the comments, when using height to deal with the issue, there is really no need to use line-height. This saves you from having to declare the same value twice, and also avoids a caret bug in webkit

Tweet this


  1. Neil Sweeney

    Interesting solution and it works somewhat, but one thing I keep finding is that it affects the text input fields and make it not line up with the rest of the fields in a particular row.

    You can see my experiments here.

    What’s interesting is that removing the line-height and keeping just height seems to work better, also in web-kit the “carrot” isn’t weirdly miss-placed in the field (so from the very top of the input to the base-line) but rather directly in the middle. It’s a bit of an odd issue and I keep coming across somethings that change my mind up as to how it works, but the “No line-height” solution (just using height) is best for alignments sake; also means only setting one parameter as apposed to two.

    I’ve been working on this a lot as I’ve often found my self hard coding in heights for input boxes but now in this “responsive” day and age I feel that I need to be a lot more relative.

  2. Neil Sweeney

    Sorry, should note also that I have a feeling that the font-family used can affect the vertical-alignment and height of form inputs.

  3. Chris Bracco

    Thanks for stumbling upon this. I’ve been noticing those discrepancies for a while but simply haven’t had the time to experiment. You rock.

  4. Josh

    Thanks for your very interesting comment, Neil. In regards to your experimentation, you can fix the issue your having when using line-height by specifying a vertical alignment (e.g. vertical-align: top;). But this begs the question, why use line-height at all?

    There are a couple of reasons not to (as you have mentioned); the caret bug in Chrome, having to declare the same value twice (line-height and height), and needed to use vertical-align.

    In regards to having to use vertical-align, I would recommend using it anyway as it ensures that form elements line up uniformly. But in regards to line-height, I was only using it as that was the property I wanted to change, and it makes more sense when reading the code (and when using padding), but perhaps using height with a comment explaining why is the smarter way to go.