Verified against Gemini · 2026-07-02
Turn a UI screenshot into working frontend code
A multimodal prompt that treats a screenshot as a literal spec — spacing, hierarchy, text, and visible states — and returns matching component code instead of a loose visual approximation.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Here's a screenshot of a pricing card component from a SaaS landing page. Build this as React with Tailwind CSS code. Match, don't reinterpret: 1. Layout structure (what's in a row vs. stacked, alignment, spacing) as closely as the screenshot shows it. 2. Every visible text label, exactly as written, including button text and placeholder text. 3. Visible states — if a button looks disabled/active, a field looks focused, or there's a badge/count, include that state in the code; don't drop it because it's "just a detail." 4. Colors and type choices close to what's shown; use our existing shadcn/ui theme tokens tokens/variables if it maps to one, otherwise use plain values and say so. Constraints: no external icon libraries, use inline SVG only; must be a single component file Where the screenshot is ambiguous (a cut-off edge, an icon you're not fully sure of, a hover state you can't see), say what's ambiguous instead of silently inventing a specific value. Output: a single component file plus a one-line list of anything you were unsure about
Customize the highlighted detailsoptional — the prompt above already works
Why this works
Gemini's multimodal vision path reads the screenshot's actual pixel layout — spacing, alignment, proportional sizing — directly, rather than working from a text description of the design, which is what makes 'match, don't reinterpret' an enforceable instruction rather than wishful thinking; without it, the model tends to substitute its own aesthetic defaults for the ones actually shown (different spacing scale, a component pattern it's seen more often in training). Explicitly requiring visible states (disabled, focused, badge counts) to be included counters the tendency to treat a screenshot as a static mockup of the 'happy path' only and quietly drop states that would otherwise need separate design documentation. The ambiguity-flagging instruction targets cropped or unclear regions specifically — a cut-off icon or an edge that's out of frame gets filled with a plausible guess by default, and naming that guess as a guess is the difference between code you can trust and code you have to re-verify against the original design anyway.
What you get back
export function PricingCard() { return ( <div className="rounded-xl border p-6 shadow-sm"> <h3 className="text-lg font-semibold">Pro</h3> <p className="text-3xl font-bold mt-2">$29<span className="text-sm font-normal">/mo</span></p> <button className="mt-4 w-full rounded-md bg-black text-white py-2" disabled> Current plan </button> </div> ) } Unsure about: the small icon next to "Pro" was partially cut off at the top edge of the screenshot — used a generic badge placeholder instead of guessing which icon it was.
Verified against
Gemini Gemini 3 Pro · 2026-07-02
Changelog
- 2026-07-02 — Initial publish, verified against Gemini 3 Pro on a cropped pricing-card screenshot.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
