How to Compare Responsive Website Screenshots at 375 and 414 Pixels

To compare responsive screenshots at 375px and 414px, capture the same page at those two CSS viewport widths while holding viewport height, browser zoom, device pixel ratio (DPR), browser version, page state, scroll position, and screenshot scope constant. Then compare the images side by side for intentional reflow and usability defects. The 39px width difference does not automatically mean a breakpoint should trigger.

For a one-off check, use Chrome DevTools Responsive mode. For repeat checks after code changes, automate both viewports with Playwright screenshot baselines and review the visual diffs.

1. Set up a fair comparison in Chrome DevTools

Open the same URL in Chrome and wait for the page to reach a meaningful, stable state.
Open DevTools and toggle the Device Toolbar. Choose Responsive mode.
Enter a width of 375 and a height you will also use for the second capture, such as 812. Record the chosen height; there is no requirement to use a particular height, only to keep it unchanged.
Set the Device Type, DPR, and viewport zoom deliberately. Keep each the same in both captures. Use the same network and CPU throttling state, if enabled.
Enable More options → Show media queries if you want to see active breakpoint ranges. DevTools can reveal the related CSS declaration from the breakpoint display.
Capture a viewport screenshot using More options → Capture screenshot. Use Capture a full size screenshot only if you intend to compare the entire page, and use it for both sizes.
Change only the width to 414. Recheck the other settings and capture again.
Open both files at the same display zoom and compare them side by side.

Chrome’s responsive toolbar accepts exact width and height values, offers DPR and device type controls, shows media query breakpoints, and supports viewport and full-page screenshots. Device emulation approximates a mobile experience; for behavior that depends on a particular device, verify on that real device too. Chrome DevTools device mode documentation.

2. Keep the capture conditions consistent

The goal is to make viewport width the only changed variable. A screenshot’s physical pixel dimensions are not necessarily its CSS viewport dimensions: DPR describes the ratio between physical hardware pixels and logical CSS pixels. Keep DPR fixed when diagnosing layout; vary it only when specifically checking image-resolution or high-density rendering behavior.

Setting	Keep consistent	Why it matters
Viewport height	Use the same height at both widths	A different height can change visible content, sticky elements, and height-based media queries.
DPR and zoom	Use the same DPR and viewport zoom	They can affect rendering and image pixel dimensions independently of CSS width.
Browser and version	Use the same browser build	Rendering, fonts, and screenshot output can vary across browser environments.
Device emulation	Keep device type and touch behavior fixed	Mobile versus desktop emulation can affect rendering and interaction events.
Page state	Use the same data, consent state, open menus, and animation state	Dynamic content can look like a responsive difference.
Scroll and capture scope	Use the same scroll position and viewport or full-page mode	Otherwise, images cover different portions of the page.

For dynamic pages, use stable test data, dismiss or set consent consistently, close or open the same controls, and wait for fonts and images before capturing. If animation is involved, pause it or capture at a reproducible point. Avoid comparing a partially loaded page to a settled one.

3. Tell a real responsive change from a defect

A fluid layout may simply gain 39px of room: text can wrap differently, columns can widen, and gaps can change without any breakpoint. If a media query lies between 375px and 414px, a deliberate layout transition may occur. The right question is whether that transition is intentional and keeps the content usable, rather than whether every pixel matches.

Inspect for:

Horizontal scrolling or content extending beyond the viewport.
Clipped buttons, navigation, form fields, or labels.
Overlapping elements, unexpected wrapping, or unreadable text.
Images wider than their container or awkward whitespace caused by a fixed width.
Important content hidden without a clear user-centered reason.
A breakpoint transition that happens at one width but leaves the other layout cramped or unbalanced.

Responsive design should work across a range of viewport widths, not only two named values. Flexible Grid and Flexbox layouts can adapt to available space; fixed-size images can create horizontal scrolling, so constrain them with max-width: 100% and provide intrinsic width and height to reserve space while they load. Check that the document includes a viewport declaration such as <meta name="viewport" content="width=device-width, initial-scale=1">; without a suitable viewport, a mobile browser may lay out the page at a wider default width. See web.dev’s responsive design guide and MDN’s responsive design guide.

4. Automate repeat comparisons with Playwright

For recurring checks, create one screenshot baseline per viewport. The following TypeScript test uses Playwright Test, opens the same page at 375px and 414px with a fixed height and DPR, waits for network activity to settle, and compares each screenshot against its stored baseline.

// responsive.spec.ts
import { test, expect } from '@playwright/test';

const target = process.env.TARGET_URL ?? 'http://127.0.0.1:3000';
const viewports = [
  { name: '375', width: 375, height: 812 },
  { name: '414', width: 414, height: 812 },
];

test('mobile layout matches visual baselines', async ({ browser }) => {
  for (const viewport of viewports) {
    const context = await browser.newContext({
      viewport: { width: viewport.width, height: viewport.height },
      deviceScaleFactor: 1,
      isMobile: true,
      hasTouch: true,
    });
    const page = await context.newPage();
    await page.goto(target, { waitUntil: 'networkidle' });
    await page.screenshot({ path: `actual-${viewport.name}.png` });
    await expect(page).toHaveScreenshot(`mobile-${viewport.name}.png`, {
      fullPage: false,
      animations: 'disabled',
    });
    await context.close();
  }
});

