How to Test Responsive Website Screenshots at iPhone 12 mini Size
Use a 375 CSS pixel baseline to check iPhone 12 mini layouts, then validate Safari behavior with Responsive Design Mode, Simulator, and automation.
For an iPhone 12 mini portrait layout baseline, use a viewport width of 375 CSS pixels. For a repeatable automated profile, Playwright’s iPhone 12 Mini descriptor specifies a 375 × 812 screen, a 375 × 629 viewport, and a 3× device scale factor. Treat those as automation configuration values, not a promise about the height Safari will show on every device: browser chrome, the keyboard, and device behavior can change the visible area.
A practical workflow is to check the page’s viewport declaration, inspect it at 375 points in Safari Responsive Design Mode, then use Simulator or a physical iPhone when you need to verify iOS-specific behavior. Use Playwright when you need repeatable screenshots in a development or CI workflow.
1. Know which iPhone 12 mini dimensions to test
CSS viewport dimensions and screenshot image pixels describe different things. The layout baseline is 375 CSS pixels wide. A 3× device scale factor means each CSS pixel maps to three output pixels in a device-scale screenshot, so a 375 CSS pixel-wide capture can be 1125 image pixels wide. The descriptor’s 375 × 629 viewport is useful for repeatable automation; it does not define the universal height visible in Safari.
| Value | How to use it |
|---|---|
| 375 CSS px wide | Portrait responsive layout baseline |
| 375 × 812 screen | Playwright device descriptor screen dimensions |
| 375 × 629 viewport | Playwright descriptor viewport configuration; not a universal Safari visible area |
| 3× device scale factor | High-density rendering and screenshot output resolution setting |
For layout defects, start with CSS pixel dimensions. Check scale factor separately when reviewing raster assets, fine borders, or resolution-dependent styles. A screenshot’s pixel dimensions alone do not tell you what CSS viewport produced it.
2. Check the page viewport declaration
Confirm the document includes a mobile viewport declaration, commonly:
<meta name="viewport" content="width=device-width, initial-scale=1">Without a suitable declaration, mobile browsers may lay out a page against a wider virtual viewport and scale it down, making a responsive layout look unlike the intended 375 CSS pixel view. Apple’s archived Safari guidance recommends width=device-width for iOS web applications. See Apple’s Safari HTML reference.
3. Inspect at 375 points in Safari Responsive Design Mode
- Open the page in Safari on macOS.
- Choose Develop > Enter Responsive Design Mode.
- Set the preview width to 375 points for the portrait layout check.
- Set pixel ratio to 3× when checking density-sensitive assets or styles.
- Rotate the preview and inspect landscape behavior as well.
- Keep Web Inspector open while resizing so you can examine overflowing elements and their computed styles.
Inspect navigation wrapping, clipped controls, text wrapping, image sizing, form fields, and horizontal overflow. Responsive Design Mode is useful for quick checks of media queries and dynamic styles, but its presets approximate device behavior. It does not fully reproduce every browser-chrome, keyboard, or device-specific form-field condition. Apple describes the feature in its Responsive Design Mode documentation; WebKit also documents its Safari and Simulator workflow.
4. Validate iOS behavior with Simulator or hardware
Use Open with Simulator from Responsive Design Mode when you need a closer look at iOS rendering and interactions without a physical phone. Check the conditions that a static viewport preview cannot settle: browser address-bar changes, the on-screen keyboard, and device-specific form-field behavior. If a release decision depends on exact behavior on the target hardware, validate on a physical iPhone 12 mini. You do not need that hardware for routine responsive layout iteration.
| Method | Best use | Limit |
|---|---|---|
| Safari Responsive Design Mode | Fast width, height, orientation, and pixel-ratio checks | Presets approximate devices; they do not fully reproduce browser chrome, keyboard, or device-specific form behavior |
| iOS Simulator | Closer inspection of iOS rendering and interaction | Still a simulation |
| Physical iPhone 12 mini | Final check when exact target-device behavior matters | Requires access to the target hardware; not needed for every layout iteration |
| Playwright device profile | Repeatable automated capture configuration | Versioned configuration does not prove equivalence to physical Safari |
5. Automate a baseline screenshot with Playwright
Playwright includes an iPhone 12 Mini device descriptor. The descriptor on the mutable main branch specifies WebKit as the default browser type and sets mobile and touch flags along with the screen, viewport, and scale values above. Check the descriptor in the exact Playwright version installed by your project; do not assume current main-branch values match a pinned release. See the Playwright device descriptor source.
Install Playwright and its browser if your project does not already have them:
npm install --save-dev playwright
npx playwright install webkitSave this as iphone12mini-screenshot.cjs and run node iphone12mini-screenshot.cjs https://example.com. It uses the installed package’s device profile, opens the URL, waits for the page load event, and writes a full-page PNG.
const { chromium, devices } = require('playwright');
(async () => {
const target = process.argv[2];
if (!target) throw new Error('Usage: node iphone12mini-screenshot.cjs https://example.com');
const browser = await chromium.launch();
try {
const context = await browser.newContext({ ...devices['iPhone 12 Mini'] });
const page = await context.newPage();
await page.goto(target, { waitUntil: 'load', timeout: 30000 });
await page.screenshot({ path: 'iphone-12-mini.png', fullPage: true });
await context.close();
} finally {
await browser.close();
}
})().catch(error => {
console.error(error);
process.exitCode = 1;
});The example launches Chromium while applying the descriptor’s viewport, scale, mobile, and touch settings. To use the descriptor’s WebKit browser type, launch WebKit instead:
const { webkit, devices } = require('playwright');
const browser = await webkit.launch();
const context = await browser.newContext({ ...devices['iPhone 12 Mini'] });Keep the browser and context settings explicit in your project. The device profile is a useful reproducible starting point, not proof that automation matches every physical Safari detail. fullPage: true captures the full document; omit it when you want only the configured viewport. Use the same setting consistently when comparing screenshots.
6. Make screenshot comparisons useful
- Keep the CSS viewport, device scale factor, browser engine, URL state, and full-page versus viewport-only choice consistent between runs.
- Wait for the content you need to inspect. A page load event does not guarantee that client-rendered data, fonts, animations, or delayed images have settled.
- Use a stable test page state, such as a known route and deterministic content, so dynamic data does not obscure layout changes.
- Compare both portrait and landscape if the page needs to support rotation.
- For lazy-loaded content, scroll or otherwise trigger it before capturing if it is part of the behavior under review.
- Review the page interactively as well as in a static image when keyboard, focus, scrolling, or browser chrome affects the result.
Do not infer physical display sharpness from a resized preview. Check the original screenshot dimensions and scale settings separately from the CSS layout width.
7. Troubleshoot common problems
| Symptom | Likely cause | Fix |
|---|---|---|
| Page looks like a scaled desktop layout | Missing or unsuitable viewport meta tag | Add width=device-width, initial-scale=1 and reload at 375 points |
| Screenshot is 1125 pixels wide, not 375 | 3× device scale factor affects output pixels | Check the CSS viewport separately; 375 CSS px at 3× can produce 1125 image pixels |
| Automated screenshot height differs from Safari | The descriptor viewport is an automation setting; browser chrome and keyboard change visible area | Use 375 px as the layout width baseline and validate visible-height behavior in Simulator or on hardware |
| Controls are cut off or the page scrolls sideways | Fixed widths, oversized media, or long unbreakable content | Inspect the overflowing element in Web Inspector; constrain media and review widths and wrapping rules |
| Screenshot captures loading placeholders | Capture occurred before client-rendered content or delayed resources settled | Wait for a page-specific ready condition or selector before taking the screenshot |
| Screenshot differs between Playwright upgrades | Device descriptor or browser versions changed | Pin the project version and inspect the descriptor bundled with that version |
| Form looks correct but fails on an iPhone | Static preview does not reproduce all keyboard and device-specific field behavior | Try Simulator, then a physical target device if the behavior is release-critical |
8. Reliability, speed, and cost considerations
Responsive Design Mode is convenient for quick interactive checks. Simulator adds setup but can reveal iOS-specific rendering and interaction behavior. Playwright makes the viewport and scale configuration repeatable and suitable for automation, but it still depends on the browser version, page state, and readiness conditions. A physical-device check takes more access and effort, so reserve it for behavior where the real device matters.
No sourced performance benchmark establishes how long these methods take, so plan around your own page and environment. For reliable comparisons, control the browser version and test state, wait for required content, and distinguish viewport captures from full-page captures. Safari tools and Simulator have no screenshot-service per-capture charge described here; automation cost depends on the machine or CI environment running it.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF; the example below requests an image of the page. See the ScreenshotNeo API documentation for options. For an iPhone 12 mini baseline, set the viewport to 375 × 812 and device scale factor to 3 using the API’s documented parameter names.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpPython
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)Node.js
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 Bun.write('shot.webp', res);Replace the example target URL with your page. ScreenshotNeo can set a custom viewport and scale, capture a full page or a CSS-selected element, and wait for a selector, delay, or network idle. Before capture it accepts the cookie or consent banner like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each cleanup step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf 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. Sign up free and get 1,000 screenshots a month with no card.
FAQ
What viewport width should I use for an iPhone 12 mini screenshot?
Use 375 CSS pixels for the portrait layout baseline.
Should I set the screenshot to 375 or 1125 pixels wide?
Set the layout viewport to 375 CSS pixels. At a 3× device scale factor, the resulting image may be 1125 pixels wide.
Is a Playwright screenshot the same as a real iPhone 12 mini?
No. It gives a repeatable configuration. Use Simulator or physical hardware to investigate iOS-specific behavior that a viewport profile cannot establish.
Do I need an iPhone 12 mini for responsive testing?
No. Safari Responsive Design Mode, Simulator, and automation cover routine checks. Use the physical device when the release depends on exact target hardware behavior.
