How to rebuild a website layout from a screenshot with AI

1. Describe the layout before generating code

Start by recording the image dimensions and the visible page regions: header, navigation, hero, content grid, and footer. Identify alignment, approximate content width, spacing patterns, heading sizes, and repeated components. Treat inferred values as estimates until you can compare a rendered result.

Separate content from styling. A screenshot may show a three-column feature grid, but that does not tell you the mobile breakpoint, reading order, or behavior of a menu. List those as design decisions instead of assuming the desktop view is a complete specification.

Analyze the supplied screenshot as a visual reference. Do not write code yet. List the layout regions, hierarchy, approximate spacing and color tokens, and reusable components. Mark estimates clearly. List any behavior or mobile decisions the image cannot establish. Propose an original implementation using my own content and brand assets.

2. Write a build brief with real behavior

Decide whether the task is a static landing page or part of an existing application. Preserve the existing routes, components, build tools, and data contracts when extending a project. Introducing a different framework just to match a screenshot can create avoidable maintenance work.

On small screens, scroll the table sideways to see every column.

Include loading and empty states only where the page has data-dependent features. A button that merely resembles a checkout or login control is not a working checkout or authentication system. Name the behavior the implementation must deliver.

3. Build a small local starter

For a static page, a single HTML file is enough to test the first layout. Create a new folder, save the following as index.html, and use it as a starting structure. Clearboard is an invented practice name; the example is not a released product or a copy of a particular website.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Clearboard — layout practice</title>
  <style>
    * { box-sizing: border-box; }
    body { margin: 0; font: 18px/1.6 system-ui, sans-serif;
      color: #172238; background: #f4f1fb; }
    .wrap { width: min(1100px, calc(100% - 40px)); margin: auto; }
    header, section { padding-block: 28px; }
    nav { display: flex; flex-wrap: wrap; gap: 18px; }
    a { color: #6332a3; text-underline-offset: 4px; }
    a:focus-visible { outline: 3px solid #6332a3; outline-offset: 5px; }
    .hero { padding-block: 64px; max-width: 750px; }
    h1 { font-size: clamp(36px, 6vw, 68px); line-height: 1.1;
      letter-spacing: -.04em; margin: 12px 0 24px; }
    .button { display: inline-block; padding: 12px 20px; border-radius: 8px;
      color: white; background: #6332a3; text-decoration: none; }
    .cards { display: grid; grid-template-columns: repeat(3, minmax(0, 1fr)); gap: 20px; }
    article { min-width: 0; padding: 24px; border: 1px solid #d8d3e4;
      border-radius: 16px; background: white; }
    h2, h3 { line-height: 1.3; }
    @media (max-width: 700px) { .cards { grid-template-columns: 1fr; } }
  </style>
</head>
<body>
  <header class="wrap"><nav aria-label="Main navigation">
    <strong>Clearboard</strong><a href="#features">Features</a><a href="#contact">Contact</a>
  </nav></header>
  <main class="wrap">
    <section class="hero" aria-labelledby="title">
      <p>LAYOUT PRACTICE</p><h1 id="title">Give your next project a clear starting point.</h1>
      <p>An original practice layout. Replace the words and visual choices with your own brief.</p>
      <a class="button" href="#features">Explore the layout</a>
    </section>
    <section id="features" aria-labelledby="features-title">
      <h2 id="features-title">A simple three-part layout</h2>
      <div class="cards">
        <article><h3>Plan</h3><p>Identify the content hierarchy and spacing.</p></article>
        <article><h3>Build</h3><p>Use semantic HTML and responsive CSS.</p></article>
        <article><h3>Review</h3><p>Check real interactions at several screen sizes.</p></article>
      </div>
    </section>
    <section id="contact" aria-labelledby="contact-title">
      <h2 id="contact-title">Next step</h2>
      <p>This is a layout demonstration. Add a real contact route for your own project.</p>
    </section>
  </main>
</body>
</html>

The starter has real section links, a visible keyboard focus style, and a three-column grid that becomes one column on smaller screens. It deliberately has no form backend, analytics, external images, or account system. Add those only when they are part of the brief.

4. Preview the page through a local server

If Python 3 is installed, open a terminal in the folder containing index.html. Choose the command that works with your Python installation. Bind to the loopback address for this local preview.

python3 -m http.server 8000 --bind 127.0.0.1

py -m http.server 8000 --bind 127.0.0.1

Open http://127.0.0.1:8000/ in a browser. Keep the server terminal open while reviewing the page; Ctrl+C stops it. If port 8000 is occupied, choose another port in the command and open the matching browser address. This is a local development preview, not a production deployment.

5. Compare in passes rather than one giant prompt

Compare the rendered page with the reference at the same viewport dimensions first. Fix the largest structural differences before adjusting small decorations: content width, column proportions, section heights, typography, spacing, then icons and borders. A change to the font can alter wrapping throughout the page, so check layout again afterward.

Compare the current rendered page with the reference at the same viewport. Identify the three largest layout differences. Fix hierarchy, container width, and spacing first while preserving real link destinations and keyboard behavior. Explain any detail that cannot be inferred from the image. Then check the narrow-screen layout before making another pass.

If you use a frontend-design skill, give it the audience, content, and visual constraints. Pair it with browser testing after implementation. The design procedure can guide choices, but it does not replace checking the page that the browser actually renders.

6. Verify the page beyond its screenshot

• Check narrow mobile, tablet, and desktop widths; the starter can be tried at 320, 768, and 1440 pixels.
• Use Tab and Enter to follow every navigation link and action. Confirm focus remains visible.
• Test long headings and realistic content lengths so cards do not overflow.
• Inspect image loading, the browser console, and the behavior of any forms or filters you add.
• For a published page, use a descriptive title and description, one clear H1, and the correct canonical URL for your domain.

If the finished site includes a theme switch or interactive controls, test those states separately. A visual match is one acceptance check; usable behavior, accessible structure, real content, and correct deployment are others.

Keep a short record of decisions you made because the screenshot did not specify them. This makes later changes easier and avoids presenting an inferred layout as the recovered original implementation.

7. Frequently asked questions

8. Related articles and next steps

• Choose frontend design and web testing skills
• Understand an existing codebase with AI
• Deploy a static website to Cloudflare Workers
• Discuss an AI or automation project