Hand Qwen 3.7 Plus a screenshot of a UI and it can write the front-end code to rebuild it. The model reads images and codes at the same time, so a design mockup, a competitor’s page, or a Figma export becomes a starting React or HTML component in one call. This guide shows the workflow and how to get output you’d actually ship.
We’ll cover the basic call, the prompt details that matter, the visual feedback loop that closes the gap to pixel-accurate, and how to turn the generated UI into a working app. For the model background see our Qwen 3.7 Plus overview, and for the request format the Qwen 3.7 Plus API guide. You’ll test the API and the endpoints your UI calls in Apidog along the way.
TL;DR
Send a screenshot plus a precise prompt to Qwen 3.7 Plus and ask for code in your target framework. The first pass gets you close; you refine by rendering the result, screenshotting it, and asking the model to fix the differences against the original. Plus suits this because it pairs strong vision with solid coding, holds a 1M-token context for large designs, and costs little per call. The work is in the prompt and the iteration, not the API.
Why Qwen 3.7 Plus for this
Screenshot-to-code needs two things at once: read the image accurately, then write correct code. Plus scores around 60% on SWE-Bench Pro and 70.3 on Terminal-Bench, so the coding holds up, and its vision handles dense UI layouts. The 1M-token context lets you send a tall, high-resolution design without truncating, and at $0.40 per million input tokens you can iterate cheaply. For the agentic cousin of this task, driving a UI instead of rebuilding it, see our computer-use agent guide.
The basic call
Send the image as an image_url part alongside a text instruction. Here’s a minimal generator:
import os, base64
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DASHSCOPE_API_KEY"],
base_url="https://dashscope-intl.aliyuncs.com/compatible-mode/v1",
)
def screenshot_to_code(png_path, prompt):
b64 = base64.b64encode(open(png_path, "rb").read()).decode()
resp = client.chat.completions.create(
model="qwen3.7-plus",
messages=[{
"role": "user",
"content": [
{"type": "text", "text": prompt},
{"type": "image_url",
"image_url": {"url": f"data:image/png;base64,{b64}"}},
],
}],
)
return resp.choices[0].message.content
print(screenshot_to_code("mockup.png", "Rebuild this UI as a React component."))
Confirm the current model ID in the Model Studio docs before shipping. That works, but a one-line prompt gets you a one-line-quality result. The prompt is where the quality lives.
Writing a prompt that gets shippable code
Vague prompts produce generic markup. Be specific about the stack and the constraints:
Convert this UI screenshot into a single React component using Tailwind CSS.
Requirements:
- Match the layout, spacing, and color palette as closely as you can.
- Make it responsive down to a 375px mobile width.
- Use semantic HTML and accessible labels for inputs and buttons.
- Use placeholder data where the screenshot shows dynamic content.
- Return only the component code, no prose.
Name the framework, the styling system, the breakpoints, and the accessibility bar. Tell it how to handle dynamic content so it doesn’t invent a backend. The Tailwind CSS docs are a good reference for the utility classes it will emit. If you give the model a component spec or a short design brief, the output gets closer still; our piece on what a design.md does for coding agents explains why a written spec changes results.
Closing the gap with a visual feedback loop
The first pass rarely nails spacing and color. This is where Plus’s vision pays off a second time. Render the generated component, screenshot it, then send both images back and ask the model to reconcile them:
Here is the target design (image 1) and my current render (image 2).
List the visual differences, then return the corrected component code
that matches image 1 more closely.
Two or three of these rounds usually gets a result that’s hard to tell from the original. It’s the same perceive-and-correct idea behind a computer-use agent, applied to code instead of clicks.
Handling real designs
Production mockups are large and detailed, which has two consequences:
- Token cost. A full-page, high-resolution image runs to thousands of tokens. Downscale to the smallest size where text in the design is still legible, and crop to the section you’re building.
- Scope. Don’t ask for a whole dashboard in one call. Break the page into sections, header, sidebar, table, and generate each, then compose them. The 1M context helps, but smaller asks produce cleaner code.
Getting better output
A few prompt tweaks fix the most common problems:
- Wrong colors. The model approximates shades. Paste the exact hex values from your design and tell it to use them.
- Invented icons. It guesses at icon shapes. Name an icon set such as Lucide or Heroicons and ask it to use those components.
- Made-up copy. If it fills in real-looking text, tell it to use clearly marked placeholder content instead.
- Div soup. Ask explicitly for semantic elements and a flat structure, or it tends to over-nest wrapper divs.
Each is a one-line addition to the prompt, and together they cut your refinement rounds noticeably.
From UI to a working app
Generated front-end code is only half a feature. The component will fetch data, submit forms, and call endpoints that have to exist and behave. That’s where the screenshot-to-code shortcut meets real engineering.
Design those endpoints first and the generated UI has something solid to talk to. Apidog lets you define the API contract, mock it so the new component renders with realistic data immediately, and test the responses before the backend is built. Our spec-first mode guide walks through that flow, and the approach pairs well with AI-built front ends the same way it does with APIs built in Cursor.
Download Apidog to mock and test the APIs behind the UI Qwen 3.7 Plus generates.
FAQ
What frameworks can Qwen 3.7 Plus target? Whatever you name in the prompt: React, Vue, Svelte, plain HTML and CSS, Tailwind, or a component library. Be explicit, since the default is generic markup.
How accurate is the first pass? Close on structure, rough on exact spacing and color. The visual feedback loop, rendering and re-sending, is what gets it to near-pixel-accurate.
Can it work from a Figma design? Yes, if you export the frame as an image. The model reads the rendered design, not the Figma file itself.
How do I keep the token cost down? Downscale the image to the smallest legible size, crop to the section you’re building, and generate the page in parts rather than all at once.
Does it build the backend too? No. It produces front-end code that expects APIs. Design and mock those separately, which is the part Apidog handles.
The bottom line
Screenshot-to-code with Qwen 3.7 Plus is a precise prompt, a cheap multimodal call, and a short visual feedback loop. It gets you a working component fast, but the UI still needs real APIs underneath. Generate the front end with Plus, then design, mock, and test the endpoints in Apidog so the finished feature holds together.
