Guide
When SCSS nesting makes a selector too specific
Keep component styles predictable by checking the CSS selector that nesting actually produces.
Start with the essential
SCSS nesting can make a stylesheet easier to scan, but every extra level changes the selector that browsers receive. A rule that looks harmless inside a component can compile into a long selector that is hard to override later. The goal is not to avoid nesting; it is to keep the compiled selector as simple as the design needs.
Put it into practice
Use nesting when it represents a true relationship: a BEM element with &__, a modifier with &--, or a pseudo-state such as &:hover. Be cautious when adding layout wrappers and several descendant classes. A structure like .panel { .content { .card { .title { ... } } } } can become tied to one exact HTML shape, even when the title is reused elsewhere.
A detail worth checking
Check the compiled CSS before you accept a conversion. If the selector becomes much longer than the class you intended to style, move the reusable part back to its own block. This is especially important when an override requires !important or a second deep selector just to win the cascade.
Your next step
Use the CSS to SCSS Converter for a readable first draft, then review its output with this question in mind: would this compiled selector still be easy to find, reuse, and override six months from now?
Use this as a small, repeatable check rather than a one-time task.