# Screenshot-to-Code: Building UIs from Images with AI > Turn a screenshot, mockup, or Figma frame into working frontend code with AI vision models — the realistic workflow, the right tools, and the honest pitfalls. Screenshot-to-code works: a vision model reads an image and emits matching markup. Treat it as an 80% first draft, not a final answer. Use prompt-to-app tools (v0, Bolt, Lovable) for greenfield, a vision model plus an agent in your editor for in-repo work, and Figma's MCP when you have real design data — because a flat screenshot loses structure a model has to guess back. Hand a vision model a screenshot of a UI and it will hand you back working code — usually React with Tailwind, often shadcn/ui — that looks a lot like the picture. This is real and it's useful. It's also where most people get burned, because **a screenshot that matches is not a UI that's correct**. A flat image throws away everything that makes frontend hard: responsive behavior, interactive state, accessibility, and your design system. The model fills those gaps by guessing. So treat screenshot-to-code as what it actually is: a fast way to get an 80%-there first draft that you then refine. This guide covers the realistic workflow, which tool fits which job, how to prompt for fidelity, and exactly where it bites you. ## The realistic workflow: capture, describe, generate, refine The loop is always the same four moves, and skipping the middle two is why output disappoints. **Capture.** Use a high-resolution image and crop tightly to what you want. Include enough surroundings to imply layout, but cut unrelated chrome. Low-res or cluttered screenshots degrade results more than any prompt tweak. **Describe.** This is the step everyone skips. A still frame has no hover, no loading spinner, no breakpoints, no data source. If you don't say what those should be, the model invents them. Name your framework, your design system, your target breakpoints, and the interactive states — then say where real data comes from. **Generate.** Produce the first draft with the tool that fits (below). **Refine.** The output is a draft, not a delivery. Iterate conversationally — tighten spacing, replace ad-hoc markup with your components, wire up state. The correctness lives in this back-and-forth, not in the first generation. ## Which tool fits which job There's no single best tool; there's a best tool per situation. ### Greenfield: prompt-to-app builders When you're starting from nothing and want a *running* app from an image or a sentence, reach for a prompt-to-app builder. [v0](/tools/v0) leans toward React, Next.js, and shadcn/ui — upload a screenshot or a Figma export and it analyzes layout, colors, and components, then generates matching code and a live preview. [Bolt](/tools/bolt) builds and runs full-stack apps in an in-browser environment and supports importing from Figma as a visual reference. [Lovable](/tools/lovable) aims at non-technical builders, generating a full stack — UI, database schema, auth, deploy — from natural language in one tab. All three are excellent for prototypes and net-new screens. None is the right move for editing code you already have. ### Existing repo: a vision model plus an agent in your editor If the UI needs to land in a real codebase with real conventions, don't start over in a builder. Drop the screenshot into an agent inside your editor — [Cursor](/tools/cursor) lets you paste an image straight into the chat, where the model sees it alongside your open files. This is the difference that matters: the agent generates code that uses *your* components and patterns instead of generic markup, and it's especially good for visual debugging, where the model sees both the rendered problem and the actual stylesheet. Under the hood this is just the vision capability of a frontier model; if you're building this into your own product instead of using an editor, see [Add Image Understanding to Your App](/guides/vision/add-image-understanding-to-your-app). ### Design handoff: use the Figma file, not a picture of it When the source is an actual Figma file, a screenshot is the worst option — you're throwing away structured data just to make the model reconstruct it. [Figma's MCP server](/tools/figma-mcp) passes the real design to your agent: the node tree, component variants, layout constraints, and design tokens, plus **Code Connect** mappings that tell the agent which of your code components a given design component maps to. That eliminates most of the guesswork a flat raster forces, so the output is far more likely to be on-system and structurally faithful. It works with Cursor, Claude Code, and other MCP clients. Screenshot when the design lives only as an image; MCP when you have the file. ## Prompting for fidelity The model can only work with what you give it, and an image is missing most of the spec. Raise fidelity by adding the context a picture can't hold: - **Name the stack.** Framework, styling approach, and component library. "shadcn/ui Card, not a raw div" changes everything downstream. - **Specify breakpoints.** A screenshot is one viewport. Say what mobile and desktop should do, or you'll get one fixed-width layout. - **List the states.** Hover, focus, disabled, loading, empty, error. None are in the image; all are in the real UI. - **Point at conventions.** Reference an existing file so the output matches your patterns instead of inventing its own. - **Iterate deliberately.** Fidelity comes from a few targeted follow-ups, not from one heroic prompt. ## The honest pitfalls This is the part the demos skip. **Pixel-perfect is not correct.** A flawless copy of the image can still be a broken UI — non-responsive, inaccessible, off-design-system. The picture is one state of one viewport, and matching it proves nothing about the other states. **A screenshot loses semantics.** The model can't *see* that a styled box is meant to be a `