How to Screenshot a Website at Google Pixel 7a Size with Playwright

Use Playwright’s built-in Pixel 7a device profile, navigate to the page, and call page.screenshot(). The profile currently uses a 412 × 839 CSS-pixel viewport, a 412 × 915 emulated screen, and a 2.625 device scale factor, with mobile behavior, touch input, and Chromium by default. These are emulation settings; they do not mean the page was captured on a physical Pixel 7a.

For responsive layout checks, use the profile’s CSS viewport. Do not set the Playwright viewport to Google’s 1080 × 2400 physical panel resolution: that is a different measurement. [Playwright device descriptors] [Playwright emulation guide] [Google Pixel 7a specifications]

1. Understand Pixel 7a viewport and resolution

“Pixel 7a resolution” can refer to the browser viewport used to lay out a page or the physical pixels in the phone display. For a website screenshot that checks responsive CSS, the relevant value is the Playwright profile’s 412 × 839 CSS pixels. The descriptor also reports a 412 × 915 screen and a device scale factor of 2.625.

Setting	Pixel 7a profile value	What it means
Viewport	412 × 839 CSS pixels	The browser layout area used for responsive page rendering.
Emulated screen	412 × 915	The screen dimensions in the device descriptor; distinct from the configured browser viewport.
Device scale factor	2.625	Maps CSS pixels to emulated device pixels for rendering.
Mobile and touch	Enabled	Enables the profile’s mobile behavior and touch input emulation.
Default browser	Chromium	The profile uses Chromium unless you choose another supported browser project.
Physical display specification	1080 × 2400 pixels	Google’s panel specification, not the CSS viewport to pass to Playwright.

The profile values can change with Playwright versions. If your installed version behaves differently, inspect that version’s device registry rather than assuming the current upstream descriptor matches it.

2. Install Playwright

The examples below use JavaScript and Playwright Test. In a new project, install the test package and its browser:

npm init -y
npm install --save-dev @playwright/test
npx playwright install chromium

If your project already has Playwright configured, you can use its existing package and browser installation. The direct Playwright library offers the same device profile through a browser context, shown below.

3. Configure a Pixel 7a Playwright project

Put a device profile in a Playwright Test project’s use settings. Tests in this project receive pages configured with that profile.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    {
      name: 'Pixel 7a',
      use: {
        ...devices['Pixel 7a'],
      },
    },
  ],
});

Then capture a viewport screenshot in a test:

// tests/pixel-7a.spec.ts
import { test } from '@playwright/test';

test('capture a website at Pixel 7a size', async ({ page }) => {
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  await page.screenshot({ path: 'pixel-7a.png' });
});

Run only this project with npx playwright test --project="Pixel 7a". The screenshot covers the emulated viewport. For long-page documentation or visual review, request a full-page screenshot explicitly.

4. Capture viewport or full page

Viewport screenshot

By default, page.screenshot() captures the visible viewport. This is usually the right choice when checking what fits on the simulated phone screen, including navigation, text wrapping, and above-the-fold layout.

await page.screenshot({ path: 'pixel-7a-viewport.png' });

Full-page screenshot

Use fullPage: true to capture the entire page beyond the viewport’s bottom edge:

await page.screenshot({
  path: 'pixel-7a-full-page.png',
  fullPage: true,
});

A full-page image is taller than the visible phone screen. The device viewport remains 412 × 839 CSS pixels; full-page mode does not create a taller emulated phone.

Choose an image format

Playwright screenshots are PNG by default. Choose a JPEG path and quality when a smaller lossy image is suitable:

await page.screenshot({
  path: 'pixel-7a.jpg',
  type: 'jpeg',
  quality: 85,
});

Use PNG for crisp text and visual comparisons where lossless output matters. JPEG quality is an integer from 0 to 100 and applies to JPEG output. Keep the file extension and type consistent.

5. Use a one-off browser context

If you are writing a script rather than a Playwright Test, create a context from the device descriptor. This example uses the Playwright library with Chromium and writes both viewport and full-page images.

// capture.mjs
import { chromium, devices } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({ ...devices['Pixel 7a'] });
const page = await context.newPage();

try {
  await page.goto('https://example.com', { waitUntil: 'networkidle' });
  await page.screenshot({ path: 'pixel-7a.png' });
  await page.screenshot({ path: 'pixel-7a-full.png', fullPage: true });
} finally {
  await context.close();
  await browser.close();
}

Install the library and Chromium if needed with npm install playwright and npx playwright install chromium. The test-runner fixture manages the page and browser lifecycle for you; a standalone script must close the context and browser itself.

6. Override device settings when needed

The built-in descriptor is a convenient, repeatable baseline. You can override individual context options for a specific test. For example, keep the Pixel 7a profile’s mobile and touch settings while choosing a custom viewport:

const context = await browser.newContext({
  ...devices['Pixel 7a'],
  viewport: { width: 390, height: 844 },
});

