Best Way to Capture the Same Website Screenshot on iPhone and Android

For a controlled, comparable website screenshot, capture the page in a desktop browser’s mobile emulation with the same viewport width, viewport height, and device pixel ratio (DPR) for both comparisons. If you need to show exactly what people see on actual phones, capture on each phone instead. Those native screenshots can differ because the devices and browsers render pages differently; matching the URL alone does not make the images pixel-identical.

First decide what “the same screenshot” means for your task:

Compare layout at a controlled size: use Chrome DevTools Device Mode or Safari Responsive Design Mode and set matching dimensions and DPR.
Record the actual phone experience: use the built-in screenshot workflow on each phone and label the result with its device, OS, browser, orientation, and capture type.
Save a long webpage: use a scrolling or full-page capture. This is different from capturing the same fixed-height viewport on both phones.

Both phones have built-in screenshot features, so you do not need to buy an accessory or install a separate app for a basic capture. For layout testing, browser emulation is usually the more controlled method; Apple notes that emulated device presets are approximations and do not reproduce every real-device detail.

1. Choose the capture method that matches your goal

Goal	Recommended method	What to keep in mind
Compare the same responsive layout dimensions	Desktop browser mobile emulation	Set the same viewport width, height, and DPR. Emulation does not reproduce every detail of physical phones.
Show what users actually see on each phone	Native screenshots from both phones	Device dimensions, pixel density, browser interface, and platform behavior can differ.
Save an entire long page	iPhone Safari Full Page or Android Capture more	These produce scrolling captures, not equal-height viewport screenshots.

For a fair visual comparison, align the URL, page content and interaction state, orientation, viewport dimensions, DPR when available, browser zoom, scroll position, and timing. For example, a cookie banner visible in one capture but dismissed in the other makes the screenshots incomparable even if the device dimensions match.

2. Compare layouts with mobile browser emulation

Open the same page in a desktop browser and open its developer tools.
Enable mobile device emulation. In Chrome, use DevTools Device Mode.
Enter or select a viewport width and height. Use those exact values for every capture.
Set the DPR, orientation, and browser zoom consistently where the browser allows it.
Load the same URL and put the page in the same state: dismiss or retain consent dialogs consistently, use the same account or test data, and wait for dynamic content to settle.
Capture the visible viewport for an above-the-fold comparison, or use the browser’s full-size screenshot option when you need the whole document.
Repeat with the same settings and compare the resulting files.

Chrome documents mobile device emulation and full-size screenshots in its Device Mode documentation. For Safari-oriented previews, Apple’s Responsive Design Mode lets you set viewport dimensions and pixel ratio. Apple cautions that presets only approximate real devices; browser chrome, keyboards, form controls, and device-specific behavior can still differ.

Viewport size and DPR are different settings

The viewport is the layout area in CSS pixels. DPR relates CSS pixels to rendered device pixels. A 390-pixel-wide CSS viewport at DPR 2 can produce a raster image with different pixel dimensions from a viewport at DPR 3, even though the page’s CSS layout width is the same. For a layout comparison, match both when possible. If you only need the same CSS layout, matching viewport dimensions is the key; if you need comparable output image dimensions and sharpness, match DPR too.

What emulation does and does not prove

Emulation is useful for repeatable responsive-layout checks. It does not prove the page behaves identically on physical iPhones and Android phones. If the question is what customers actually see, capture on the real devices and record their details rather than expecting pixel-for-pixel equality.

3. Take a full-page screenshot on iPhone

Open the webpage in Safari.
Take a screenshot. On Face ID iPhones, press the Side button and Volume Up together. On iPhone models with a Home button, press Side and Home together.
Tap the screenshot preview.
Select Full Page to capture content beyond the visible screen.
Save the result as an image or PDF.

Apple describes this option as a way to capture content longer than the screen, such as an entire Safari webpage. A Full Page result is a scrolling capture; use a normal screenshot when you need the visible viewport only. See Apple’s instructions for taking a screenshot on iPhone.

4. Take a scrolling screenshot on Android

Open the webpage and press Power + Volume Down together.
In the screenshot preview, tap Capture more.
Adjust the crop guides to include the scrollable content you need, then save.

Google documents this workflow for Android 12 and later on most screens that allow scrolling. Availability and button labels may vary by device. If the option is missing or the buttons differ, consult the phone manufacturer’s support instructions. See Google’s Android screenshot instructions.

5. Keep the captures comparable

Use this checklist before you capture:

Same target: use the same canonical URL, including relevant query parameters.
Same page state: match login state, selected tab, expanded menus, consent choice, and loaded content.
Same orientation: portrait and landscape layouts can have different breakpoints.
Same viewport and DPR: set these in emulation; for native captures, record the device instead of assuming the values match.
Same zoom and scroll position: browser zoom changes layout, and a different scroll position changes the visible content.
Same capture type: compare viewport with viewport, or full page with full page.
Same timing: wait for fonts, images, animations, and client-rendered content to settle. Capture both pages at comparable points.
Record provenance: note device model, OS, browser, viewport, DPR if known, orientation, and whether the image is a viewport or scrolling capture.

For automated visual checks, use a stable test page or account and avoid content that changes on every load. If animations affect the result, wait for a consistent frame or disable them in the test setup. Do not treat a native full-page capture and a browser-emulated viewport image as equivalent outputs.

6. Automate a repeatable screenshot with code

