Why you should avoid nesting in CSS?

Introduction

Let’s start by examining what CSS nesting looks like in practice. Nesting allows developers to write cleaner-looking code by embedding selectors within one another, mimicking the structure of HTML or preprocessor syntax like SCSS.

1
.card {
2
  padding: 1rem;
3

4
  .title {
5
    font-weight: bold;
6
  }
7

8
  &:hover {
9
    background: #f2f2f2;
10
  }
11
}

At first glance, nesting feels elegant, tidy, and almost magical — like a feature designed to solve many of our styling headaches. However, as the saying goes, “a wolf in sheep’s clothing” — and that’s exactly what CSS nesting can be. While it looks convenient, careless use of nesting can quickly turn your styles into a nightmare to maintain.

Why CSS Nesting Can Be Problematic

Let’s go through a few key reasons why nesting in CSS should be approached with caution:

1. Hard to maintain when nesting gets deep

The deeper your hierarchy goes, the harder it becomes to see where one style rule starts and another ends. Once your project grows, even a small structural change in the HTML can break multiple layers of nested CSS.

2. Difficult to override due to high specificity

Deeply nested selectors generate extremely high specificity, making overrides frustratingly complex. You’ll often find yourself writing even longer selectors — or resorting to the dreaded !important.

3. A fast track to “spaghetti” CSS

Nesting might look like a clean and organized way to structure your code, but it can quickly spiral out of control. When that happens, your stylesheets become a tangled mess that no one wants to debug or extend.

1
.page-container {
2
  background: #fafafa;
3
  padding: 2rem;
4

5
  .dashboard {
6
    display: flex;
7
    flex-direction: column;
8

9
    .sidebar {
10
      width: 250px;
11
      background: #222;
12
      color: white;
13

14
      .menu {
15
        list-style: none;
16
        padding: 0;
17

18
        .menu-item {
19
          padding: 0.75rem 1rem;
20
          border-bottom: 1px solid rgba(255, 255, 255, 0.1);
21

22
          a {
23
            color: inherit;
24
            text-decoration: none;
25

26
            &:hover {
27
              color: #4ade80;
28
            }
29

30
            .icon {
31
              margin-right: 8px;
32

33
              svg {
34
                width: 16px;
35
                height: 16px;
36

37
                path {
38
                  stroke: currentColor;
39
                  transition: stroke 0.3s ease;
40
                }
41
              }
42
            }
43
          }
44
        }
45
      }
46
    }
47
  }
48
}

This is the kind of pattern that looks neat while your project is small — but as soon as your app scales, things start to break. Styles begin to overlap, cascade unpredictably, and suddenly your “well-structured” CSS turns into a maintenance nightmare.

When Nesting Might Be Acceptable

Of course, nesting isn’t inherently bad. There are cases where using it makes perfect sense — as long as you do it deliberately and with clear boundaries in mind. Here are a few situations where nesting can be justified:

1. You’re working on a small project

For static websites, landing pages, or small internal tools that won’t grow much, nesting can make your CSS cleaner and easier to follow.

2. You’re the only developer on the project

When no one else needs to touch your styles, the risk of misusing nesting or introducing conflicts is much lower. You can afford a bit more flexibility.

3. You limit yourself to a maximum of two nesting levels

Anything beyond that usually leads to unnecessary complexity and unreadable code. Two levels are more than enough to preserve readability and logical structure.

Final Thoughts

Hopefully, this post made you pause for a moment and question how you approach CSS in your own projects. Nesting might look like a convenient ally at first, but without discipline, it can quickly turn into your worst enemy — one that silently undermines the maintainability of your entire codebase.