Open any HTML page without a single line of CSS, and you will still see styles applied: margins around paragraphs, bullets in front of list items, particular spacing around headings. These default styles, defined by each browser's internal style sheet, are not identical from one rendering engine to another.
CSS reset and CSS normalization are two answers to this problem, but they do not pursue the same goal. Confusing the two often leads to a choice that does not fit the project, or to an inconsistent mix of both approaches inside the same codebase.
Definition
A CSS reset is a style sheet you load before your own rules, and it removes, as much as possible, every default style applied by the browser. margin and padding are brought down to zero, font sizes are unified, and list-style is stripped from lists. Every element then starts from a neutral base with no inherited decoration, and it is up to you to rebuild every style from that blank slate.
Normalize.css, the historical reference for the second approach, follows a different philosophy: instead of erasing everything, it fixes inconsistencies between browsers while keeping the default styles that remain useful. A level one heading still keeps a larger font size than a paragraph, a bold element stays bold, but rendering gaps between Chrome, Firefox and Safari are smoothed out.
Why browsers ship different default styles
Every browser ships its own internal style sheet, invisible in the page source but very real, known as the user agent style sheet. Chrome, Firefox, Safari and the others each apply slightly different values for the margin of a body, the indentation of a bulleted list, or the native look of a button and a form field.
These differences trace back to the history of the web: each browser vendor made its own rendering choices before the standards settled down, and nobody benefits from breaking compatibility with millions of already published pages by changing those values afterward. As a result, the exact same HTML document can show sixteen pixels of space under a heading in one browser, and twenty pixels in another.
Reset or normalize: how to choose
The choice mostly depends on the nature of the project. A full reset suits a highly customized interface built with a strict component system like BEM, where every style is explicitly redefined anyway and the browser defaults add nothing useful. It is also the default choice of many utility frameworks, including Tailwind CSS's Preflight module, which applies a reset close to the one popularized by Josh Comeau, or by Eric Meyer before him.
Normalize.css, on the other hand, fits better on a site with rich text content where you do not want to start from scratch for every piece of typography: blog posts, documentation, editorial pages. You keep a coherent and readable base even before writing a single custom rule, which makes the result more forgiving if a component forgets to be styled.
| Criterion | Reset | Normalize |
|---|---|---|
| Goal | Erase everything to start from zero | Harmonize without removing everything |
| Useful default styles | Removed, to be rebuilt entirely | Kept and corrected |
| Rendering before your own styles | Completely bare page | Already readable and coherent page |
| Known example | Eric Meyer Reset, Tailwind Preflight | Normalize.css |
A minimal reset in practice
Most recent projects no longer use either of the two historical files as they are, but draw inspiration from a modern reset, shorter and designed for current CSS practices, in particular setting box-sizing to border-box on every element and removing the default margins on headings and paragraphs. Our HTML and CSS course starts every hands-on project with exactly this kind of short reset, to build the habit of working from a neutral base before writing a single custom style.
/* Minimal modern reset */
*,
*::before,
*::after {
box-sizing: border-box;
margin: 0;
padding: 0;
}
html {
-webkit-text-size-adjust: 100%;
}
ul,
ol {
list-style: none;
}
img,
picture,
video,
canvas,
svg {
display: block;
max-width: 100%;
}
input,
button,
textarea,
select {
font: inherit;
}Common pitfalls
An overly aggressive reset sometimes removes styles that served accessibility, such as the visible focus outline on links and buttons when navigating with a keyboard. If you remove that indicator without replacing it with your own focus style, you break keyboard navigation for part of your visitors, which is a real regression rather than a cosmetic detail.
Frequently asked questions
Yes, in a lighter form. Modern browsers are more consistent than they were ten years ago, but gaps remain around margins, lists and form elements. A short reset is still the most reliable way to start from an identical base everywhere.
It is not recommended. Both approaches modify the same properties with different values, and loading them together creates conflicts that are hard to debug. It is better to pick a single strategy and build your styles consistently on top of it.
Most modern frameworks, including utility frameworks, already bundle their own reset at startup. Check its documentation before adding a second one, or you risk duplicating that work needlessly and adding weight to your style sheet with no real benefit.