10 responsive mistakes in AI-built websites (and fixes)
AI tools build great desktop pages and wobbly phone ones. The 10 responsive mistakes AI-built websites make most, how to spot each one, and a prompt to fix it.
The most common responsive mistakes in AI-built websites are fixed desktop widths, oversized headings, nav bars that don't collapse, rows that don't wrap, 100vh heroes, hover-only interactions, tiny tap targets, wide tables, unsized images and a missing viewport tag. They happen because AI tools design and preview at desktop size first. Each one is easy to spot and quick to fix once you know what to look for.
To spot them, look at your site at three phone widths: 360px (Galaxy S25), 402px (iPhone 17 Pro) and 440px (iPhone 17 Pro Max). Every mistake below has a "spot it" line and a prompt you can paste into Claude, ChatGPT, Cursor, Lovable, v0 or Bolt.
1. Fixed widths copied from desktop layouts
The AI designed a 1280px page and some of those numbers stuck: width: 600px on a form, min-w-[800px] on a dashboard, w-[520px] on a card.
Spot it: the page wobbles sideways on a phone. In doesitfit it's a SPILLING +Npx sticker, and Show me where outlines the element that sticks out. In the code, look for pixel widths bigger than about 320.
Find every fixed width or min-width over 320px (including Tailwind arbitrary values like w-[600px]) and make it responsive: width: 100% with the old value as max-width. Keep desktop exactly as it is.
The full list of causes is in how to fix horizontal scrolling on mobile.
2. Oversized hero headings
AI loves a giant headline. Tailwind's text-7xl is 72px and text-8xl is 96px, and if there's no smaller size for phones, a long word like "Transformation" at that size is usually wider than a 360px screen. Short words just stack one per line and push the button below the fold.
Spot it: a headline with one word per line, a word running off the edge, or a hero that's all headline.
Fix: a mobile size first, bigger at breakpoints (text-4xl md:text-6xl lg:text-7xl), or one fluid size:
h1 { font-size: clamp(2rem, 1.2rem + 4vw, 4.5rem); }
My hero heading is too big on phones. Make headings scale with the screen using clamp() with a rem part (or text-4xl md:text-6xl lg:text-7xl in Tailwind), so the h1 is about 32–36px on a 360px phone. Keep the desktop size.
3. Nav bars that don't collapse
Six links, a logo and a "Get started" button fit nicely in a row at 1440px. At 360px they wrap into two messy lines, overlap the logo or push the page sideways.
Spot it: the header is taller than it should be, links wrap or overlap, or the header is the SPILLING element.
Below 768px, collapse the header links into a menu button. The button needs aria-expanded and aria-controls, a label like Menu, a tap area of at least 44×44px, and should close with Escape. The menu should open below the header, full width, with each link at least 44px tall. Keep the desktop nav unchanged.
4. Rows of cards that don't wrap
Three pricing cards in a flex row, or grid-cols-3 with no mobile version. On a phone you get three 100px-wide columns of squashed text, or a row that spills.
Spot it: skinny columns with a few words per line, or a SPILLING sticker pointing at a card row.
Fix: one column on phones, more on bigger screens: grid grid-cols-1 md:grid-cols-3, or flex flex-wrap with min-w-0 on the items.
Make every row of cards, features, pricing plans and logos stack to one column below 640px and go to two or three columns on bigger screens. Use grid-cols-1 sm:grid-cols-2 lg:grid-cols-3 or flex-wrap, and add min-w-0 to flex children.
5. 100vh heroes on phones
A hero set to h-screen or height: 100vh fills a laptop screen nicely. On phones, 100vh is measured as if the browser's toolbars were hidden, so the bottom of the hero, usually the button, sits behind Safari's toolbar on first load. On an iPhone 16 Pro (402×874), only about 718px of page is visible on first load with Safari's toolbars showing (how much of the screen iPhone users see).
Spot it: turn on Browser bars in doesitfit to see Safari's and Chrome's toolbars at their real heights, and check whether your hero's call to action is hidden.
.hero { min-height: 100vh; min-height: 100svh; }
svh is the height with the toolbars showing, and min-height lets the hero grow if the text needs more room. The details are in 100vh on mobile is broken.
Replace h-screen / height: 100vh on hero sections with min-height: 100svh (keep 100vh as a fallback before it; in Tailwind use min-h-svh). Make sure the main button is visible without scrolling on a 402×874 iPhone with Safari's toolbars showing.
6. Hover-only interactions
Dropdowns that open on hover, cards that reveal the price on hover, tooltips holding important info. Phones don't hover. Some taps trigger a fake hover, some don't, and nobody knows they should try.
Spot it: on a phone, try to reach every menu item and every piece of information without a mouse.
Fix: make it work with a tap and with the keyboard, and only add hover extras where there's a real mouse:
.card-details { opacity: 1; }
@media (hover: hover) and (pointer: fine) {
.card-details { opacity: 0; transition: opacity 0.2s; }
.card:hover .card-details,
.card:focus-within .card-details { opacity: 1; }
}
Tailwind v4's hover: variant already only applies on devices that can hover, which stops stuck hover styles but doesn't make hover-only content reachable.
Find anything that only works on hover (menus, dropdowns, tooltips, hidden card content). Make it open on click or tap and keyboard focus, show content by default on touch screens, and only use hover as an extra inside @media (hover: hover) and (pointer: fine).
7. Tap targets under about 44px
Icon buttons with a 20px icon and no padding, footer links crammed together, a tiny "×" to close a banner. Thumbs are not mouse pointers.
The numbers, accurately:
| Guideline | Minimum |
|---|---|
| Apple Human Interface Guidelines | 28×28 points for controls (44×44 is the default size) |
| WCAG 2.2, 2.5.8 Target Size (Minimum), level AA | 24×24 CSS pixels, or enough spacing around smaller targets (links inside sentences are exempt) |
| WCAG 2.2, 2.5.5 Target Size (Enhanced), level AAA | 44×44 CSS pixels |
On the web, an iPhone point is a CSS pixel, so aim for 44×44px and treat 24px as the accessibility floor, not the goal.
Spot it: try tapping every icon and link on a real phone with your thumb. Mis-taps mean it's too small or too close.
Make every button, icon button and link that isn't inside a paragraph at least 44×44px to tap (use padding or min-width/min-height; in Tailwind min-h-11 min-w-11), without making icons bigger. Add at least 8px between neighbouring tap targets.
8. Wide tables and code blocks
Comparison tables, pricing tables and code snippets have a minimum width, usually more than a phone has.
Spot it: SPILLING on pages with a table or pre.
Wrap every table in a div with overflow-x: auto so it scrolls inside its own box, and give pre blocks max-width: 100% and overflow-x: auto. For tables with two or three columns, stack them as cards below 640px instead.
9. Images without dimensions or max-width
Two separate problems, often in the same <img>:
- No
widthandheightattributes. The browser doesn't know how tall the image will be until it loads, so the text jumps down when it arrives. That's layout shift, measured as CLS, one of Google's Core Web Vitals. - No
max-width: 100%. A 1600px image is 1600px wide on a 360px phone.
Spot it: text jumping while the page loads, a Lighthouse warning about images without explicit width and height, or a SPILLING sticker pointing at an image.
img { max-width: 100%; height: auto; }
Give every img a width and height attribute matching the image's real aspect ratio, and make sure the CSS has img { max-width: 100%; height: auto; }. Use responsive images with srcset and sizes for large photos, and don't lazy-load the hero image.
More on that in responsive images with srcset and sizes.
10. Missing viewport tag
Without <meta name="viewport" content="width=device-width, initial-scale=1">, phones lay the page out about 980px wide and shrink it to fit the screen. Everything looks tiny, and nothing is technically "spilling" because the phone zoomed out to fit it all.
Spot it: the page looks like a miniature desktop site on a phone. The doesitfit MCP server warns about it directly: ask your AI to check your site and it reports a missing viewport tag. The full story is in the meta viewport tag and why your website looks zoomed out on phones.
Add to the head of every page. Don't add maximum-scale=1 or user-scalable=no: people must be able to zoom.
That last line matters because AI tools sometimes add user-scalable=no to stop iPhones zooming into small form fields. The right fix for that is a 16px font size on inputs.
Does your site fit?
Paste your address (or localhost:3000). doesitfit shows it on real screen sizes at once and tells you, bluntly, where it spills.
Free, no sign-up. Or ask Claude, ChatGPT or Codex to check it.
How to catch all ten in one go
Most of these show up the moment you look at real sizes side by side. Check the narrow phones first (360px Samsung Galaxy models, 375px iPhone SE), then current iPhones at 393–440px, a tablet and a laptop to make sure fixes didn't break anything bigger.
doesitfit does that in one go and flags spills and cramped text. If you'd rather stay in your AI chat, connect the doesitfit MCP server (/connect) and ask "does my site fit on an iPhone and a Galaxy S25?". The AI gets the exact element to fix. See check your website from Claude, ChatGPT or Codex.
Hover-only menus and small tap targets need a real thumb, so finish on your own phone.
The short version
- AI tools build desktop-first. Assume these ten until you've checked.
- Widths are maximums, headings scale, rows wrap, heroes use
svh, menus collapse. - Everything tappable: 44×44px. Everything hoverable: also works with a tap.
- Images get dimensions and
max-width: 100%; tables and code scroll inside their own box. - One viewport tag, no zoom blocking.
- For the whole check-and-fix loop, see make your AI website mobile friendly.
Questions people ask
Why do AI-built websites break on mobile?
AI tools usually generate and preview the desktop layout first, so fixed widths, huge headings and multi-column rows slip through. Nobody looks at the page at 360px wide until a visitor does.
What is the minimum tap target size on mobile?
Apple's Human Interface Guidelines give 44 by 44 points as the default control size and 28 by 28 points as the minimum. WCAG 2.2 success criterion 2.5.8 (level AA) requires at least 24 by 24 CSS pixels, or enough spacing around smaller targets.
How do I get an AI to make my site responsive?
Give it specifics: the screen width, the element that breaks and by how many pixels, and ask it to fix the cause without changing the desktop layout. Vague prompts get vague fixes.
Does an AI-built site need a meta viewport tag?
Yes. Without it, phones lay the page out about 980px wide and shrink it to fit, so everything looks tiny. Most frameworks add it for you, but hand-written or exported HTML often misses it.