How to Compare Desktop and Mobile Competitor Landing Page Screenshots

To compare desktop and mobile competitor landing page screenshots fairly, capture the same page purpose and equivalent page states at documented viewport sizes. Compare what is visible and where it appears, rather than expecting the two layouts to be pixel-identical. Record the URL, capture time, viewport dimensions, browser when known, page state, and whether each image shows the viewport or the full page. Treat conclusions about user behavior or conversion as hypotheses: screenshots show layout and visible content, not how people respond.

1. Define what you are comparing

Start with one competitor page and a specific question, such as whether the primary offer and call to action remain visible on mobile, or whether the page changes the order of proof points and form fields. A focused question makes the comparison useful and keeps incidental differences from taking over.

Compare equivalent page purposes: use the same landing page, or explain why two pages serve the same task.
Compare equivalent states: initial load against initial load, or a menu-open state against a menu-open state.
Record changes in destination or content: if mobile redirects or serves a different page, preserve that as an observation.
Choose your capture scope: a viewport screenshot answers what appears without scrolling; a full-page screenshot helps compare section order and page length.

Do not silently compare a desktop page with a consent banner to a mobile page after dismissing it. Page state is part of the evidence.

2. Capture reproducible desktop and mobile screenshots

Choose viewport dimensions that represent the comparison you want to make, and write down the exact width and height in CSS pixels. If you use device emulation, record the device scale factor too. A desktop viewport and a mobile viewport are supposed to produce different responsive layouts; the aim is to compare each layout at a known size and a known state.

Capture with Playwright

The following Node.js example opens the same URL at two explicit viewport sizes and saves viewport and full-page images. It creates a separate browser context for each size. Change the dimensions to suit your review, and change the page-state handling if the site requires a consent choice or another interaction.

import { chromium } from 'playwright';

const url = 'https://example.com/landing-page';
const captures = [
  { name: 'desktop', width: 1440, height: 900 },
  { name: 'mobile', width: 390, height: 844 },
];

const browser = await chromium.launch({ headless: true });

try {
  for (const capture of captures) {
    const context = await browser.newContext({
      viewport: { width: capture.width, height: capture.height },
      deviceScaleFactor: 1,
    });
    const page = await context.newPage();
    await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });

    // If needed, put the same consent or page-state action here for both captures.
    // Example: await page.getByRole('button', { name: 'Accept all' }).click();

    await page.screenshot({ path: `${capture.name}-viewport.png` });
    await page.screenshot({ path: `${capture.name}-full.png`, fullPage: true });
    await context.close();
  }
} finally {
  await browser.close();
}

Install the dependency with npm install playwright and install a browser with npx playwright install chromium. In a team or a visual regression workflow, keep the browser and operating system consistent with the screenshot baseline. Playwright notes that rendering can vary by host OS, browser version, settings, hardware, power source, and headless mode, and recommends using the same environment for consistent screenshots (Playwright screenshot testing documentation).

Choose page readiness deliberately

networkidle is convenient for pages whose requests settle, but analytics, ads, chat tools, and live content can keep network activity going. If navigation times out, wait for a meaningful element or a short, documented delay instead. For example:

await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 60000 });
await page.locator('main').waitFor({ state: 'visible', timeout: 15000 });
await page.waitForTimeout(1000); // Use only when the page needs a brief render delay.

Use the same readiness rule and state actions for both captures. Avoid masking or hiding content during an editorial comparison unless you label the altered state. For automated pixel comparisons, Playwright supports screenshot assertions, masks, animation handling, and stylesheets for dynamic page elements; these controls can stabilize a diff, but they do not determine whether a design difference matters.

3. Compare the first screen, then the page journey

Review the first viewport before scrolling. It contains the initial message and action a visitor encounters, and it is where responsive changes are often most consequential to the page’s presentation.

Comparison axis	What to inspect
Message hierarchy	Is the headline and core promise visible? Does the order of supporting claims change?
Offer and action	Is the same offer shown? Where is the primary call to action, how prominent is it, and does its label change?
Navigation	Does desktop navigation collapse into a menu or disappear? Is the relevant menu state captured?
Content order	Are benefits, imagery, social proof, pricing, or FAQs moved, omitted, or reordered?
Readability and fit	Do text blocks, images, cards, or buttons appear crowded, clipped, or broken at the captured width?
Form friction	Does the form move or simplify? How many fields and which labels and actions are visible?
Length and repetition	Does mobile require more scrolling? Is the call to action repeated at different points?

Then review full-page screenshots or a sequence of viewport captures. Compare section order, repeated calls to action, testimonials, pricing or offer details, forms, and footers. Label viewport and full-page images clearly: Playwright’s fullPage option captures the full scrollable page rather than only the current viewport (Playwright screenshot guide).

4. Separate evidence from interpretation

Write down what the screenshot visibly shows first. Add a possible consequence separately, mark it as a hypothesis, and state your confidence. This avoids presenting a design interpretation as a measured user outcome.

Observation	Possible implication (hypothesis)	Confidence
Mobile places the testimonial section below the lead form; desktop places it beside the form.	Mobile visitors encounter the form before that proof point.	High for placement; low for any effect on trust or submissions.
The mobile first viewport shows the headline but not the primary action.	A visitor may need to scroll before acting.	High for visibility at this viewport; behavior is unknown.

