Screenshot-to-code breaks on phones because a screenshot describes one screen width and nothing else. A converter that matches pixels places elements with absolute coordinates, fixed widths and desktop font sizes measured from a 1440px picture, so on a 390px phone the text overflows, boxes overlap and the page scrolls sideways. A layout that survives phones has to be built from flowing flex and grid rules, with its own type sizes and column plan at each width.
What a screenshot can't tell a converter
A screenshot is a picture of one moment at one width. It doesn't say:
- which elements belong together as a group;
- what should wrap onto a new line when space runs out;
- whether a 560px text column is a fixed width or a maximum;
- what happens when the headline is twice as long;
- what the navigation turns into on a phone;
- which part of a photo may be cropped.
A designer answers those questions from experience. A tool that only measures pixels has to guess, and the guess that matches the picture most exactly is "put each thing at the coordinates where it appears". That's perfect at 1440px and wrong everywhere else.
This is why FNJ's screenshot-to-website builder doesn't convert a screenshot into coordinates at all. It treats the image as a design reference and builds the layout from scratch. Whatever tool you use, though, the failure modes below are worth knowing, because you can test for every one of them.
The six ways converted pages break
1. Absolute positioning
This is the classic. The output looks like this:
.hero-title {
position: absolute;
left: 120px;
top: 212px;
width: 640px;
font-size: 88px;
}
.hero-button {
position: absolute;
left: 120px;
top: 486px;
}
Every box remembers where it sat on the desktop picture. Absolutely positioned elements also don't push each other around, so when the headline wraps onto a third line it simply grows over the button below it. On a phone, half the elements start off the right edge of the screen.
2. Fixed widths
width: 1280px on a wrapper or width: 560px on a text block forces the page wider than the phone. The browser adds horizontal scrolling, and visitors see a page that wobbles left and right as they scroll down.
3. Desktop type sizes everywhere
An 88px headline is striking at 1440px. On a 390px phone with normal side gutters, it fits about seven or eight characters per line, so a short headline becomes a tower of broken words. Long words that can't break at all push past the edge of the screen.
4. Rows that never become columns
Three feature cards side by side at desktop width are fine. Squeezed into a phone they become three slivers, each roughly a hundred pixels wide, with text breaking after every word. The same happens to logo rows, stats rows and pricing tables.
5. Text and buttons baked into images
When a converter can't recreate an element, it may export a cropped piece of the screenshot instead. That piece can't reflow or be edited, its text is invisible to search engines and screen readers unless someone writes alt text for it, and it turns blurry when scaled.
6. A missing viewport tag
Without <meta name="viewport" content="width=device-width, initial-scale=1">, phones assume the page was designed for a desktop and render it zoomed out to a tiny size. MDN's viewport meta tag reference explains the values. It's one line, and its absence is the first thing to check.
What a responsive layout needs instead
A layout that works on phones describes relationships, not positions: "these three cards share a row and wrap when there isn't room", "this column is at most 640px wide", "the headline is smaller below 810px". The tools for that are flexbox and CSS grid, which MDN covers well in its CSS grid layout guide.
The hero from earlier, written that way:
.hero {
display: grid;
grid-template-columns: 1.2fr 1fr;
gap: 48px;
align-items: center;
max-width: 1200px;
margin: 0 auto;
padding: 0 40px;
}
.hero-title { font-size: 88px; line-height: 1.05; }
@media (max-width: 1199px) {
.hero { gap: 32px; padding: 0 32px; }
.hero-title { font-size: 60px; }
}
@media (max-width: 809px) {
.hero { grid-template-columns: 1fr; padding: 0 20px; }
.hero-title { font-size: 40px; }
.hero-actions { flex-direction: column; }
}
Nothing in it knows where anything sits on the screen. It knows how things relate, and the browser works out the rest at every width.
What changes at 1440, 810 and 390
Designing at three widths means making a deliberate decision for each element at each one. These are typical starting points for a marketing page, not rules:
| Element | Desktop (1440px) | Tablet (810px) | Phone (390px) |
|---|---|---|---|
| Display headline | 72–96px | 52–64px | 36–44px |
| Body text | 18px | 17px | 16px |
| Feature cards | 3 per row | 2 per row | 1 per row |
| Hero | Text and image side by side | Side by side or stacked | Stacked, text first |
| Navigation | Links plus one button | Shortened links or a menu | Menu button |
| Buttons | Inline | Inline | Stacked, full width |
| Side gutters | 40px or more | 32px | 16–20px |
Those three widths are design checkpoints, not the only screens that exist. A real layout also has to look right at 1024px, 360px and everything in between, which is another reason fixed coordinates fail: they're correct at exactly one width. For more on choosing and checking breakpoints, see responsive breakpoints explained.
Small CSS details that prevent overflow
- Give flex children that contain text
min-width: 0, or long words will stretch them past their container. - Add
overflow-wrap: anywhereto text that may contain long URLs or email addresses. - Use
max-width: 100%andheight: autoon images, andaspect-ratiowithobject-fit: coverwhere a photo must fill a fixed shape. - Prefer
max-widthtowidthon content containers.
How to test any screenshot-to-code output
Run these checks before you accept output from any tool, including your own hand-written code.
Search the stylesheet. Count the matches for
position: absolute. A few for decorative badges or overlays are normal; dozens mean the layout is built from coordinates. Then search for widths over about 400px set in pixels.Open your browser's device emulation. In Chrome or Edge DevTools, toggle the device toolbar and check 390px wide, then 360px.
Drag slowly from wide to narrow. Resize the viewport from 1440px down to 320px and watch for the moment things collide. Problems often hide between your breakpoints.
Find what's sticking out. Paste this into the console to list every element wider than the screen:
const w = document.documentElement.clientWidth; document.querySelectorAll("body *").forEach((el) => { if (el.getBoundingClientRect().right > w + 1) console.log(el); });Stress the content. Replace a headline with one twice as long, paste a long email address into a paragraph, and try a German translation of a heading if you have one. Real content is never as tidy as the mockup.
Zoom in. At 200% browser zoom, text should still reflow into a readable column without sideways scrolling. WCAG's reflow criterion goes further and asks for content to work in a viewport 320 CSS pixels wide, which is a good bar for any site.
Use a real phone. Check it upright and turned sideways, and try the menu with your thumb.
How to fix output you already have
If only a few sections are broken, patch them: wrap related boxes in a container, switch the container to flex or grid, replace fixed widths with max-width, add smaller type sizes in a media query and add the viewport tag. If most of the page is absolutely positioned, be honest with yourself. Rebuilding the layout from the screenshot is usually faster than untangling hundreds of coordinates, because every fix you make at one width breaks something at another. For a broader grounding in the techniques, web.dev's Learn Responsive Design course is a thorough, practical reference.
Building from a screenshot without the breakage
FNJ's AI builder takes the look of a screenshot (its grid, typography, palette, spacing and component style) and designs each page from that with real flex and grid layouts at 1440, 810 and 390px, each width with its own type sizes and layout. The exported code is plain CSS per breakpoint, which you can inspect in a Next.js or HTML export and test with the checklist above. If that's the result you need, you can build a responsive site from a screenshot with FNJ.
Frequently asked questions
Why does my converted website scroll sideways on a phone?
Usually something is wider than the screen: a fixed pixel width, an absolutely positioned element placed for a desktop layout, or a long word or image that can't shrink. Run an overflow check in the browser console to find the element, then replace its fixed width with a maximum width or let it wrap.
Can a screenshot-to-code tool make a responsive website?
Only if it rebuilds the layout with flowing rules such as flexbox and grid and decides how each section should change at smaller widths. A tool that copies the positions from the screenshot produces a layout that's correct at one width and breaks at others.
Which screen widths should I test?
Check the widths the site was designed for, such as 1440, 810 and 390px, and then drag between them down to about 320px. Problems often appear between breakpoints rather than at them.
Is absolute positioning always bad?
No. It's the right tool for small overlays such as a badge on a card or a decorative shape. It becomes a problem when the main layout, meaning headings, text blocks and buttons, is placed with coordinates.
How do I stop text overflowing on mobile?
Give the text a smaller size at narrow widths, add overflow-wrap: anywhere for long words and URLs, and set min-width: 0 on flex items that contain text. Also check that the page includes the viewport meta tag.