Line-Height Doesn’t Work As Expected On Inputs

Line-Height Doesn't Work As Expected On Inputs

While Chrome and Safari respect line-height val­ues on inputs, Firefox, Internet Explorer, and Opera do not. I found out about this when exper­i­ment­ing with this little :focus trick I recently discovered.

So why don’t all browsers behave the same way? Inconsistent beha­vior like this is very frus­trat­ing for a web designer. Ideally, I’d like all browsers to behave as Chrome and Safari do in this case and respect line-height val­ues on inputs. Unfortunately, this is not the case, although at least Firefox expli­citly 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 ‘nor­mal’ is unre­li­able as that depends on the typeface and can roughly range from 1 to 1.2. Each browser also renders ‘nor­mal’ slightly dif­fer­ently. See this art­icle by Eric Meyer for more information.

Now I assume that Firefox, Internet Explorer, and Opera don’t feel that it’s neces­sary to respect line-height on inputs because they only con­tain one line of text, and most of the time this is fine, but if you are work­ing with a strict baseline, or doing some­thing sim­ilar to the example I linked to earlier, then prob­lems arise.

So what can we do?

If we want reli­able input heights no mat­ter the browser, then we must declare a height as well as using line-height. This is import­ant; if we just used line-height, the res­ults would be incon­sist­ent as each of the browsers that don’t allow altered line-heights on inputs render the ‘nor­mal’ 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 men­tioned by Neil in the com­ments, when using height to deal with the issue, there is really no need to use line-height. This saves you from hav­ing to declare the same value twice, and also avoids a caret bug in webkit

Tweet this


  1. Neil Sweeney

    Interesting solu­tion and it works some­what, but one thing I keep find­ing is that it affects the text input fields and make it not line up with the rest of the fields in a par­tic­u­lar row.

    You can see my exper­i­ments here.

    What’s inter­est­ing is that remov­ing the line-height and keep­ing just height seems to work bet­ter, also in web-kit the “car­rot” isn’t weirdly miss-placed in the field (so from the very top of the input to the base-line) but rather dir­ectly in the middle. It’s a bit of an odd issue and I keep com­ing across somethings that change my mind up as to how it works, but the “No line-height” solu­tion (just using height) is best for align­ments sake; also means only set­ting one para­meter as apposed to two.

    I’ve been work­ing on this a lot as I’ve often found my self hard cod­ing in heights for input boxes but now in this “respons­ive” 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 feel­ing that the font-family used can affect the vertical-alignment and height of form inputs.

  3. Chris Bracco

    Thanks for stum­bling upon this. I’ve been noti­cing those dis­crep­an­cies for a while but simply haven’t had the time to exper­i­ment. You rock.

  4. Josh

    Thanks for your very inter­est­ing com­ment, Neil. In regards to your exper­i­ment­a­tion, you can fix the issue your hav­ing when using line-height by spe­cify­ing a ver­tical align­ment (e.g. vertical-align: top;). But this begs the ques­tion, why use line-height at all?

    There are a couple of reas­ons not to (as you have men­tioned); the caret bug in Chrome, hav­ing to declare the same value twice (line-height and height), and needed to use vertical-align.

    In regards to hav­ing to use vertical-align, I would recom­mend using it any­way as it ensures that form ele­ments line up uni­formly. But in regards to line-height, I was only using it as that was the prop­erty I wanted to change, and it makes more sense when read­ing the code (and when using padding), but per­haps using height with a com­ment explain­ing why is the smarter way to go.