Debugging Layout Problems With DevTools

CSS layout bugs have a special quality: they're completely visible and completely opaque at the same time. You can see that the sidebar dropped below the content, that the page scrolls sideways on your phone, that a button is half-buried under the header. What you can't see is why — because the why lives in an invisible negotiation between margins, containing blocks, stacking contexts, and whichever of your 14 stylesheets won the specificity fight.

Browser DevTools make all of that visible. But most people use a small fraction of the layout tooling — right-click, Inspect, squint at some CSS — and then fall back to the ancient debugging technique of adding !important until something moves. This post covers the rest: a systematic workflow for the layout bugs that actually happen, with the specific panels and tricks that crack each one. Everything here works in Chrome, Edge, and (with minor cosmetic differences) Firefox, which has arguably the best layout inspectors of the lot.

First moves: inspect the right element and read the box model

Right-click the misbehaving thing and choose Inspect. Two easy mistakes happen in the first five seconds:

You inspected a child, not the culprit. Clicking text often selects an inner <span> or <a> when the layout problem belongs to a wrapper three levels up. Walk up the DOM tree in the Elements panel with the arrow keys, watching the highlight on the page, until the highlighted region matches the thing that's actually wrong.
You ignored the box model diagram. The Computed pane (and the bottom of the Styles pane) shows the rectangle-in-rectangle diagram: content, padding, border, margin. Hover each layer and it lights up on the page. Half of all "mystery gaps" are solved right here — that inexplicable space is an orange-highlighted margin from some reset you forgot, visible in two seconds once you look.

While you're there, learn to read the highlight colors when hovering elements in the DOM tree: blue is content, green is padding, orange is margin. A page can be debugged remarkably far just by hovering things and watching which color is doing the damage.

Styles vs Computed: finding out who did this

The Styles pane shows every rule that matches the element, ordered by specificity, with losing declarations struck through. The Computed pane shows the final answer for each property — and, crucially, has an arrow next to each value that jumps to the exact rule and file that set it.

The workflow for "why is this element like this":

Go to Computed, find the property with the surprising value (say, position: absolute you didn't write).
Expand it to see the winning rule and its source — theme.min.css:1, some plugin's stylesheet, an inline style injected by JavaScript.
Now you know who to fight and what specificity you need to beat.

Two power moves in the Styles pane that pay for the whole trip:

Edit live. Click any value and change it; click in the whitespace of a rule to add new declarations. You are prototyping the fix at zero cost. Nothing persists on reload, so experiment brutally — delete properties with the checkboxes, try display: none on suspects, binary-search your way to the culprit.
Force element states. The :hov button lets you pin :hover, :focus, and :active states on. Essential for debugging dropdown menus that vanish the moment you move your mouse toward DevTools.

On WordPress specifically: the Styles pane is where you discover the archaeology of your site — the theme's rule, overridden by the page builder's rule, overridden by something in Additional CSS, all fighting over one heading's margin. Seeing the whole stack is how you stop adding layers and start removing them.

The classic: "why does my page scroll sideways on mobile?"

Horizontal overflow is the most common layout bug on real-world WordPress sites, and it has a repeatable diagnosis. Something is wider than the viewport — the question is what. The usual suspects: an image or embed with a fixed pixel width, an element with width: 100% plus padding (without box-sizing: border-box), a negative-margin "full-width" section trick gone wrong, or an unbreakable long string (a URL in a comment is the classic).

Three ways to find the culprit, fastest first:

The console one-liner. Paste this into the Console:
[...document.querySelectorAll('*')].filter(el => el.scrollWidth > document.documentElement.clientWidth).map(el => [el, el.scrollWidth])
It lists every element wider than the viewport, widest offenders included. Usually the guilty element is immediately obvious in the list.
The delete method. In the Elements panel, delete nodes (press Delete on a selected element) top-down until the horizontal scrollbar disappears. The last thing you deleted contains your problem. Reload to restore everything.
Outline everything. Add * { outline: 1px solid red; } in the Styles pane's element.style or a new rule. Outlines (unlike borders) don't affect layout, and the element poking past the right edge becomes visible.

Do all of this in device toolbar mode (the phone icon, Ctrl/Cmd+Shift+M) at an actual mobile width like 375px — plenty of overflow bugs only exist below a breakpoint you never test at.

Flexbox and grid: stop guessing, turn on the overlay

When a flex or grid layout misbehaves — items won't align, something stretches weirdly, a column vanishes — the inspectors turn the invisible geometry into lines you can see.

In the Elements panel, any element with display: flex or display: grid gets a small flex or grid badge next to its tag. Click it. The browser draws the container's actual structure on the page: flex lines and item boundaries, or grid tracks, gaps, and line numbers. Firefox additionally names grid areas and shows line numbers beautifully.

What the overlay tells you instantly that squinting never will:

Whether the container is the size you think it is. Countless "flexbox is broken" bugs are actually "the container is only as wide as its content" bugs. The overlay draws the container's true bounds.
Which axis you're actually on. If justify-content is doing nothing, the overlay will show you the main axis runs the other way (flex-direction: column somewhere upstream). Align/justify confusion evaporates when you can see the axis.
Where grid items actually landed. With line numbers visible, "why is this in column 3" becomes a reading exercise instead of a guessing game.

Chrome's Styles pane also shows clickable icon editors next to display: flex/grid declarations — small grids of alignment buttons that apply justify-content, align-items, and friends live. It's the fastest way to try all nine alignment combinations in ten seconds.

Overlaps and z-index: the stacking context safari

Something's on top of something it shouldn't be, you set z-index: 99999, and nothing changed. This is the moment to know one fact: z-index only competes within the same stacking context. An element with z-index: 99999 inside a parent whose stacking context sits below another context will lose to a z-index: 2 in the winning context. It's not a bidding war; it's a bracket tournament.

Stacking contexts are created by more things than people expect: position plus a z-index, opacity below 1, transform, filter, will-change, and others. The debugging move: inspect the overlapping element, then walk up its ancestors in the Elements panel checking Computed styles for any of those properties. The first ancestor that creates a stacking context is the actual competitor — its z-index (not the child's) is what needs to change. That harmless transform: translateZ(0) a plugin added "for performance" is a classic hidden culprit.

Layout shifts and things that move on their own

If elements jump during load (and your CLS score shows it), Chrome's Performance panel can catch the shift in the act: record a page load, then look for the Layout Shift markers in the Experience row — clicking one highlights exactly which element moved and from where to where. The usual suspects, in order: images without width/height attributes, web fonts swapping in, embeds and ad slots expanding, and content injected above existing content by JavaScript. Knowing which element moved converts a vague score into a one-line fix like adding dimensions to an image.

A ten-minute triage checklist

For any layout bug, in order:

Inspect the element; walk up to the true culprit; read the box-model diagram.
Check Computed for the surprising property; follow the arrow to the rule that set it.
Prototype the fix live in the Styles pane before touching any file.
If it's overflow: run the console one-liner.
If it's flex/grid: click the badge, look at the overlay, check the axis.
If it's overlap: hunt the ancestor that creates the stacking context.
Reproduce at mobile width in device mode before declaring victory.

Then — and only then — write the real fix in your child theme or Additional CSS, with the minimum specificity that wins. The goal of the whole exercise is that your stylesheet gains one small, well-aimed rule instead of another !important layered on the pile. DevTools doesn't just find layout bugs faster; used this way, it stops you from creating the next three.

Photo: Daniil Komov on Pexels