What's the difference between "resetting" and "normalizing" CSS?
Which would you choose, and why?TL;DR
A reset deliberately removes selected browser defaults so the application rebuilds them; normalization preserves useful defaults while reducing targeted inconsistencies. Neither is automatically required. Choose a maintained normalization stylesheet when broad native consistency is valuable, or a small documented reset when a design system intentionally owns those styles. Do not erase focus indicators, control affordances, headings, or list semantics without accessible replacements.
What's the difference between "resetting" and "normalizing" CSS?
Resetting and normalizing
| Approach | Intent | Tradeoff |
|---|---|---|
| Reset | Remove a chosen set of user-agent styles and establish a blank or project-specific baseline | The project must restore useful typography, spacing, controls, focus states, and other affordances |
| Normalize | Preserve useful user-agent behavior while correcting selected inconsistencies and documented browser bugs | The project accepts more native defaults and depends on the normalization stylesheet's scope and version |
“Reset” describes a strategy, not one standard file. A reset can range from a destructive * { margin: 0 } rule to a careful design-system baseline. Normalize.css is a particular open-source implementation of the normalization approach; inspect its current rules rather than treating its name as a platform guarantee.
A minimal application reset
Many applications need only a few intentional defaults:
html {box-sizing: border-box;}*,*::before,*::after {box-sizing: inherit;}body {margin: 0;}button,input,select,textarea {font: inherit;}img,video {max-inline-size: 100%;block-size: auto;}
Each declaration should solve an understood project problem. For example, inheriting form fonts improves typographic consistency, but native controls still need testing in each target browser and operating system.
Choosing and maintaining the baseline
Use normalization when content-heavy pages benefit from sensible native typography and the project wants targeted cross-browser corrections. Use a custom reset when a component library defines all relevant tokens and states and the team can maintain that baseline. Some teams combine a small reset with selected normalization rules.
Review the final cascade rather than stacking several resets. Avoid outline: none without an equally visible focus indicator, avoid all: unset on controls unless every lost behavior is rebuilt, and be careful when removing list styles because visual changes can affect how some browser and assistive-technology combinations expose list semantics.
After changing the baseline, test headings, lists, links, forms, validation states, dialogs, keyboard focus, forced colors, zoom, print output, and right-to-left content. The reset is shared infrastructure: a small mistake propagates to every page.
Further reading
- Normalize.css
- User-agent stylesheets in the cascade (MDN)
- Understanding Success Criterion 2.4.7: Focus Visible (W3C WAI)