A modern alternative to CSS resets

  • By Nicolas Gallagher
  • Last update: Jan 3, 2023
  • Comments: 16


Normalize Logo

A modern alternative to CSS resets

npm license changelog gitter


npm install --save normalize.css


See https://yarnpkg.com/en/package/normalize.css


See https://necolas.github.io/normalize.css/latest/normalize.css

What does it do?

  • Preserves useful defaults, unlike many CSS resets.
  • Normalizes styles for a wide range of elements.
  • Corrects bugs and common browser inconsistencies.
  • Improves usability with subtle modifications.
  • Explains what code does using detailed comments.

Browser support

  • Chrome
  • Edge
  • Firefox ESR+
  • Internet Explorer 10+
  • Safari 8+
  • Opera

Extended details and known issues

Additional detail and explanation of the esoteric parts of normalize.css.

pre, code, kbd, samp

The font-family: monospace, monospace hack fixes the inheritance and scaling of font-size for preformatted text. The duplication of monospace is intentional. Source.

sub, sup

Normally, using sub or sup affects the line-box height of text in all browsers. Source.


By default, Chrome on OS X and Safari on OS X allow very limited styling of select, unless a border property is set. The default font weight on optgroup elements cannot safely be changed in Chrome on OSX and Safari on OS X.


It is recommended that you do not style checkbox and radio inputs as Firefox's implementation does not respect box-sizing, padding, or width.


Certain font size values applied to number inputs cause the cursor style of the decrement button to change from default to text.


The search input is not fully stylable by default. In Chrome and Safari on OSX/iOS you can't control font, padding, border, or background. In Chrome and Safari on Windows you can't control border properly. It will apply border-width but will only show a border color (which cannot be controlled) for the outer 1px of that border. Applying -webkit-appearance: textfield addresses these issues without removing the benefits of search inputs (e.g. showing past searches).


