The Best CSS Reset Stylesheets

Resetting your CSS to baseline property values is useful for gaining control, predictability, and uniformity with regards to how browsers render your HTML elements.

To learn about CSS resets in greater detail, see these articles:

If you’re looking for a stylesheet to help you reset your CSS, in my opinion, these are your top options right now:

Reset CSS

Reset CSS

Eric Meyer’s Reset CSS — this is the stylesheet that made CSS resets a mainstay. Reset CSS either nullifies a default CSS property by setting it to 0, or it sets the property to a common-sense value (e.g., line-height: 1 on the <body> element). Explicitly declaring certain CSS property values can help reduce inconsistencies in the way our HTML elements are rendered by the browser.

Related: Eric Meyer’s thoughts on CSS3

Note that Reset CSS was last updated in 2011. Many CSS reset stylesheets we’ll be talking about haven’t been updated in a while.

HTML5 Reset Stylesheet

HTML5 Reset Stylesheet

This reset stylesheet by Richard Clark is a modification of Eric Meyer’s Reset CSS. This CSS reset is geared towards modern HTML 5 elements. Other tweaks found in HTML5 Reset Stylesheet are the removal of a :focus pseudo-class reset and the use of attribute selectors to target the <abbr> and <dfn> elements in a way that minimizes the scope of their style rules.

CSS Mini Reset

This is a minimalist CSS reset by Vladimir Carrer. It only has four CSS style rules. It only resets the most frequently-used HTML elements — the ones you’ll actually use in your web development projects. Check out CSS Mini Reset on GitHub.

reset.css (from HTML5 Reset)

This stylesheet is part of the HTML5 Reset boilerplate. Its inception was inspired by three open source projects: Reset CSS, HTML5 Reset Stylesheet, and HTML 5 Boilerplate. This reset stylesheet is robust and opinionated. For example, it has specific style rules for the :before and :after pseudo-classes and it sets the box-sizing property to border-box, which your other options don’t do.



This CSS reset is a boilerplate stylesheet for small website development projects. For simple websites, such as one-page sites, you most likely don’t need to use a big front-end framework like Bootstrap. In these cases, Marx is an option to consider.

Specialized CSS Resets

These two CSS reset stylesheets are purpose-specific:


This is a baseline CSS reset just for Web typography. It’s geared towards text-heavy sites and web pages, such as blogs and news sites.

Note that Typeset.css will only work on HTML elements that are the children of an element with a class of typeset. So to implement Typeset.css, you’d need to do something like:

<div class="blog-post typeset">
  <h1>Blog Post Title</h1>
  <p>My blog post.</p>



This CSS reset stylesheet is extremely aggressive. It’s designed for use on content that will be distributed on another website, a scenario where your control over style rules is restricted. Cleanslate uses an !important declaration on all property values to force browsers not to follow normal cascading and CSS specificity rules. This gives you a fighting chance when it comes to overwriting the style rules of the third-party website.

CSS Normalization: A Modern Alternative

Browsers today are pretty good at setting appropriate default styles. Also, they now abide by modern standards and best practices. Default styles are now more predictable and consistent across the board.

So, instead of doing a blanket reset on all the default browser styles, we can instead focus only on specific HTML elements and CSS properties that aren’t being rendered uniformly in different browsers. We keep the other useful browser defaults.

That’s the main idea behind CSS normalization.

In other words, for our unstyled HTML elements, we implicitly let the browser or the normalization stylesheet set the style rules for us. This way, if we forget or don’t assign a style rule to an element, they will still render predictably and consistently across the various browsers.

One benefit of CSS normalization is it keeps our stylesheets DRY. We aren’t resetting an HTML element’s property values to 0, only to overwrite the property declarations farther down the cascade with another style rule.

Related: Should You Reset Your CSS?

Here are the top two CSS normalization stylesheets to check out:



This popular CSS normalization stylesheet is used in major sites like Twitter and GitHub, and is a dependency in big open source projects like Bootstrap and HTML5 Boilerplate. Normalize.css is the one that started it all.



This CSS normalization stylesheet is by Jonathan Neal, the co-author of Normalize.css. sanitize.css has style rules that will help you render HTML elements consistently in different browsers. This normalization stylesheet has a Sass version, which many developers will appreciate.

Further Reading

Related Content

Jacob Gube is the founder of Six Revisions. He’s a front-end developer. Connect with him on Twitter and Facebook.

This was published on Jun 1, 2015


Thanks for this! Very timely since the topic recently came up in a class.

CSS Lint was also suggested as a resource in that class and it seems like a good way to learn how to better edit a stylesheet. But I’m very confused by its recommendation to not use ID’s as selectors, since learning how to create and select ID’s is a fundamental focus for learning how to write CSS.

CSS Lint itself led me to this article:, which seems to summarize major issues — or at least raise flags of uncertainty for using the tool.

