Set a CSS viewport width and height, render the page in a real browser, and record the responsive state your layout produces. Use the result for breakpoint QA, documentation, campaign review, and visual comparisons without resizing a desktop screenshot.
curl -X POST https://api.prod.ss.snapshot-site.com/api/v1/screenshotx-snapshotsiteapi-key: YOUR_API_KEY
Mobile website capture is the regular screenshot request with a smaller CSS viewport. It exercises responsive layout rules, but it is not a physical-device emulator and does not reproduce every device-specific browser behavior.
A useful representative viewport for testing compact navigation, single-column content, and the initial fold.
A second representative width that can reveal breakpoint assumptions hidden by testing one phone size.
Standard tablet viewport for tablet-specific QA and documentation.
Store artwork rules and physical-device screenshots are separate requirements. Confirm the destination specification before using a website viewport capture.
Get an API key from the console
POST a URL with the CSS viewport width and height you want to test
Set fullSize: true for full-page mobile captures, false for above-the-fold assets
Repeat across your device/locale matrix in a simple loop
Capture a page at a common iPhone layout viewport.
curl --request POST \
--url https://api.prod.ss.snapshot-site.com/api/v1/screenshot \
--header 'Content-Type: application/json' \
--header 'x-snapshotsiteapi-key: YOUR_API_KEY' \
--data '{
"url": "https://example.com",
"format": "png",
"width": 390,
"height": 844,
"fullSize": false
}'
A mobile screenshot is useful when it records a page state that exists only at a narrow viewport: a collapsed menu, stacked pricing cards, shorter headings, touch-sized controls, or a different initial fold. Taking a desktop image and scaling it down preserves the desktop layout, so it cannot validate any of those behaviors.
Snapshot Site sets the width and height used by the browser viewport. The page then evaluates its media queries and responsive component logic before the screenshot is created. That makes the output useful for website QA and content review. It does not turn the service into a physical phone farm, and it should not be described as exact emulation of a named device.
This distinction matters. A real device can differ through its browser chrome, operating-system font rendering, device pixel ratio, touch behavior, safe areas, and hardware-specific features. Use real-device testing when those differences are the question. Use viewport screenshots when the question is whether the website's responsive layout is correct at a controlled CSS size.
Analytics and support reports should lead the selection. If most traffic clusters around a narrow phone width and a wider phone width, test both. Add a tablet breakpoint only if the product has meaningful tablet usage or a layout rule that changes there.
Avoid building a list of every device sold. Many devices share similar CSS viewport widths, and maintaining dozens of nearly identical captures creates review fatigue. A small matrix tied to actual breakpoints is easier to understand and more likely to be checked.
Use identifiers such as phone-narrow-390, phone-wide-412, and tablet-portrait-768. These names describe the input you control. A label such as “latest iPhone” becomes stale, suggests device emulation, and does not reveal the viewport used to create the image.
Store width, height, full-page mode, delay, and format with every baseline. A filename alone is not enough to recreate a result months later.
Width selects responsive layout. Height controls the visible fold when fullSize is false. This is valuable for checking whether a CTA, important notice, or first product card appears in the initial viewport.
Set fullSize: true when the review needs the complete responsive page. The browser keeps the selected narrow width and captures the scrollable document. Long mobile pages can be much taller than desktop pages because every section stacks, so use full-page mode intentionally.
Capture critical routes after a preview deployment and compare each one with the baseline for the same width. Pricing, checkout, sign-in, account, and campaign pages are good starting points. Do not compare a 390-pixel image with a 1440-pixel baseline; the changed dimensions make the result meaningless.
The Visual Diff API can compare two live page states or a live page with an existing image. Keep both sources on the same viewport settings and hide known dynamic regions before setting an alert threshold.
Support teams often need to show a mobile navigation path or compact form state. Capture the real responsive page at a controlled size rather than cropping a desktop image. When documentation changes, regenerate only the affected routes and keep the viewport name next to the asset.
A desktop hero can leave the primary action far below the fold on a phone. Capture the initial viewport at the widths that matter and review copy wrapping, image cropping, consent overlays, and sticky banners. A full-page image can then confirm that lower sections remain ordered correctly.
A scheduler can capture the same mobile breakpoint daily or after a publish event. Compare it with its previous approved state and route only meaningful differences for review. The Website Monitoring API explains baseline ownership and alert design.
Responsive applications often hydrate after the initial HTML response. Menus, product grids, localization, and personalization may appear after JavaScript runs. Use a small delay supported by observed page behavior, not a large default applied to every request.
Lazy images below the fold can also affect a long mobile capture. Test representative pages and confirm whether the target loads those images before a full-page screenshot. Remove animations and rotating content where you control the page; otherwise mask or hide regions that create noise.
Cookie banners are especially disruptive on a small viewport because they can cover most of the visible area. Use hideCookie for common banners and verify the result. If a site uses a custom overlay, handle it with the documented cleanup controls rather than assuming every consent system behaves alike.
Run mobile captures from a backend, CI job, worker, or approved automation platform. Keep the API key in a secret store and never ship it in mobile web JavaScript. If URLs contain session or preview tokens, sanitize logs and use short-lived credentials.
Limit scheduled capture frequency to the rate at which the page or business requirement changes. A three-breakpoint matrix triples work compared with one capture; full-page output can also be more expensive to render and store than a viewport image. Cache approved assets and prevent overlapping jobs from processing the same route twice.
No. The API sets a browser viewport width and height so responsive CSS can render at that size. It does not claim to reproduce every hardware, operating-system, or mobile-browser behavior of a named device.
Choose widths from your analytics and design breakpoints. A small matrix such as 390, 412, and 768 pixels often reveals more than one device label.
Yes. Capturing at a narrow viewport lets media queries, wrapping, navigation, and responsive components render in their mobile state before pixels are recorded.
Yes. Set the mobile width and fullSize to true. The resulting image records the scrollable page using the responsive layout selected at that width.
They have different dimensions and intended layouts, so a direct pixel mismatch is not a regression signal. Compare each breakpoint with its own approved baseline.
Yes. It opens the page in a real browser. Use a measured delay when hydration, lazy content, or fonts complete after navigation.
Only when the capture and final asset satisfy the store's current rules. A responsive website screenshot is not automatically equivalent to a native application screenshot.
Fix width, height, timing, format, locale, full-page behavior, and hidden elements. Compare the same breakpoint against a baseline produced with the same settings.
Start with one high-traffic mobile width, capture a representative page, and expand into a small evidence-based viewport matrix.