Every stylesheet that survives more than a few months tends to pick up the same handful of bad habits. A rule gets added wherever there was room, a media query grows without anyone reorganizing it, and somewhere in the middle is a selector nobody remembers writing. None of this happens because someone was careless. It happens because CSS formatting mistakes are small and easy to miss in the moment, and they only become obvious once they have already piled up.
Below are the mistakes that show up most often across real stylesheets, why they cause more trouble than they look like they should, and what actually fixes them.
None of these are exotic edge cases. They are the same handful of habits repeating themselves across beginner projects and production codebases alike, which is exactly why recognizing them is most of the battle.
1. Inconsistent Indentation Within the Same File
This is the most common issue by a wide margin, and it rarely happens on purpose. A developer starts a stylesheet with two-space indentation, then pastes in a component from a different project that uses four spaces, and now half the file lines up differently than the other half.
The result looks like this:
.card {
padding: 16px;
border-radius: 8px;
background: #fff;
}
Nothing here is technically broken. The rule still applies correctly. But the inconsistent indentation makes it harder to trust the visual structure of the rest of the file. Once you stop trusting indentation, you stop relying on it, which defeats the entire point of formatting in the first place.
2. Missing Semicolons
CSS is unusually forgiving about a missing semicolon on the very last property in a rule, which is exactly why this mistake keeps happening. It works fine, right up until someone adds a new property after it.
Consider this:
.button {
color: white
background: #2d6cdf;
}
Without the semicolon after
white, the browser reads
color: white background: #2d6cdf; as a single, invalid declaration, and the entire rule silently fails. Always terminating every property, including the last one, avoids this trap entirely.
3. Unclosed or Mismatched Braces
A missing closing brace on one rule does not just break that rule. It breaks every rule that comes after it, since the browser assumes everything following is still part of the original selector.
.header {
background: #111;
color: #fff;
.nav {
display: flex;
}
Here, the missing closing brace on
.header means the
.nav rule gets absorbed into it instead of standing on its own. This is one of the CSS syntax errors that a formatter will not catch, since a formatter just indents whatever structure it detects. Catching this reliably requires a dedicated CSS validator.
4. Mixing Tabs and Spaces
This one is sneaky because it looks perfectly fine in your own editor. Your editor renders a tab as, say, four spaces wide, so everything lines up. Then a teammate opens the same file with their tab width set to two, and suddenly nothing lines up the way you intended.
There is no universal fix here beyond picking one, spaces or tabs, and applying it consistently across the whole project. Most teams settle on spaces specifically because they render identically no matter whose editor is doing the rendering.
5. Cramming Multiple Properties Onto One Line
Fine for a two-property rule. A real problem once a selector accumulates eight or ten properties squeezed together.
.badge{display:inline-block;padding:4px 8px;border-radius:4px;font-size:12px;font-weight:600;color:#fff}
Nothing about this is invalid. It is just dense enough that a quick glance does not tell you anything useful. Breaking each property onto its own line costs almost nothing and pays off every single time someone else has to read the rule.
6. Duplicate Selectors Scattered Across the File
Writing
.card in three separate, unrelated places throughout a stylesheet is a subtle formatting issue that has nothing to do with indentation and everything to do with organization.
When a selector’s styles are split across a file, changing that component means hunting through multiple locations, and it becomes genuinely easy to update one occurrence while forgetting another. Grouping related rules together, ideally near other styles for the same component, keeps the actual source of truth for any given element in one predictable place.
7. Inconsistent Spacing Around Selectors and Braces
Mixing
.card{ with
.card { throughout the same file makes a stylesheet look careless even when every rule is technically valid.
.card{padding: 12px;}
.title {
font-size: 18px;
}
Small inconsistencies like this add up across a file. They do not break anything, but they make the whole stylesheet read as though nobody was paying close attention, which tends to be a fair impression of what actually happened.
8. Formatting Minified CSS and Shipping It That Way
Every so often, someone pulls a minified production stylesheet to debug a live issue, formats it to actually read what is going on, fixes the problem directly in that formatted version, and pushes it without thinking about the fact that the file is now carrying unnecessary bytes.
The fix is mostly procedural: keep beautified CSS in your source files, and let a build step or a minifier handle compression before anything actually deploys. It is an easy mistake to make once and a hard one to notice until someone checks page weight later.
It usually happens under time pressure. Someone is debugging a live styling issue, pulls the production CSS to inspect it, formats it to actually read what is going on, fixes the problem directly in that formatted version, and pushes it without thinking about the fact that the file is now larger than it needs to be.
9. Over-Specific Selectors That Fight the Cascade
Not every formatting mistake is about spacing. Sometimes the structure itself creates problems, even when the indentation is perfectly clean.
body div.container ul.nav li a.active {
color: #2d6cdf;
}
A selector chain this long is technically valid and will format just fine, but it is difficult to override later and hard to reason about at a glance. This is really a structural mistake more than a pure formatting one, but it has the same effect: even perfectly indented CSS is harder to work with when the underlying selectors are unnecessarily complicated.
10. Assuming a Formatter Fixes Broken CSS
This one trips up a lot of people, understandably. You paste messy CSS into a formatter, get back a clean-looking result, and assume the underlying code must be correct now too.
It is not necessarily. A formatter organizes whatever structure it finds, including broken structure. If your original file had a missing brace or an invalid property, the formatted version will still have that same problem, just tidier looking. Formatting improves appearance. Validation checks correctness. They are not the same job, and relying on one to do the other’s work is how bad CSS code slips through looking perfectly innocent.
11. Never Running Old Stylesheets Back Through a Formatter
New rules tend to get written with reasonable care. Old stylesheets, written months or years ago under a different set of habits, often just get left alone. Nobody wants to be the person who touches a working file just to reformat it.
The problem is that inconsistency compounds. Every new rule that follows a slightly different convention than the old ones makes the stylesheet as a whole a little harder to navigate. Periodically revisiting older files, especially ones that get edited frequently, keeps a project from drifting into a patchwork of competing styles.
12. Leaving Off Units on Numeric Values
CSS is inconsistent about when a unit is actually required, and that inconsistency trips up even experienced developers occasionally. A property like
margin needs a unit even when the value is meant to look like zero-adjacent spacing, while a property like
z-index or
opacity never takes one at all.
.card {
margin-top: 10;
opacity: 0.8px;
}
Both of these lines are invalid. The first is missing a unit where one is required, and the second adds a unit where none belongs. Neither will cause an error message. The browser simply ignores the invalid declaration and moves on, which means the mistake often goes unnoticed until the layout looks slightly wrong for reasons that are not obvious from a glance.
13. Comments That Do Not Explain Anything Useful
Comments exist to add context the code itself does not already provide. Somewhere along the way, plenty of developers pick up the habit of littering stylesheets with comments that just restate what the selector already says.
/* card styles */
.card {
padding: 16px;
}
That comment tells you nothing you could not already see from the selector itself. A file full of noise like this trains readers to skip over comments entirely, which means the one comment that actually matters, explaining why a strange override exists, gets skipped right along with it.
Formatting Issues vs. Actual Syntax Errors
It is worth drawing a clear line here, because the two get lumped together constantly. A formatting issue, like inconsistent indentation or cramped spacing, does not break anything. The styles apply exactly the same either way. A genuine syntax error, like an unclosed brace or a missing colon, can actually cause part of a stylesheet to be ignored or misapplied entirely.
Running your code through a
CSS Formatter cleans up the first category instantly. Catching the second category reliably requires a dedicated CSS validator, which checks your stylesheet against actual syntax rules rather than just tidying up appearance. Most experienced developers use both, not because one replaces the other, but because they catch entirely different things.
A Quick Way to Catch These Before They Spread
None of the mistakes above require much effort to avoid once they are on your radar. Running a stylesheet through a formatter before committing it, terminating every property with a semicolon even the last one, and occasionally glancing back at older files are all small habits. They just have to happen consistently to actually matter.
A five-minute pass with a formatter now is almost always cheaper than the twenty minutes someone will spend tracing a styling bug through inconsistent, unclosed, or duplicated rules later. That trade-off is really the whole argument for caring about this in the first place.
If you are working on a team, it is worth putting these habits somewhere more permanent than good intentions. A short pre-commit check, a shared editor configuration, or just a line in your project’s readme covering indentation and spacing preferences removes the need for anyone to remember the rules on their own.
The Same Habits Apply to Your HTML
CSS formatting mistakes rarely exist in isolation. If a stylesheet has drifted into inconsistency, the markup it styles has often drifted right along with it. Running both through their respective tools, this
CSS Formatter for your styles and ToolMato’s
HTML Formatter for your markup, catches both sides of the same problem at once.
Frequently Asked Questions
What is the most common CSS formatting mistake?
Inconsistent indentation is by far the most frequent issue, usually caused by pasting styles from multiple sources that each used a different indent size within the same file. It rarely happens all at once, it tends to build up file by file.
Can bad CSS formatting actually break a website?
Formatting itself, like spacing and indentation, will not break a page. Genuine syntax errors, like an unclosed brace or a missing semicolon before a new property, can cause part of a stylesheet to be misapplied or ignored entirely.
How do CSS indentation errors affect debugging?
They make structural problems much harder to spot. A missing closing brace or a misplaced property is often obvious in properly indented CSS and easy to miss entirely in a file with inconsistent or missing indentation.
Does a formatter catch CSS syntax errors?
Not reliably. A formatter organizes indentation based on the structure it detects, even if that structure is technically broken. For catching actual syntax errors, a CSS validator is the right tool.
Is it a mistake to mix spacing styles around selectors and braces?
It is not invalid, but it is inconsistent, and inconsistency across a file makes code noticeably harder to scan. Picking one style and sticking with it is worth the small effort.
Why does mixing tabs and spaces cause formatting issues?
Because tab width is not fixed. It renders differently depending on each person’s editor settings, so a file that looks aligned in your editor can look completely broken in someone else’s.
What is the difference between a formatting issue and a syntax error?
A formatting issue affects readability without changing how styles are applied. A syntax error means the CSS does not follow correct rules, which can actually cause part of a stylesheet to be ignored by the browser.
How often should I check my CSS for formatting mistakes?
Ideally before every commit, or at minimum whenever you paste in styles from an external source. Catching inconsistency early is far less work than untangling it after it has spread across multiple files, and it takes only a moment once it becomes routine.
Can duplicate selectors be considered a formatting mistake?
It is more of an organizational habit than a pure spacing issue, but it has the same effect: even perfectly indented CSS is harder to maintain when a component’s styles are split across several unrelated locations.
Is clean CSS the same as valid CSS?
Not necessarily. Clean CSS is easy to read because of consistent formatting. Valid CSS follows correct syntax rules. A file can technically be one without fully being the other, which is why both formatting and validation are worth doing.
Most of the mistakes on this list are not hard to fix individually. What makes them costly is how quietly they build up when nobody is paying attention. Catching them early, ideally before code ever gets committed, is a lot less painful than untangling a stylesheet that has been accumulating bad habits for a year.
If you have a stylesheet that has been bothering you for a while, running it through ToolMato’s
CSS Formatter is a fast way to see exactly how far it has drifted.