Why Screenshots Make Bad Prompts (and What to Paste Instead)

The most common way people hand a design to an AI coding tool is a screenshot. Grab the region, paste it into Cursor or Claude, type "build this", and wait. The result is usually close enough to be encouraging and wrong enough to be annoying. The spacing is off, the font weight is wrong, the shadow is a flat grey smear, and the whole thing falls apart at tablet width.

That is not the model's fault. It is doing the best it can with a picture. This post is about what a picture leaves out, and what to paste instead.

What a screenshot actually contains

A screenshot is a grid of pixels. From it, a vision model can infer the rough layout, the approximate colours, the text content and a general sense of type size. Everything else is a guess.

Here is a partial list of what it has to guess:

Exact colours. Anti-aliasing, subpixel rendering and image compression mean the hex value the model reads off a screenshot is rarely the one in the stylesheet. "Something like #6366f1" becomes #6B5FE8, and the brand colour drifts.
Spacing. A 24px gap and a 20px gap look the same at a glance. The model picks a round number and moves on. Across a whole component, those small guesses add up to a layout that looks subtly cheap.
Typography. Font family, weight, letter spacing and line height are all approximations from a screenshot. Inter at 600 and Inter at 500 are hard to tell apart in a picture, and easy to tell apart on a page.
Shadows, blurs and gradients. A box shadow with two layers and a 1px inset ring looks like "a shadow". The model writes shadow-md and the depth is gone.
Layout mechanism. Is that row a flex container with gap, a grid with fixed columns, or absolutely positioned children? The picture does not say, so the model picks whatever it uses by default.
Responsive behaviour. A screenshot is one viewport. The model has no idea the three columns stack at 768px or the nav collapses at 640px.
Hidden structure. Pseudo-elements, inline SVGs, images with object-fit, borders that are actually gradients. All flattened.

Any one of these is a small error. Together they are the difference between "looks like the reference" and "is the reference".

Why the output drifts

Because the model is guessing, every guess is pulled towards its defaults. Default spacing scale, default shadow, default font stack, default radius. The more it has to infer, the more the result looks like every other AI-generated component.

Then you iterate. "Make the gap bigger." "The shadow should be softer." "That blue is wrong." Each round fixes one guess and leaves the rest. Three or four rounds in, you have spent longer describing the component than it would have taken to inspect it by hand.

What to paste instead

Give the model what the browser already knows. For any rendered element, the browser holds the full DOM subtree and the computed style of every node in it: the actual colour value, the actual padding, the actual font weight, the actual shadow definition. That is the ground truth. A prompt that includes it leaves nothing to guess.

This is what Pluck's AI prompt mode copies. When you pluck a component, the clipboard gets:

The element tree, so the model sees the real structure and nesting.
Computed styles for every node: layout, flexbox and grid properties, spacing, colours, typography, borders, shadows, transforms and images.
How the component changes at each responsive breakpoint, so the model knows what collapses where.
A screenshot, copied alongside the text, so the model can see the result it is aiming at.

The screenshot still goes along. It is useful as a target. It just is not the source.

You can also tell Pluck which stack you are building in. Pick Tailwind, CSS Modules, Styled Components or Vanilla Extract, and React, Vue, Svelte, Solid or Qwik, or leave it on Auto and let the prompt ask the model to match your project.

A concrete comparison

We tried both on a pricing card from a well-known billing provider.

Screenshot, pasted into Claude Code with "recreate this in React and Tailwind". The first output had the right three tiers and roughly the right proportions. The card radius was rounded-lg where the original was 16px. The highlighted tier's border was a plain 2px blue where the original was a gradient ring. Feature list spacing was space-y-2 where the original used 12px. The button used the default font-medium and the original was 600. At mobile width the cards overflowed because the model guessed grid-cols-3 with no breakpoint.

Pluck prompt, same instruction. The output used 16px radius, the gradient ring rendered as a wrapper with a gradient background and 2px padding, list spacing was 12px, the button weight was 600, and the grid dropped to one column below the breakpoint the capture recorded. Two things still needed a touch: a hover colour the capture could not see, and a font that was not installed locally.

One round versus four or five. That is the whole argument.

When a screenshot is enough

Sometimes a picture is the right input. If you want "something in the spirit of this" rather than a faithful rebuild, a screenshot plus a sentence of direction is fine, and arguably better, because the model will not be anchored to specifics you intend to change anyway. The moodboard workflow in Pluck Studio leans on that: references into a prompt, a brief that says what to keep, and an image out.

The rule of thumb: if you would be annoyed when the spacing is wrong, paste the styles. If you would not notice, paste the picture.

Try it on something real

Install Pluck from the Chrome Web Store, open any site, click the icon, and pluck a component you have tried to rebuild before. Paste it into your coding tool of choice with a one-line instruction. Then compare it with what you got from the screenshot. We have setup guides for Cursor, Claude Code and Lovable if you want the specifics for your tool.