Browser automation is useful when you need to capture the same URL repeatedly with explicit viewport settings. The following examples use Playwright and set the same viewport and DPR for both runs. They produce one image per browser context; they do not claim to reproduce every physical iPhone or Android behavior.

JavaScript with Playwright

import { chromium } from 'playwright';

const url = 'https://example.com';
const settings = {
  viewport: { width: 390, height: 844 },
  deviceScaleFactor: 2,
};

const browser = await chromium.launch();
for (const name of ['iphone-sized', 'android-sized']) {
  const context = await browser.newContext(settings);
  const page = await context.newPage();
  await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
  await page.screenshot({ path: `${name}.png`, fullPage: false });
  await context.close();
}
await browser.close();

To capture the full document, change fullPage: false to fullPage: true. The labels in this example identify two output files; the settings are intentionally identical, so this is a controlled layout capture rather than a simulation of distinct phone hardware.

Python with Playwright

from pathlib import Path
from playwright.sync_api import sync_playwright

url = "https://example.com"

with sync_playwright() as p:
    browser = p.chromium.launch()
    for name in ("iphone-sized", "android-sized"):
        context = browser.new_context(
            viewport={"width": 390, "height": 844},
            device_scale_factor=2,
        )
        page = context.new_page()
        page.goto(url, wait_until="networkidle", timeout=60_000)
        page.screenshot(path=f"{name}.png", full_page=False)
        context.close()
    browser.close()

Install the Playwright package and its browser before running the example. If the page maintains long-lived network connections, network idle may never occur; use a bounded wait for a known page element instead, or wait for the page’s main content and then capture.

cURL, Python requests, and Node.js with ScreenshotNeo

These one-request examples capture a URL through ScreenshotNeo. They are a hosted alternative when you do not want to install and operate browser automation. See the ScreenshotNeo API documentation for parameters and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

For Node.js versions without Bun.write, use node:fs/promises to save the response body:

import { writeFile } from 'node:fs/promises';

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request returns a PNG, JPEG, WebP, or PDF. Its clean-shot flow accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Every feature is on every plan. Learn about ScreenshotNeo, review the API docs, or sign up for 1,000 free screenshots a month with no card.

8. Troubleshooting

Symptom	Likely cause	Fix
The screenshots have different page layouts	Viewport width, orientation, zoom, page state, or content differs.	Match those settings and the page state. Check for different consent choices, account data, or responsive breakpoints.
The files have different pixel dimensions	DPR or capture type differs, or one image is a full-page capture.	Match DPR and compare viewport captures with viewport captures. Record native device output dimensions rather than assuming equivalence.
A full-page option is missing on iPhone	The page or capture flow may not offer Full Page in that context.	Use Safari, take the screenshot, open its preview, and check for Full Page. For other contexts, use browser emulation or a capture tool that supports full-page screenshots.
Android does not show Capture more	The phone may not be on Android 12 or later, or the current screen may not support scrolling capture.	Try a scrollable webpage on a supported device. Check the manufacturer’s instructions if the option or button combination differs.
The automated page never reaches network idle	Analytics, streaming, or other long-lived requests keep the network active.	Wait for a meaningful page element or use a bounded delay after navigation instead of waiting indefinitely for network idle.
The screenshot contains a loading state or missing images	Capture happened before client rendering, fonts, or lazy-loaded images finished.	Wait for a stable selector and required images. For long pages, scroll through content before a full-page capture if the site loads images lazily.
ScreenshotNeo returns an error instead of an image	The request may have an invalid key, malformed URL, or non-success response.	Check the API key and URL, inspect the HTTP status and response headers, and consult the API documentation.

9. Performance, reliability, and cost

Native capture: requires no extra service or browser setup and reflects the current phone’s view. It is manual and the results are not guaranteed to match across different devices.
Browser emulation: makes viewport and DPR easy to control for repeatable comparisons. It still differs from physical device rendering and behavior.
Automation: removes repetitive manual steps, but browser startup, page load, dynamic content, and network waits affect duration and consistency. Set timeouts and wait for page-specific readiness rather than an unbounded condition.
Hosted API: avoids maintaining browser infrastructure. ScreenshotNeo offers 1,000 shots per month free with no card; paid plans are $5 for 3,000, $15 for 15,000, $39 for 60,000, $99 for 250,000, and $249 for 1,000,000. Yearly billing gives two months free. The product states that only clean shots are billed and exposes verdict and billing headers.

For a one-off comparison, native screenshots or DevTools are sufficient. For repeated capture jobs, choose a stable viewport and page state, add explicit timeouts, and retain device or configuration metadata with each image so differences can be reproduced.

10. FAQ

How do I make iPhone and Android screenshots the same size?

Use browser emulation and set the same viewport width, height, and DPR. Native screenshots can have different output dimensions because the phones have different screens and pixel densities.

Will the same website screenshot look identical on both phones?

No. Even with the same URL, rendering, browser interface, device characteristics, and page state can differ. Use emulation for controlled layout comparison or real devices for actual user experience.

Can I capture an entire webpage on both platforms?

Yes. Safari on iPhone offers Full Page capture for webpages, while Android 12 and later supports Capture more on most scrollable screens. These workflows create scrolling captures, not ordinary viewport screenshots.

Should I use a phone emulator for customer-facing evidence?

Use physical phones when the evidence needs to represent those devices. Emulation is appropriate for repeatable layout checks, with its limits stated.