Screenshot-to-code has a reputation for producing demos that dazzle and outputs that disappoint. The technology is not the problem; the input is. One screenshot at one width, compressed to a JPEG, is a lossy description of a design. Multi-viewport capture with extracted design tokens is a faithful one.
Three failure modes of single-screenshot capture
- Colour drift: hex values read off a compressed image are never exact, so the rebuild's palette is subtly off.
- Font invention: the model guesses a typeface from letterforms and usually picks the wrong one.
- Responsive blindness: with one width, the agent has no idea how the layout should behave on mobile, so it fabricates breakpoints.
The fix: capture the design, not a picture of it
WebForge captures each page at desktop (1440), tablet (768) and mobile (390), stitched full-page after scrolling through lazy-loaded content. Alongside the images it extracts an area-weighted colour palette and the real font stack. The agent gets both the layout evidence and the precise values.
Area-weighted colour, not a naive histogram
A naive palette counts pixels and hands back near-duplicates of the background. An area-weighted palette ranks colours by how much meaningful surface they cover, so the accent that appears on one button still surfaces, which is exactly the colour an agent most needs and most often gets wrong.
The result
Give an agent three real renders and a token file and the output stops being “inspired by” the original and starts matching it. That is the whole point of screenshot-to-code, and it only works when the screenshot is actually a blueprint.
Try it on any URL from the WebForge homepage, or wire the Python or Node package into your pipeline.