Use such an override when reproducing a particular CSS breakpoint or comparing nearby widths. Record the override with the screenshot so another run can reproduce it. If you need a different scale factor or screen setting, set the corresponding context option deliberately; changing the viewport alone does not change the physical display specification.

For a test project, add the same override alongside the profile:

use: {
  ...devices['Pixel 7a'],
  viewport: { width: 390, height: 844 },
}

Use a browser project that matches the browser engine you intend to exercise. A device descriptor describes emulated parameters; it does not establish pixel-for-pixel equivalence with a handset’s hardware, browser build, fonts, or operating system.

7. Make captures repeatable

1. Wait for the page state you need. Network idle can help with ordinary static pages, but analytics, polling, or long-lived requests may prevent it. Prefer waiting for a meaningful selector when the page has a known ready element.
2. Wait for images and fonts where they matter. A screenshot taken before content finishes loading may contain blank image areas or fallback fonts. Wait for page-specific readiness, then capture.
3. Control animation for visual snapshots. Animations, carousels, and blinking cursors can make successive images differ. Use the screenshot API’s supported animation handling or disable motion in your application for a stable comparison.
4. Keep profile and browser version consistent. Pin Playwright in the project lockfile and install the corresponding browser revision in CI.
5. Save useful metadata with artifacts. Record the URL, commit, browser project, and any viewport overrides so image differences can be traced.

8. Troubleshoot common capture problems

Symptom	Likely cause	Fix
devices['Pixel 7a'] is undefined	The installed Playwright version predates the descriptor, or the import comes from an unexpected package.	Update the Playwright package and browser together; inspect the installed device registry. Confirm the import is from @playwright/test for tests or playwright for a standalone script.
Screenshot dimensions do not look like 1080 × 2400	The profile’s viewport is in CSS pixels; Google’s 1080 × 2400 figure is the physical panel specification.	Use the descriptor values for responsive layout tests. Do not substitute physical panel dimensions for viewport dimensions.
Image is unexpectedly very tall	fullPage: true captures page content beyond the viewport.	Remove fullPage or set it to false for a screen-sized viewport image.
Navigation or screenshot times out	The site may keep network connections open, respond slowly, or wait on third-party resources.	Use a readiness condition that fits the page, such as waiting for a stable selector. Set an appropriate navigation timeout if necessary; avoid waiting for network idle on pages that never become idle.
Images or fonts are missing	The capture happened before those assets loaded, or the site blocked the browser request.	Wait for the relevant image or font readiness and check browser console/network errors. In CI, verify the environment can reach the asset hosts.
Screenshot differs across runs or machines	Browser revision, fonts, operating system, dynamic content, time, or animation differs.	Keep Playwright and browser versions pinned, use the same CI image, stabilize test data and time-dependent content, and disable animation for visual comparisons.
Works locally but fails in CI	The browser may be missing, libraries may be absent, or the job may lack memory for a long page.	Install Playwright’s browser dependencies in the CI image, check browser launch logs, and capture only the needed region if a full-page image exhausts resources.

9. Performance, reliability, and cost

A screenshot requires launching or reusing a browser, loading the page and its assets, and rasterizing the requested area. Reuse a browser across multiple captures, create a fresh context per independent emulation profile, and close contexts when finished. This reduces repeated startup work while keeping page state isolated.

Full-page images can be much larger and more memory-intensive than viewport captures, especially for long pages or high device scale factors. Capture the viewport when that answers the question; use full-page mode when you need the whole document. In parallel jobs, limit concurrency to the resources available to the machine.

Playwright itself has no per-screenshot API charge, but browser execution consumes the compute and storage resources of the machine or CI service running it. A local run depends on local browser installation and connectivity; a CI run also depends on its image, network access, and artifact retention. Emulation makes repeated viewport checks practical, but a real handset remains the appropriate validation when device hardware or actual mobile browser behavior is part of the requirement.

10. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. For a general website capture, make one request; see the API documentation for parameters. This call captures the target site as an image:

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

The API has device presets and custom viewports, but this call alone does not claim to reproduce Playwright’s Pixel 7a descriptor. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its 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 shots.

Sign up free for 1,000 screenshots a month, with no card required.

11. FAQ

Does this capture a real Pixel 7a?

No. Playwright applies a device profile in browser emulation. Use a physical handset when you need to validate actual hardware or browser behavior.

Should I use 412 × 839 or 1080 × 2400?

Use 412 × 839 CSS pixels for the Playwright responsive viewport. The 1080 × 2400 value is the physical display specification.

Why is the emulated screen taller than the viewport?

The descriptor reports separate screen and viewport dimensions. Page layout uses the viewport; consult the descriptor and Playwright version when a test depends on the distinction.

Can I use the profile with Firefox or WebKit?

The descriptor’s default browser type is Chromium. Playwright supports projects for different browser engines, but test the resulting emulation behavior for your selected engine rather than assuming identical output.

Does full-page mode show the phone’s entire physical display?

No. It captures the web document beyond the viewport. It does not represent the handset’s panel dimensions or a physical device screenshot.