Install and run it from a project directory:

npm init -y
npm install --save-dev @playwright/test
npx playwright install chromium
# Save the test above as responsive.spec.ts
TARGET_URL=http://127.0.0.1:3000 npx playwright test responsive.spec.ts

On the first run, Playwright creates reference screenshots. Inspect the generated snapshots, then commit the reviewed baselines with the test. Later runs report differences against them. The screenshot assertions above check the viewport, matching the manual viewport captures; set fullPage: true in the assertion if full-page comparison is what you need.

Run the test on a page your local server can reach. If the app requires login or a particular state, add the appropriate setup before the screenshot and keep it deterministic. Playwright’s rendering can vary with operating system, browser version, settings, hardware, power state, and headless mode, so generate and compare baselines in the same environment. See Playwright visual comparisons.

Useful Playwright controls

viewport sets the CSS viewport dimensions; keep height identical between cases.
deviceScaleFactor fixes DPR. Set the same value for both widths and in baseline generation.
isMobile and hasTouch control mobile emulation and touch behavior. Keep them consistent with your test intent.
fullPage chooses viewport versus full-page capture. Do not compare one scope to the other.
animations: 'disabled' reduces animation-driven differences. If animation itself is under test, do not suppress it; instead arrange a deterministic capture point.
maxDiffPixels can allow a defined number of changed pixels, but a tolerance can also hide genuine regressions. Start strict and adjust only after reviewing the diff.
stylePath can inject a stylesheet that hides volatile elements. Use it only for genuinely irrelevant dynamic content, not to conceal layout defects.

When the baseline changes, review the actual and expected images and the diff before updating snapshots. Update them intentionally with npx playwright test --update-snapshots; do not automatically accept every changed image.

5. Troubleshooting common mismatches

Symptom	Likely cause	Fix
The screenshots have different pixel dimensions	Height, DPR, zoom, device frame, or capture scope differs.	Match those settings first. A 375 CSS-pixel viewport need not produce an image exactly 375 physical pixels wide when DPR is above 1.
The page looks zoomed out or media queries do not behave as expected	The viewport meta tag is absent or incorrect.	Use `<meta name="viewport" content="width=device-width, initial-scale=1">` and reload both captures.
Text, cards, or banners differ between runs at the same width	Live data, consent, rotating content, animations, fonts, or delayed assets changed.	Fix test data and page state, wait for required assets, and disable or freeze irrelevant animation.
Playwright reports a diff immediately after setup	No baseline exists yet, or the baseline came from another environment.	Review the first generated image and establish the baseline in the environment that will run subsequent comparisons.
A full-page result seems disproportionately different	Page height or lazy-loaded content changed, or only one capture is full-page.	Use the same scope and ensure the same content has loaded. For a focused layout check, compare viewport screenshots.
DevTools screenshot disagrees with a physical phone	Device emulation approximates, but does not reproduce every device condition.	Use remote debugging or capture on the target device when device-specific rendering or interaction matters.
A control is missing at 375px	It may be clipped, wrapped off-screen, covered, or intentionally hidden at a breakpoint.	Check horizontal overflow and the matching media query. Confirm that the control remains accessible and that hiding it is intentional.

6. Performance, reliability, and cost

Manual DevTools capture has no screenshot-service usage charge, but each comparison takes hands-on time and depends on a human keeping settings aligned. Playwright makes repeated checks consistent and can run in a development or CI workflow, but image baselines need review and the browser environment must remain stable. Capturing more viewports, pages, or full-page content increases work and stored artifacts; begin with the two widths and important pages, then expand coverage where a defect would matter.

Visual diffs are evidence to investigate, not automatic proof of a bug. Fonts, platform rendering, dynamic content, and browser changes can produce pixel differences. Keep the baseline environment stable, investigate unexpected changes, and update a baseline only when the new appearance is intended.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Use its API to request captures at the two target widths; its viewport option supports custom viewport sizes. Keep other capture settings the same for both requests. The example below demonstrates a single capture; repeat it for each width using the viewport setting described in the ScreenshotNeo API documentation.

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

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)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners, popups, and chat widgets are removed before the shot; each step can be turned off.
Bot checks, blank pages, and failed loads are never billed. Response headers say which page verdict and billing status apply.
An MCP server gives AI agents tools to take screenshots, inspect page information, and capture PDFs.
1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Are 375px and 414px physical screen widths?

In this workflow they are CSS viewport widths. Physical pixel output depends on DPR, which is why DPR should stay fixed for a layout comparison.

Should the page look identical at both widths?

No. Content can reflow naturally, and a breakpoint can intentionally change layout. Check whether the result is usable and whether the transition is expected.

Do I need a full-page screenshot?

Only if you need to compare content below the fold. For the visible mobile layout, viewport screenshots are simpler; use the same scope for both widths.

Are these two widths enough to validate responsive behavior?

They answer the specific comparison, but they cannot cover every width or device. If a breakpoint is near either value, inspect the breakpoint and test around it as well.