Please read the contribution guidelines in order to make the contribution process easy and effective for everyone involved.




  • 1

    "IE8+" version of normalize.css

    I've got a version of normalize.css that removes legacy browser support. This would not affect the ability to download the existing version of normalize.css. I'm looking for:

    • Feedback on how much this non-legacy version is wanted now
    • Feedback on the specifics of the proposal below

    Intended browser support

    • Chrome
    • IE 8+
    • Safari 5+
    • Opera (latest)
    • Firefox 4+ (in practice, latest few versions)
    • Mobile Safari
    • Other common mobile browsers that should be catered for

    In essence, dropping IE 6/7, Safari 4, and Firefox 3.x

    Plan of attack

    • ~~Tag existing normalize.css as 1.0.0~~
    • ~~Use semantic versioning going forward~~

    I'd like to avoiding modifying 1.0.0 as much as possible in the future, and plan around how I'd like to manage the project 12-24 months down the line (i.e., not with a "legacy" branch hanging around). So using tags feels simpler, and AFAIK, would still leave me the option of hotfixing version 1 if absolutely necessary.

    NOTE: Please avoid comments like "IE < 8 sucks, who uses that?".

  • 2

    input font: inherit also pulls in line height

    I have a search form where the parent element sets a line height to vertically centre the text in the form. The following rule brings that line height to the text inside the input in the form:

    button, input, optgroup, select, textarea { font: inherit; /* 1 */ }

    Perhaps this was overlooked? I don't think it's a great 'normalisation' as I don't think anyone would expect this particular aspect of the font style to come through. Perhaps we could be more specific and inherit just the font-face?

  • 3

    On the "Opinionated rules"

    I understand that Normalize isn't a classical CSS Reset but removing those that you call opinionated rules is harsh. It's 2017 everybody is setting their box sizing to border-box. Leaving the body margin? How many websites don't have this set to zero?

    For me Normalize is considered a reset for the non useful stuff like the body margin and a way to make the different browsers behave consistently. I don't really like the new update and I am sure that there are a lot who disagree with it.

    Currently the stuff that I could spot was:

    • removing box-sizing setting to border-box
    • removing setting the body margin to 0
    • removing setting the font family to sans-serif

    I wonder if you can share with us a more detailed list of the removed features. For now I think I am sticking the projects I am working on to version 5.0 and I am sure that the frameworks that depends on Normalize will do the same.

  • 4

    Global line-height rationale, semver strategy revision

    What's the rationale behind html { line-height: 1.15 }? I thought it was supposed to be just the headings? And wouldn't such a drastic change warrant a major version bump?

  • 5

    font-family: -apple-system,system-ui,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,sans-serif

    It's time to add: font-family: -apple-system,system-ui,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,sans-serif

    This solution is harmless and very useful. It is used by GitHub, Wordpress, Bootstrap, Medium, Ghost, etc.

    The main reason for using "system" fonts is performance. Fonts are typically one of the largest/heaviest resources loaded on a website. If we can use a font already available on the user’s machine, we can completely eliminate the need to fetch this resource, making load times noticeably faster. The beauty of system fonts is that it matches what the current OS uses, so it can be a comfortable look.

    • -apple-system targets San Francisco in Safari (on Mac OS X and iOS), and it targets Neue Helvetica and Lucida Grande on older versions of Mac OS X. It properly selects between San Francisco Text and San Francisco Display depending on the text’s size.
    • system-ui represents the default UI font on a given platform.
    • BlinkMacSystemFont is the equivalent for Chrome on Mac OS X.
    • Segoe UI targets Windows and Windows Phone.
    • Roboto targets Android and newer Chrome OS. It is deliberately listed after Segoe UI so that if you’re an Android developer on Windows and have Roboto installed, Segoe UI will be used instead.

    The bottom line: It's truly the ultimate solution for any website/webapp in any OS.

    More info

  • 6

    TextArea in Chrome has 2px more than in other browsers

    Can you maybe somehow normalize/fix this. This is realy bad.

    <input type="text" style="width: 200px">
    <textarea style="width: 200px"></textarea>

    Looks great in IE, both boxes have the same length, but in Google Chrome the textarea has 2px more width ;(

    Best regards

  • 7

    Normalize headings

    I'm considering normalizing headings in some way after all. Mainly because I caught myself out while developing a project which used HTML5 elements, because of the way modern Firefox and Chrome resize h1 (coincidently to the size I needed) when nested within sectioning elements...while other browsers do not.

    It would be pretty simple, just use the existing defaults and it will override the -webkit-any() / -moz-any() rules and kill off h1 resizing in sectioning elements. But then one might as well normalize all the headings and margins too, I suppose. It's likely that every project is going to modify these styles to match the design.


    h1 {
        font-size: 2em;
        margin: 0.67em 0;
    h2 {
        font-size: 1.5em;
        margin: 0.83em 0;
    h3 {
        font-size: 1.17em;
        margin: 1em 0;
    h4 {
        font-size: 1em;
        margin: 1.33em 0;
    h5 {
        font-size: 0.83em;
        margin: 1.67em 0;
    h6 {
        font-size: 0.75em;
        margin: 2.33em 0;
  • 8

    Normalize body background

    Not sure if this issue is within normalize.css' idea but nevertheless. I suggest that body gets background: white because by default, or at least in Firefox it's transparent. This means it's filled with system-default color (clWindow?) which by default is white but depends on user's theme. I was surprised when a visitor sent me a screenshot with my design filled with gray instead of white which made the page look entirely different.

  • 9

    [role="button"] should be styled with cursor:pointer

    At the very least, [role="button"] should be styled with cursor: pointer, but I think it would make sense to style other elements the same way, for example:

    select {
        cursor: pointer;

    If menu was considered in nomalize, then we could also add menuitemin there.

  • 10

    Break into parts

    Might be worth building the normalize.css file from several parts. Perhaps web components would want to import the section of styles their component needs normalized as a base.

  • 11

    How to unset opinionated outline-width rule?

    Is there a way to unset this opinionated rule back to each browser's default value:

     * Remove the outline on focused links when they are also active or hovered
     * in all browsers (opinionated).
    a:hover {
      outline-width: 0;

    So far I haven't found a way (there is no 'auto'). If this is the case, please can we remove it?

  • 12

    summary element styling needs to be scoped to details element

    The current display style applied to the summary element results in unwanted list-item styling for instances where the summary element is not used properly.

    summary {
      display: list-item;

    This should rather be something like details > summary:first-of-type - which matches how modern browsers are treating the element.

  • 13

    Microsoft Edge adds extra margin to heading and paragraph elements

    I'm using Microsoft Edge version 107.0.1418.56 and I'm noticing it adds a couple of margin rules to just about any text element. Here's an unstyled <h2> as an example. See how there's a little bit of top and bottom margin?


    Just to double-check I opened the styles tab and yes, the "user agent stylesheet" added a couple of rules.


    I'm wondering if these rules should be added to normalize. If so, I'd be happy to create a PR.

  • 14

    Summary IOS sets the text color of buttons in the useragent stylesheet to blue. No other browser does this, and it should follow suit. Normalize.css should set the button to inherit the color from it's parent by default, similar to how other properties are done ie. font-family. I've added a screenshots to show that in our case, we're setting the base color to black, and then IOS safari is actually overriding that.

    Task Add color: inherit to the button tag to override the useragent styles applied by IOS

    image image

  • 15

    Change the link

    Hi, @necolas :wave:

    First thank you for this amazing package :heart_eyes:

    in your :link: blog article you referenced to the :link: normalize.css ghpage.

    What is Problem? Nothing, Just, Github page deployed to .io top level domain and and not in .com so... change to

    https://necolas.github.com/normalize.css/ :heavy_check_mark: https://necolas.github.io/normalize.css/

  • 16

    Firefox vs. Chrome

    When I use normalize.min.css v8.0.1 as my only css file for fairly ordinary HTML, I get different renderings for Firefox vs. Chrome.

    Here are the differences:

    font face (Arial vs. Times New Roman, I'm guessing), font size (possibly), and definitely overall zoom factor.

    Also, both show an extra top margin, although no margin at left. I looked at elements with dev tools, and cannot find any correction by normalize for the initial top margin. When I experiment with dev tools, I find that the rule "margin-top:-1.4rem" works perfectly to remove the top margin in FF.

    Normalize is a great idea, and I appreciate all your work, but I'm not seeing it working as expected on my Windows 10 Home 64 computer.