How to Take Website Screenshots for a Web Design Handoff Document
Capture the right pages, viewport sizes, and UI states for a clear design handoff, then label each image so developers know what to build.
A useful web design handoff is a small, labeled set of screenshots that shows the important pages, responsive layouts, and UI states a developer needs to implement. Use a viewport screenshot to show a particular layout at a known browser size, and a full-page screenshot to show the page’s complete vertical structure. Add concise notes for behavior and details that a static image cannot explain.
This guide walks through a Chrome DevTools workflow, a handoff checklist, and ways to capture and organize images. The steps are practical guidance based on Chrome and Figma’s documented features; there is no single universal handoff format.
1. Decide what each screenshot needs to communicate
Before capturing, write down the question each image should answer. This keeps the handoff focused and makes it easier to spot missing states.
| Capture | Use it to show | Useful context to record |
|---|---|---|
| Viewport screenshot | The layout visible at a particular width and height. | Viewport dimensions or device category, page, and state. |
| Full-page screenshot | The page’s vertical structure and content outside the initial viewport. | Page name and any sticky, lazy-loaded, or state-dependent content to verify. |
| Element capture | A specific component or region that needs focused review. | Component name and where it appears on the page. |
| Interaction-state screenshot | A material variation such as an open menu, selected tab, or validation message. | What action produces the state and what should happen next. |
One desktop screenshot rarely describes responsive behavior. Capture separate widths when the layout changes materially, such as when navigation collapses, columns stack, or a component changes arrangement. A screenshot documents appearance; pair it with a short note for transitions, rules, or interactions that cannot be inferred from a still image.
2. Capture viewport and full-page screenshots in Chrome DevTools
- Open the page in Google Chrome and open DevTools.
- Enable the Device Toolbar. Choose a device type or set the dimensions for the layout you need to document.
- Set the page to the intended state. For example, open the relevant menu or select the relevant tab before capture.
- In Device mode, open More options and select Capture screenshot to capture the current viewport, or Capture a full size screenshot to capture the page beyond the visible viewport.
- Repeat for each meaningful viewport and state. Use the same dimensions when comparing pages or states that should be reviewed at the same size.
- Give each image a descriptive filename and add a note with its page, viewport, state, and any non-obvious behavior.
Chrome Device mode simulates mobile or desktop rendering and lets you set viewport dimensions. Record the dimensions or device category in the handoff so the recipient knows what the image represents. Simulation is a useful reference for responsive layout; it does not by itself document every behavior on a physical device.
Example capture plan
| Page or component | Capture set | Note |
|---|---|---|
| Landing page | Desktop viewport, mobile viewport, full page | Record widths and identify the approved page reference. |
| Navigation | Desktop default, mobile closed, mobile open | State the trigger and expected close behavior. |
| Form | Default, validation error, success | Describe the input condition that produces each state. |
3. Label and annotate the handoff
Use a predictable name that answers what, where, and which state or viewport. For example: pricing-mobile-menu-open.png or home-desktop-full-page.png. Keep names consistent across the handoff rather than relying on vague labels such as final2.png.
- Identify the page and UI state shown.
- State the viewport dimensions or device category where responsive behavior matters.
- Include both viewport and full-page images when they answer different questions.
- Add concise callouts for spacing, behavior, content, or visual intent that is not self-evident.
- Link to the approved design or implementation reference and identify which source takes precedence.
- Mark designs ready for development if your team uses Figma Dev Mode.
Figma Dev Mode supports inspection, measurements, annotations, comparisons, and readiness statuses. Its current help documentation says Dev Mode is available on paid plans and requires a Full or Dev seat; check the current plan requirements before building a workflow around it. Figma’s Chrome extension can capture a webpage or selected element and paste it into Figma Design or FigJam as editable layers. That can help teams already working in Figma, but an editable capture is still a reference to validate against the live site.
4. Choose a handoff format that suits the team
A shared folder with clearly named images and a short index is enough for many handoffs. A design workspace can be useful when the team needs editable layers, inspection, annotations, or readiness tracking. Choose based on what the recipient needs to do with the reference, not just on where it is easiest to paste an image.
- Static files: straightforward to share and review; include viewport and state details in filenames or an index.
- Figma workflow: the Chrome extension can capture a page or element into editable layers; Dev Mode adds inspection and handoff context. Feature access can depend on plan and seat.
- Automated capture: useful when you need repeatable image files across URLs, viewports, or states. Confirm that the capture method can reproduce the required page state and viewport.
5. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. A single GET request can return a PNG, JPEG, WebP, or PDF. For a quick handoff reference, this runnable cURL example saves a WebP screenshot:
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-o shot.webp
See the ScreenshotNeo API documentation for request options. The following Python and Node.js examples make the same request.
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
timeout=90,
)
r.raise_for_status()
with open("shot.webp", "wb") as image:
image.write(r.content)
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(({ writeFile }) =>
writeFile('shot.webp', Buffer.from(await res.arrayBuffer()))
);
Replace the example URL with the page you are documenting. Keep API keys on the server or in a secret store; do not put a private key in a public webpage. To document responsive layouts or interactive states, use the API’s viewport and interaction options described in the docs, and verify the returned image before sharing it.
ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each of these steps can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response reports the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan.
Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.
6. Troubleshooting screenshot handoffs
| Problem | Likely cause | What to do |
|---|---|---|
| The image does not show the intended responsive layout. | The viewport was set after capture, or the wrong dimensions were used. | Set the Device Toolbar dimensions first, recapture, and include the dimensions in the label. |
| A menu, dialog, or selected state is missing. | The page was captured in its default state. | Reproduce the state before capture and label the action or condition that creates it. |
| The full-page image is very long and hard to review. | A full-page capture was used for a question about a specific visible area. | Keep the full-page image for structure, and add focused viewport or element captures for detail. |
| The screenshot seems to omit content loaded later. | Content may appear after scrolling, a delay, or an interaction. | Load the content before capture and note any steps required to reveal it. For automated capture, configure an appropriate wait condition. |
| Reviewers disagree about what to implement. | The screenshot lacks state, viewport, behavior, or source-of-truth context. | Add a brief annotation and link the approved design or implementation reference. |
| A Figma capture or Dev Mode feature is unavailable. | Feature access may depend on the plan or seat. | Check Figma’s current plan and seat requirements, or share clearly labeled static captures. |
7. Performance, reliability, and cost considerations
For a one-off page, DevTools avoids setting up an automation workflow. For a repeatable handoff across many pages or viewports, automation can reduce manual repetition, but only if page state and capture settings are controlled. A full-page image is larger and less convenient for close inspection than a viewport image, so include it only when it communicates useful structure.
Pages that load content lazily or depend on user interaction can produce incomplete captures unless the content is loaded and the correct state is prepared. Capture the same viewport and state when making comparisons, and retain the page URL and capture context alongside the image so the reference can be reproduced. A screenshot is a static record; it cannot replace notes about transitions, responsive rules, or behavior.
DevTools capture is included in the browser workflow described above. Figma’s extension and Dev Mode have plan or seat requirements noted in Figma’s documentation, which can change; verify current access before standardizing on them. ScreenshotNeo offers 1,000 shots a month free with no card; paid plans are Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free. Only clean shots are billed, and cache hits, bot checks/CAPTCHAs, blank pages, timeouts, and failed loads cost nothing.
Frequently asked questions
Should a handoff use viewport or full-page screenshots?
Use a viewport capture to communicate a layout at a known size and a full-page capture to communicate vertical structure. Include both when they serve different review needs.
How many viewport sizes should I capture?
Capture each width at which the layout or an important component changes. Label the dimensions or device category; there is no single set of widths that fits every site.
Can a screenshot fully specify an interaction?
No. Capture important states, then add a note describing the trigger and expected behavior.
Can I put website screenshots directly into Figma?
Figma’s Chrome extension can capture a page or element and paste it as editable layers into Figma Design or FigJam. Check current feature access and validate the capture against the live page.
Sources
- Chrome DevTools: Device mode documents device simulation, viewport settings, and viewport and full-size screenshot capture.
- Figma Chrome extension describes capturing pages or elements into Figma.
- Figma Dev Mode guide documents inspection, annotations, measurements, readiness statuses, and seat/plan requirements.


