Responsive bugs often hide between the breakpoints teams remember to test. The layout works at 375, 768, and 1440 pixels, then fails in a 520-pixel card rail or a 980-pixel split pane.
That is a sign the breakpoint may be attached to the wrong thing.
Step 1: Resize slowly
Do not test only device presets. Drag the viewport or container slowly and watch where the layout first becomes awkward. Note the content width at the failure, not just the viewport width.
Step 2: Inspect the failing component width
A card inside a sidebar may have 280 pixels of inline space on a 1440-pixel desktop. A viewport media query cannot describe that local constraint.
If the component should change based on its own width, use a container query.
.rail-item {
container-type: inline-size;
}
@container (min-width: 28rem) {
.teaser {
grid-template-columns: 10rem minmax(0, 1fr);
}
}Step 3: Remove fixed assumptions
Look for fixed widths, unwrapped labels, and grid tracks that cannot shrink. A breakpoint may appear to fix the bug only because it moves the layout before the fixed assumption becomes visible.
Step 4: Test real states
Responsive behavior must survive:
- Long headings.
- Optional badges.
- Empty states.
- Loading text.
- Validation errors.
- Translated labels.
If a breakpoint works only with perfect content, it is not a reliable breakpoint.
Use fewer, better breakpoints
Global breakpoints should describe page-level structure. Component breakpoints should describe component space. Mixing those responsibilities is how responsive CSS becomes a pile of exceptions.