How to edit CSS across responsive breakpoints
Fact-checked
Fix a layout at one width while keeping the other widths in view. Start with the rule that actually controls the element, then check both sides of its breakpoint.
A heading fits on a phone and desktop, but collides with a button on a tablet. Adding another media query might hide the collision. A better first step is to find which declaration wins at the failing width, change it, and see whether the surrounding layouts still work.
Open the failing width and its neighbors
Open your page in Responsive Tester and add viewports for the layouts you want to compare. Include the exact width where the problem appears. Device presets are a starting point; the bug may sit between them.
If the page changes layout at 768px, try 767px, 768px, and 769px, alongside a narrower phone and wider desktop. Those three neighboring widths help expose overlapping conditions and off-by-one assumptions. They are diagnostic samples, not a complete test of every possible width.
Site Breakpoints can create viewports from supported min-width and max-width media queries. Detection does not cover every media-query form and can miss inaccessible stylesheets, so keep any known project breakpoints in your test set too.
Find the rule that wins
Open the editor and select the element in the failing viewport. Read its matching rules before adding a new declaration. The editor marks overridden declarations, which helps distinguish a value that exists in the stylesheet from one that currently affects the element.
A media query determines whether its rules participate at a given viewport size. It does not guarantee they win. Another applicable rule, an inline style, or an important declaration may win. For an inherited property, check whether the element inherits its value from an ancestor or specifies its own value. An inherited value does not override a declaration applied directly to the element. See the CSS inheritance specification.
You can also use Chrome DevTools' Styles and Computed views to investigate the cascade. In Responsive Tester, the advantage is keeping the other layouts visible while you experiment.
Keep the change in the right scope
Consider this simplified layout:
.hero {
display: grid;
gap: 24px;
}
@media (min-width: 768px) {
.hero {
grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
gap: 48px;
}
}If the two-column layout feels too cramped, try changing the 48px gap to 32px inside that media query. In this example, the narrower layout keeps its 24px gap. Editing the base rule instead would change the narrow layout while leaving the wider gap overridden.
The query's min-width condition includes the threshold itself: this rule becomes eligible at 768px. MDN's media query reference explains the conditions and range syntax.
Responsive Tester sends the CSS edit across the open viewports. An existing-rule edit applies where the corresponding rule can be found; each viewport evaluates its media conditions independently. If a viewport loads different stylesheets or components, verify the change there separately.
Check more than the selected element
After the edit, look at the heading, neighboring controls, and the section below. A smaller gap may fix one collision while changing text wrapping or making another part feel crowded. Check the layout on both sides of the threshold and resize through the interval between your test widths.
If the change appears to do nothing, check these likely causes:
- The query is inactive. The current viewport does not satisfy its width or other conditions.
- A different declaration wins. Inspect the cascade before adding
!important; if you edited an ancestor, check whether the element overrides that inherited value. - The selector targets another element. Some sites render different components at different widths.
- The component uses a container query. Its layout may depend on an ancestor's size, not just the viewport. See MDN's container query guide.
Move the result back into your project
The Changes panel tracks your CSS edits so you can copy the rules you want to keep. Review the selector and media-query context, then apply the change to the corresponding source file in your project.
For a generated stylesheet, update the source that produces it. That may be a component stylesheet, a design token, or a utility class in a template. Pasting an override into compiled output can make it disappear on the next build.
Live edits do not save your repository files. Stylesheet-rule changes are saved locally and restored while using the trial or Pro. Copy the changes into your source, then disable Responsive Tester or discard its saved changes before reloading to verify the source fix. Standard undo and redo shortcuts are available while experimenting in the editor.
What you need
Live CSS editing is a Pro feature in Responsive Tester and is included in the seven-day free trial. Viewport setup, scroll sync, and breakpoint detection remain available on the free plan.
For the rest of your review, follow the responsive testing checklist. If you are still choosing a workflow, compare the responsive testing tools.