Website looks fine on desktop but broken on mobile: how to find what’s different
I was updating a page I’d built from scratch, no page builder, just HTML and CSS, and the comparison table at the center of it looked exactly right on my laptop. Clean columns, clear headings, everything lined up. I sent the link to someone and they said it looked wrong on their phone. I pulled it up on my own phone and saw it: cramped, squished, cut off at the edges, requiring a horizontal swipe just to read the full row. Nobody wants to do that.
I felt stuck in a particular way with this one. A comparison table is inherently horizontal. That’s what it is. There are only so many ways to make something horizontal fit on a screen that’s vertical, and I couldn’t find an approach that showed all the data cleanly without forcing a user to scroll sideways. My first instinct was to hide the table entirely on mobile. I tried it. It worked in the sense that the problem disappeared, but the problem hadn’t actually been solved: the data still needed to be there, for anyone visiting on a phone.
What I eventually realized was that the fix wasn’t in the table itself. It was in understanding which CSS rules were controlling the layout at that width, where those rules came from, and what I actually had authority to change. That’s the diagnostic most explanations skip.
When I read articles about desktop-fine-mobile-broken, everyone seems to have it figured out. The fixes are listed as though they’re obvious, the causes are named as though they’re easy to spot. It made me feel like I was missing something everyone else understood. I don’t think that’s true anymore. I think the actual experience of hitting this problem, checking your phone, going back to the laptop, not being able to see the broken version while you’re trying to fix it, is harder than most explanations acknowledge. This post tries to name what’s actually happening.
Why the same page looks different on different screens
Most themes and stylesheets include CSS rules that change layout based on screen width. These are called media queries, and they fire automatically when the browser window is narrower than a specified breakpoint, typically somewhere around 768px for tablet and 480px for mobile. At those widths, a rule might hide an element entirely, change it from a horizontal layout to a vertical stack, reduce a font size, or override a width you set for desktop.
You didn’t write these rules. You didn’t see them get applied. But when the page loads on a phone, they fire, and whatever you built on desktop gets overridden by behavior you didn’t know existed. The element that’s missing on mobile isn’t broken. It has display: none applied to it by a rule at that viewport width. The section that won’t stack correctly isn’t broken either. A flexbox rule that works at 1200px is behaving differently at 375px because nobody constrained how it should wrap. The table that requires horizontal scrolling has a fixed pixel width that made sense on a wide screen and spills past the edge of a narrow one.
In every case, the rule causing the problem is in the CSS. The browser applied it correctly. The question is which rule, and where it came from.
Why this is so disorienting to diagnose
The broken version isn’t visible while you’re trying to fix it. You’re editing on desktop, the problem lives on mobile, and if you’re using a page builder, it’s showing you the desktop version. You can switch to a mobile preview, but the preview doesn’t always match the actual device. You end up going back and forth between your laptop and your phone, making a change, reloading, checking again, not always sure whether what you’re seeing is the real state of the page or a cached version.
I did this with the comparison table: laptop open, phone next to it, checking both, using the browser’s device simulator as a third reference point. The simulator was useful but not perfectly accurate. iOS Safari applies its own default styles that Chrome’s simulator doesn’t replicate exactly, so even with the simulator confirming something looked fixed, the actual phone sometimes disagreed.
Where to look first: your page builder’s mobile preview
If you built the page in Elementor, Divi, or another page builder, check whether the problem is visible in the builder’s own mobile preview before opening any external diagnostic tools. Switch to mobile view and look at the broken element. If the problem appears there, check whether the element has mobile-specific settings applied. Elementor lets you set different values for desktop, tablet, and mobile independently, and a value set correctly for desktop can have a conflicting entry set for mobile, sometimes accidentally, from an earlier edit.
If you find a conflicting mobile setting in the builder, clearing it usually resolves it. If the builder’s preview looks fine but the actual device still shows the problem, the rule is coming from somewhere outside the builder, which means you need to look at the CSS directly.
How to inspect the broken state in your browser
Open the page in Chrome on your desktop. Open developer tools (right-click anywhere on the page and choose Inspect, or press F12). Find the device toolbar at the top of the developer tools panel: it looks like a phone and tablet icon. Click it. Set the viewport width to 375px, which is a common width for modern phones, and check whether the problem appears. If it does, you’re now looking at the broken version in a context where you can inspect it.
Click on the element that looks wrong. In the Styles panel on the right, look for rules wrapped inside an @media block. These are the responsive rules. A rule inside @media (max-width: 768px) only applies when the screen is 768px wide or narrower, which is why it didn’t appear on your desktop but does on a phone. The rule controlling the breakage will be inside one of these blocks.
Note where the rule came from. The selector and source file appear next to each rule. A rule from your theme’s main stylesheet means the theme controls this behavior, and you’ll need a custom CSS override to change it. A rule from a plugin means a plugin is affecting layout at mobile widths in a way that conflicts with your design. If the rule is one you wrote yourself, at least you know where to change it.
If reading the Styles panel and tracing rule origins feels like work you don’t have the context to do, Loupely Lens handles this by capturing the full CSS state of any element you click, including which rules apply at the current viewport width and where each one came from, and telling you in real human terms what’s controlling the layout and why it looks that way at that width.
Website looks fine on desktop broken on mobile: the three usual causes
Most of these situations come down to one of three things.
First, a media query in a theme or plugin is hiding or rearranging elements at mobile widths in a way you didn’t expect and didn’t set. The element didn’t disappear because of anything you did. Something in the tools you’re using decided it shouldn’t show at that width.
Second, a flexbox or grid layout that works at wide viewports doesn’t wrap or collapse correctly at narrow ones. This was what was happening with my table: the columns were set to fixed widths that made sense at 1200px and had no instruction about what to do at 375px, so the browser just kept them at their fixed widths and let them overflow the container.
Third, a fixed pixel value that made sense at full desktop width pushes elements outside the viewport at mobile widths. A width of 800px is fine on a 1440px screen. On a 375px screen, it spills 425px off the right edge.
None of these are things you did wrong. They’re behavior built into the tools you’re using, firing at widths you weren’t looking at when you built the page.
The fix, once you’ve found the rule
What you do next depends on where the rule came from and what it’s doing.
If an element is hidden by a theme media query and you want it visible, add a custom CSS override that targets the element at that breakpoint and sets display: block or display: flex, depending on how it’s structured. The override needs to be inside a matching @media block so it only applies at mobile widths.
If a section is stacking incorrectly because a flexbox container isn’t wrapping at small widths, the fix is usually adding flex-wrap: wrap to the container at the mobile breakpoint, or adjusting the flex item widths so they respond correctly when the container narrows.
If it’s a page builder setting applying a desktop-only value at mobile widths, go back into the builder, switch to mobile view, and either clear the conflicting value or set the correct one explicitly for mobile. Most builders let you set independent values per breakpoint, so a desktop width of 800px can have a mobile width of 100% set separately.
For a table specifically: the options are genuinely limited, and that’s worth naming honestly. You can make the table horizontally scrollable within a wrapper div rather than the full page, which is less bad than full-page horizontal scrolling. You can use CSS to stack table rows differently at mobile widths, turning each row into a block rather than a row. You can replace the table entirely with a different structure on mobile using display: none on one version and display: block on the other, though this means maintaining two versions of the same content. None of these are perfect. They’re tradeoffs, and the right one depends on your specific table and what the data needs to communicate.
After any fix, test on an actual device, not just the browser simulator. The simulator is accurate for most things, but real device rendering can differ in ways that matter, particularly on iOS Safari.
If the CSS fix isn’t applying
If you’ve written an override and it isn’t taking effect on mobile, the problem is usually specificity: another rule has higher priority and is winning the cascade. The post on CSS override not working: how to find which rule is winning and where it came from covers how to find which rule is beating yours and what to do about it. If you’re working in Elementor and responsive settings aren’t behaving as expected, Elementor CSS not applying: why and how to fix it covers the generated CSS layer that sits between your settings and the live page.
The broken mobile layout is always in the CSS. The browser knows which rule is causing it. The hard part is reading what the browser knows, at the width where the problem appears, when you can only see the working version on your screen.
Most desktop-fine-mobile-broken failures come down to a media query hiding or rearranging something at a width you weren’t watching, a layout that doesn’t wrap correctly when the viewport narrows, or a fixed pixel value that made sense at full width and spills off the edge of a phone. Find the rule in the Styles panel at 375px, note where it came from, and apply your fix at the same breakpoint where the problem fires. If you’re not sure where to start, open the broken page in Chrome, switch to device simulator at 375px, click the broken element, and look for the @media block in the Styles panel. That’s where the answer is.
