Images, screenshots and visual work

What you’ll be able to do

Give Claude screenshots, mockups and diagrams as context, describe visual problems precisely, and run a “match this design” loop that reliably gets close to the target.

Why this matters

Some problems are hard to describe in words but obvious in a picture: a button that overlaps the text on a phone, a layout that should match a designer’s mockup, an architecture sketched on a whiteboard. Describing these in text loses detail and invites misunderstanding.

Claude can see images. Giving it the picture, together with a sentence about what you expect, is usually faster and more accurate than any description. The catch: on its own, Claude can’t see how its code actually renders. Getting good visual results means closing that gap, which is what the exercise in this lesson teaches.

Three ways to give Claude an image

1. Paste an image from your clipboard straight into the prompt: Ctrl+V on macOS and Linux (Cmd+V in iTerm2), Alt+V on Windows and WSL. A placeholder like [Image #1] appears in your prompt, and you can refer to it in your text (“in Image #1, the header…”).
2. Drag and drop an image file into the terminal window.
3. Reference a file path with @: “Look at @designs/checkout.png and…”. This is best for images that live in the project, such as design mockups.

What images are good for

• Bug reports: “This modal overflows on mobile; here’s what it looks like. Expected: the content scrolls inside the modal.” The image shows the problem, and the sentence says what “fixed” means.
• Mockups to code: “Build this card component to match the image.”
• Diagrams: a photo of a whiteboard sketch becomes a starting point: “Turn this into a Mermaid diagram and a list of the services it shows.”
• Error dialogs you can’t copy as text, such as a message box from a desktop app.

Exercise: match a design

You’ll build a small page that matches a picture, then improve it by showing Claude how its version actually looks. This compare-and-fix loop is the visual equivalent of running tests.

1. Set up a practice project:

mkdir visual-practice && cd visual-practice
git init
claude

2. Choose a target. Find a simple piece of UI you like, such as a pricing card or a login form, take a screenshot, and save it in the folder as target.png.

3. Ask for a first version:

Build index.html + styles.css that reproduces @target.png as closely as
possible. Use plain HTML/CSS, no frameworks. When done, list the differences
you expect between your version and the target.

What you’ll see: Claude creates the two files and lists where it’s unsure, such as exact fonts, colours or spacing. That list is useful: it tells you where to look first.

4. Show Claude the real result. Open index.html in your browser, take a screenshot of it, and paste it in:

Here's how it renders now (Image #1). Compare it with @target.png and fix the
three biggest differences.

What you’ll see: Claude names specific differences (“the button corners are square, the target’s are rounded”, “the heading is too large”) and adjusts the CSS.

5. Repeat two or three times. Each round should get visibly closer to the target.

Let Claude take the screenshots itself

Pasting screenshots by hand works, but you can close the loop completely:

• Claude in Chrome: start Claude Code with claude --chrome (or run /chrome in a session) with the Claude in Chrome browser extension installed. Claude can then open your page in your own Chrome or Edge browser, take screenshots, read console errors, click through forms and fix what it sees. It needs a direct Anthropic plan (Pro, Max, Team or Enterprise), and it doesn’t work inside WSL.
• The Desktop app has a built-in browser pane that Claude can use the same way.
• MCP browser servers are another option, covered in Module 5.
• Native apps: computer use lets Claude operate real desktop applications to check changes that only a graphical interface shows.

Tips for better visual results

• Crop to what matters. A full-screen screenshot of a small bug makes Claude hunt for it.
• Annotate with arrows or boxes when several things are wrong.
• Say what’s already right. “The layout is correct; only the spacing and font sizes are off” stops Claude from changing things that already work.
• Compare like with like. Take screenshots at the same window size as the target, or the comparison will mislead.

Common mistakes

• Sending an image with no explanation. Always say what you expect to be different.
• Expecting a pixel-perfect match in one step. Plan for two or three compare-and-fix rounds.
• Comparing at different screen sizes. Layouts change with width; keep the comparison fair.

Verify it worked

• You gave Claude an image by pasting, by drag and drop, or with an @ path
• You ran at least two compare-and-fix rounds against a target image
• Your final version is recognisably close to the target