I found the tool mentioned here with other helpful info: If you have any opinions about its fine-grain recommendations, I would be interested to read more about it. I like this site a lot, very helpful, thanks!

    Jacob Gube Jun 01 2015

    Hi MB,

    CSS Lint isn’t a reset stylesheet. It’s a code-quality analysis tool. I’ve thought about covering CSS Lint’s suggestions before, but the project already does a good job of explaining the CSS Lint Rules.

    But to answer your question: The argument for not using ID selectors is that it’s not as flexible and maintainable as class selectors. You can only have 1 element per ID on the page. It’s harder to update your work when you’re using ID selectors and are relying on a certain HTML structure.

    In contrast, you can have an infinite amount of elements with the same class. So, in addition to flexibility and maintainability, a class selector theoretically has the ability to be more efficient in terms of the number of elements it can affect.

    Also, in CSS, there’s virtually no benefit* to using ID selectors versus class selectors.

    So the idea goes: Why not just make things easier for ourselves and use classes all the way?

    Not using ID selectors is just a suggestion. It’s not wrong to use ID selectors. In my view, as long as you fully understand the pros and cons of something, you should do what works best for you.

    I personally try not to use ID selectors. But there are some cases where that’s not always possible. For example, when I’m working on someone else’s markup, or I’m doing work on a CMS/e-commerce theme built by someone else, I find that I sometimes just can’t avoid using ID selectors. And, that’s alright.

    * There might be a slight performance difference between ID selectors and class selectors. But the difference is not compelling enough to be a cause for using ID selectors instead of class selectors, especially in sites with significant amounts of CSS–maintainability and flexibility that comes from using class selectors is more important in this particular scenario.

      Robert Smith Jun 08 2015

      I think it should be a rule not to use IDs in CSS. I am yet to see any circumstance where an ID is preferable to a class, there’s nothing a class cannot do that an ID can, apart from overriding another ID (ignoring !important).

      Like Crockford’s JavaScript the Bad Parts tells you never to use ‘with’ and ‘eval’, it’s the same here, never use IDs in CSS.

      Harry Roberts explains in further detail here:

Is there a performance penalty for using the * selector?

    Jacob Gube Jun 03 2015

    Do you mean performance penalty in terms of CSS selector speed? If there is, it’s probably minuscule, and it won’t be perceivable by your users.

    In other words, if there is a performance penalty for using the universal selector, it is most likely insignificant in the vast majority of cases.

    Thus, selector performance shouldn’t be the reason why you would not use the universal selector.

    There are more productive performance optimizations we can work on, such as lowering our CSS file sizes through minification. Or choosing high-performance CSS transitions and animations, because they can have an effect on the perceived performance of your UI. Some transition properties, for example, don’t render smoothly in certain browsers, and they make the UI feel slow.

    I’ll have to do actual tests to quantify my position on the universal selector speed. I have done some tests on CSS selector speed years ago. I’m particularly interested in seeing CSS selector performance on mobile devices, since I’ve done no tests on mobile.

    Even on older computers and older versions of web browsers, the universal selector’s speed-performance was not significant enough to be a deciding factor between using or not using it in my stylesheets.

    In the mean time, here are some links to check out:

    • CSS Performance Revisited: Selectors, Bloat and Expensive Styles — These tests show that the universal selector is not the slowest selector, and that selector speed varies across different browsers.
    • Performance Impact of CSS Selectors — If you’re interested in web performance, anything written by Mr. Souders is a great read. In this post, he says: “For most web sites, the possible performance gains from optimizing CSS selectors will be small, and are not worth the costs.” “Costs” in the context of Souders’s post is the amount of time and money you spend optimizing your CSS selectors.
    • CSS Selector Test — You can use this test on your browser to see the speed of several different CSS selectors. These results might vary on your machine versus mine. When I tested on Chrome version 43, there were quite a few selectors that were slower than the universal selector. Such as el el selectors like ul li or form input.

    There are plenty of reasons why I would not use the universal selector in my CSS. However, selector speed is not one of those reasons.

    Since this post is about CSS reset and normalization, I will list down some reasons why I do not recommend using a massive universal selector reset. But first, let me describe a very common scenario.

    A CSS author uses the following style rule to set all the margin and padding properties of all HTML elements to 0px:

    * {
      margin: 0px;
      padding: 0px;

    Then the CSS author adds back the margin and padding properties on HTML elements that should have them. Paragraphs, lists, blockquotes, and so forth.

    * {
      margin: 0px;
      padding: 0px;
    p {
      margin: 16px 0px;
    ol {
      margin: 16px 0px;
      padding-left: 40px
    li {
      margin-left: 5px;
      padding-left: 10px;
    blockquote {
      margin: 40px 16px;

    You can see several problems here:

    • You are removing useful default CSS properties on all HTML elements. If you forget to add back the margin/padding properties on an HTML element, or if you use some new HTML element that you haven’t styled yet, then you’ll run into rendering issues. In these cases, having the default margin/padding styles is probably better than having them at 0px. 0px margin/padding can affect UX. Particularly the reading experience.
    • Your stylesheet’s file size will most likely increase because you’re needlessly removing and then adding back CSS properties, which means more lines of code.
    • The stylesheet isn’t DRY. Removing something and then adding it back is redundant. Keeping stylesheets DRY goes a long way towards improving maintainability and scalability. A better option would be to explicitly set margin/padding property values, rather than removing them and then adding them back in.

    Still, given those issues, I’ll still use that type of universal selector reset in certain situations.

    For example, if I’m being lazy and/or a personal-project site I’m working is small and will only use basic HTML elements (like a simple one-page site), then I might still use a massive margin/padding reset for development speed, cross-browser consistency, and most of all personal convenience.

    Since this type of universal selector reset does not significantly impact performance — or, really, anything that our users care about — there’s no practical harm to using the universal selector in a vast majority of situations. I’ll use the time I save from not implementing a robust CSS normalization or reset stylesheet towards something more productive.

    There’s “best practice” and then there’s “practical practice”.

    Really, it all boils down to this: It depends on the situation. I know a lot of people dislike that sort of uncertainty. But I also don’t want to subscribe or advocate towards some sort of dogma. I want to do what works best when given a particular problem.

This comment section is closed. Please contact us if you have important new information about this post.