Lovable mobile layout broken: why it looks fine in preview and how to fix it

Symptom

The app looks tidy in Lovable's Mobile view. On an actual phone:

• The page scrolls sideways, or the whole layout sits slightly wider than the screen.
• A full-height screen hides its bottom button behind the browser's toolbar.
• A dialog is taller than the screen and its save button can't be reached.
• A table or chart is cut off at the right edge.
• The navigation overlaps the content, or the menu never collapses.

There's no error message for any of this. The browser renders exactly what the code asks for.

Why it happens

The Mobile view is a narrower frame, not a phone. Lovable's device toggle switches the preview between Desktop, Tablet and Mobile view. It's useful, but it's still your desktop browser. The real phone has a toolbar that grows and shrinks as you scroll, an on-screen keyboard that takes half the screen, and fingers instead of a mouse.

Full-height screens use the wrong unit. MDN's docs explain that vh is the large viewport, the size with the browser's toolbars retracted. A 100vh screen is taller than what you can see while the toolbar is showing, so the bottom of it hides.

Classes written desktop first. If your project uses Tailwind (check package.json for tailwindcss), it's mobile first: classes without a prefix apply to every screen, and md: applies from 768px up. Tailwind's docs warn that sm: doesn't mean "on small screens". A layout written as grid-cols-3 with nothing smaller in front of it is three columns on a phone too.

Fixed widths and wide content. A sidebar at a fixed width, an image without a max width, or a data table with eight columns will push past a 375px screen.

Each prompt fixes one screen. Lovable edits what you describe. Fixing the dashboard on mobile doesn't teach it to build the next page mobile first, unless you tell it once in a place it always reads.

The fix

1. Reproduce it on a real phone

Publish, or share a preview link, and open it on your phone. Lovable's docs also suggest opening the preview in a new tab and resizing the window. Then ask Lovable to check for you. Switch the preview to Mobile view first, because browser testing uses the preview's screen size by default:

Use browser testing at mobile size to go through sign-up and the dashboard. Report any element wider than the screen and any button that is hidden or can't be tapped.

2. Find the element that overflows

Open the published page in Chrome's device toolbar, or on your phone with remote debugging, and paste this into the console. It lists every element wider than the screen:

// List elements that stick out past the right edge of the viewport.
const width = document.documentElement.clientWidth;
[...document.querySelectorAll("body *")]
  .filter((el) => el.getBoundingClientRect().right > width + 1)
  .forEach((el) => console.log(el, Math.round(el.getBoundingClientRect().right)));

The deepest element in the list is usually the culprit. Its parents only appear because they contain it.

3. Apply the standard fixes

These assume Tailwind. If your project uses plain CSS, the same ideas apply.

// Grids: one column on phones, more from the md breakpoint up.
<div className="grid grid-cols-1 gap-4 md:grid-cols-3">{cards}</div>
 
// Full-height screens: follow the visible viewport, not the large one.
<main className="flex min-h-[100dvh] flex-col">{children}</main>
 
// Wide tables: let the table scroll inside its own box, not the page.
<div className="w-full overflow-x-auto">
  <table className="min-w-[640px] text-sm">{rows}</table>
</div>
 
// Dialogs: cap the height and let the content scroll.
<div className="max-h-[90dvh] overflow-y-auto">{form}</div>
 
// Fixed-width sidebars: hide on phones, show from lg up.
<aside className="hidden w-64 shrink-0 lg:block">{nav}</aside>

MDN notes that dynamic viewport units resize as the toolbar moves, which can cost some smoothness while scrolling. Use 100dvh for screens that must fit exactly, like a checkout or a chat, and normal page flow everywhere else.

4. Prompt for one element at a time

For changes you'd rather not hand-code, use the preview toolbar's Select elements mode, click the broken element, and describe the change. Name the breakpoint and the behaviour, not just "make it responsive":

On screens under 768px, stack these three cards in one column, make the table scroll horizontally inside its card, and keep the page itself from scrolling sideways. Don't change the desktop layout.

5. Write the rules down once

Open Project settings, then Instructions and add your layout rules. Lovable considers them on every edit, and each set can hold up to 10,000 characters. For example:

Layout rules for this project:
- Build mobile first. Unprefixed classes are for phones; add md: and lg: for larger screens.
- Never use h-screen or 100vh for full-height screens. Use min-h-[100dvh].
- Tables go inside a container with overflow-x-auto.
- Tap targets are at least 44px high.
- After any layout change, check the page in Mobile view.

Lovable also reads an AGENTS.md or CLAUDE.md file in the project, if you'd rather keep the rules in code.

How to prevent it

• Check Mobile view after every layout prompt, and a real phone before every publish.
• Test forms with the on-screen keyboard open. That's where hidden buttons show up.
• Keep the Instructions up to date as the design settles.
• If you want the app on home screens, you can make a published Lovable app a Progressive Web App. That doesn't fix layout, so fix the layout first.

When to get help

A few broken screens are quick to fix. A layout that was built desktop first throughout, with fixed widths in every component, is closer to a redesign of the shell. This page is part of my guide to fixing a vibe-coded app. For the patterns that apply to any AI tool, read fixing mobile layouts in AI-built apps, and because tap targets and zoom affect everyone, making an AI-built app accessible is the natural next step.

For the full Lovable launch checklist, read taking a Lovable app to production. Start with the free vibe-code health check, and if the layout needs proper work, a Rescue Sprint includes a phone-first pass at a fixed price agreed after the check.