Use screenshots only for a site you own, have permission to reproduce or are studying as inspiration. Identify the viewport, content hierarchy, grid, type scale, colours and recurring components; then design the unseen mobile, hover, focus, loading and error states yourself. Build with semantic HTML and real content, compare at the original viewport, and test responsiveness and interaction separately from visual similarity.
Reviewed for material changes on August 13, 2026
Clear the rights before matching the pixels
A screenshot does not make the underlying copy, photography, illustration, logo or code free to use. Recreate your own site or work from written permission. If another site is only a reference, use it to understand a pattern and produce your own words, assets and brand expression.
Keep a short asset ledger with the source, owner and licence for each image, font and icon. This takes minutes on a small page and prevents a hurried launch from turning borrowed material into a permanent dependency.
Read the screenshot as a set of rules
Establish the captured viewport first; proportions mean little without it. Measure the outer margins, content width, columns, gaps, section spacing, type sizes and image ratios. Look for repeated values rather than recording every distance as unique.
Write a small token sheet before coding: background and text colours, accent, border, radius, shadow, type families, scale and spacing steps. The goal is not forensic perfection. It is a compact rule set that produces the same visual logic across the page.
- Identify the primary content column and any full-bleed sections.
- Separate font family, size, weight, line height and letter spacing.
- Check whether apparent spacing comes from padding, line height or the asset itself.
- Note repeated card, button, label and divider treatments.
Design everything the screenshot leaves out
Choose how the layout collapses below the captured width, what the navigation does, whether images crop or resize and how long headings wrap. Do not shrink a desktop page until it fits. Reorder the page around the reading and action priority of a narrow screen.
Add hover, focus, active, disabled, loading, empty, error and success states where the interface needs them. WCAG 2.2 includes requirements around visible focus, target size and accessible authentication; a visually faithful page can still be miserable to use.
Build the hierarchy before polishing decoration
Start with real headings, landmarks, lists, links, buttons and forms. Then establish the large layout and responsive rules. Fine-tune shadows and one-pixel offsets after the content order works; decoration cannot rescue a wrong grid.
Use actual production copy as early as possible. Placeholder text hides wrapping problems, and a perfectly matched card can fall apart as soon as its title is twice as long as the sample.
Compare in layers, then test it as a website
Render your page at the exact reference dimensions and compare the large geometry first: section boundaries, column widths, image boxes and text blocks. Fix those before colour nuance. Repeat at widths the screenshot did not provide so your invented responsive rules get a fair test.
Finally stop looking at screenshots. Tab through the page, zoom it, submit forms, slow the network and use it on a phone. Google treats loading, interactivity and visual stability as separate Core Web Vitals; matching a still image proves none of them.
Sources and checks
Product limits and prices came from the companies themselves:
- U.S. Copyright Office: what copyright protects
- W3C Web Accessibility Initiative: what is new in WCAG 2.2
- Google web.dev: Web Vitals
Plans move. We date every check so you know when to verify again.