A screenshot cannot establish usability with real visitors, accessibility conformance, page performance, conversion impact, or preference. Treat apparent clipping and small text as prompts for further checks, not as a complete accessibility assessment.

5. Make pixel comparisons useful

For repeatable visual checks, Playwright Test can compare screenshots against stored reference images with toHaveScreenshot(). Its screenshot comparison waits for two consecutive screenshots to match before comparing. Keep the capture environment and page state stable, and mask only genuinely volatile elements such as timestamps or rotating content. A mask can make a diff easier to read, but document it so it does not conceal a meaningful change.

A pixel-difference result is a triage signal, not a design-quality score. A large difference may be intentional responsive behavior. A small difference may still hide a changed call-to-action label or a missing claim. Review the images and the underlying page in addition to any diff. BrowserStack documents a visual review flow organized by browser and viewport width, with side-by-side, overlay, and diff views (BrowserStack Percy review documentation).

Do not infer a precise responsive breakpoint from only one desktop and one mobile capture. If the breakpoint matters, capture additional widths around the point where the layout appears to change. Keep viewport height in mind too: changing height changes what is initially visible even at the same width.

6. Save a comparison record

Keep filenames and notes specific enough that another reviewer can reproduce the comparison. A compact record can include:

Competitor page URL and capture date/time.
Browser and version, operating system, and headless or headed mode when known.
Viewport width and height, device scale factor, and zoom when known.
Page state, including consent choice, open navigation, selected tab, or other interaction.
Capture scope: viewport, full page, or a sequence of viewport images.
Observation, hypothesis, and confidence in separate fields.

Competitor pages change. A screenshot is evidence of a page at a particular time, not proof that the design is permanent.

Or skip the browser setup

ScreenshotNeo takes a screenshot from one API request. The ScreenshotNeo API documentation covers the request options. For example, this cURL request captures a competitor landing page:

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

Python:

import requests

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

Node.js:

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/landing-page',
});
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('competitor.webp', new Uint8Array(await res.arrayBuffer()));

Use the same target URL and capture settings for each viewport you compare, and record those settings with the images. ScreenshotNeo accepts common screenshot API parameter names and provides viewport sizing, full-page capture, device presets, custom waits, and image formats. Cookie and consent banners are accepted like a visitor and removed along with 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 screenshots per month without a card; paid plans start at $5 for 3,000 screenshots.

Troubleshooting

Problem	Likely cause	What to do
Navigation times out at `networkidle`.	The page keeps making background requests, or a resource is slow.	Use `domcontentloaded`, then wait for a meaningful visible element and, only if needed, a short fixed delay. Apply the same rule to both captures.
The two images differ even though the page seems unchanged.	Browser or host rendering differences, dynamic content, fonts, animation, or inconsistent page state.	Use the same browser and environment, wait for fonts/content to settle, stabilize state, and mask only known volatile regions for a diff.
Mobile shows a different URL or page.	The site redirects or serves a device-specific destination.	Record the destination and compare the actual experience. Do not imply it is the same rendered page.
The screenshot has a consent dialog or a menu open in only one size.	State setup differed or a responsive state was missed.	Repeat with equivalent state actions, or label the distinct states as the subject of the comparison.
A full-page image is unexpectedly long or stitched with awkward sections.	The page contains lazy-loaded content or sticky elements that change during scrolling.	Scroll through the page before capture if content loads on scroll, or capture successive viewport images and compare sections by position.
A visual diff flags many pixels after a responsive change.	The layouts are intentionally different at the chosen widths.	Review structural and content changes manually; do not interpret raw changed-pixel area as quality or impact.

Performance, reliability, and cost

Two viewport captures require two page renders; full-page captures can take longer and produce larger files than viewport captures. Keep the browser open while capturing both sizes, reuse setup where appropriate, and avoid unnecessary retries. A fixed delay improves neither speed nor reliability unless the page actually needs it, so prefer waiting for a relevant element.

Repeatability depends on more than viewport width. Browser version, operating system, fonts, device scale factor, headless mode, dynamic page content, network timing, and page state can all affect output. Save capture metadata alongside images and repeat a capture before treating a surprising visual difference as meaningful.

Playwright is a practical do-it-yourself option when you can run a browser and manage the environment. ScreenshotNeo is a hosted API option when you want to request captures without setting up the browser workflow; plan limits and current prices are listed by the product, with the supplied plans ranging from 1,000 free monthly shots to paid tiers beginning at $5 for 3,000. Choose viewport-only captures for first-screen questions and reserve full-page captures for page-journey questions to limit needless rendering and file handling.

FAQ

Should the desktop and mobile screenshots show the same amount of content?

No. The initial viewport height and responsive layout affect how much is visible. Compare what each size presents before scrolling, then use full-page images when comparing the overall journey.

Can screenshots tell me which version converts better?

No. They show visible design and content. Conversion claims require behavioral or experiment data beyond screenshots.

How many viewport widths should I capture?

Use one documented desktop and one documented mobile width for a basic comparison. Add widths near a suspected layout transition when you need to understand breakpoint behavior.

Can a pixel diff decide whether a design is better?

No. It can identify visual changes for review, but people must judge whether those changes are intentional and relevant to the page’s purpose.