How to Test a Website’s Tablet Layout with Automated Screenshots
Catch tablet layout regressions with Playwright screenshot tests. Choose stable viewports, compare reviewed baselines, and troubleshoot noisy diffs.
Use Playwright Test to render a page at a defined tablet viewport and compare its screenshot with a reviewed reference image. Choose a named device preset when you want its emulated device settings, or set the viewport dimensions directly when you want to test a particular responsive breakpoint. Keep the browser and operating system consistent with the environment that created the baseline so unrelated rendering differences do not swamp real layout changes.
1. Choose what “tablet” means for your test
A tablet test needs a browser context with explicit dimensions and, optionally, other device emulation settings. A label in a test name does not change the viewport by itself.
Use a registered device preset when you want a convenient bundle of device parameters. The available names can change between Playwright versions, so confirm the exact name in the registry installed in your project. You can also override a preset’s viewport. If your goal is to check a CSS breakpoint, explicit dimensions make the test’s intent clear and avoid coupling it to a device label. Playwright documents device emulation and viewport overrides in its emulation guide.
| Choice | Useful when | What to record |
|---|---|---|
| Named device preset | You want a device-like emulation configuration. | Preset name and Playwright version. |
| Explicit viewport | You want to test a specific responsive breakpoint or product target. | Viewport width and height, plus browser project. |
For a responsive site, consider testing the narrow and wide edges of the tablet range your product supports. Include a case just below or above an important CSS breakpoint if that transition is where regressions are likely. The relevant dimensions depend on your design; there is no single viewport that covers every tablet layout.
2. Install and configure Playwright Test
In an existing Node.js project, install Playwright Test and its browser binaries using the official installation instructions. Then create a test file such as tests/tablet-layout.spec.ts. The example below uses the device registry pattern; confirm that iPad (gen 7) exists in the version you install.
import { test, expect, devices } from '@playwright/test';
test.use({ ...devices['iPad (gen 7)'] });
test('tablet landing page has the expected layout', async ({ page }) => {
await page.goto('/');
await expect(page).toHaveScreenshot('tablet-landing.png');
});If your test runner does not already define a base URL, use an absolute URL in page.goto(), such as await page.goto('http://127.0.0.1:3000/'). A project-level baseURL lets you keep route paths short and makes the target environment configurable.
For breakpoint coverage, set a deliberate viewport directly:
import { test, expect } from '@playwright/test';
test.use({
viewport: { width: 1024, height: 768 },
});
test('landing page fits the tablet breakpoint', async ({ page }) => {
await page.goto('/');
await expect(page).toHaveScreenshot('landing-1024x768.png');
});The dimensions above are an example target, not a universal tablet standard. Pick dimensions that match your supported layout and write them into the test name or snapshot name so failures are easy to identify.
3. Create and review the baseline
- Run the test once in the chosen browser project. Playwright creates a reference screenshot when no baseline exists.
- Open the generated expected image and confirm it shows the intended layout and state. Commit the baseline with the test.
- Run the same test later. Playwright captures the page and compares it with the reference. Inspect the diff whenever it changes.
- Update a baseline only after deciding that the visual change is intentional. A newly generated image is not automatically the correct expected result.
Follow Playwright’s snapshot workflow for the update command appropriate to your project and runner. Snapshot output can be affected by the browser project and host environment, so keep those consistent between baseline creation and comparison whenever practical.
4. Make the captured page deterministic
Visual assertions are most useful when the page reaches the same state on every run. Use predictable test data, wait for meaningful content, and avoid capturing during animation or while volatile content is changing. The screenshot assertion waits for two consecutive screenshots to match before it compares the final capture with the stored expectation; this helps with settling, but does not make inherently changing content deterministic. See the PageAssertions API.
- Use a stable test account, fixture, or seeded dataset.
- Wait for a page-specific landmark, such as a heading or loaded component, instead of relying only on an arbitrary long delay.
- Disable or finish animations where appropriate. If you use screenshot assertion options such as animation handling or a mask, keep them narrow and intentional.
- For timestamps, rotating content, or other known volatility, use a test-specific stylesheet to hide or stabilize only those elements. Playwright’s visual comparison guidance describes applying a stylesheet for dynamic content.
- Do not mask broad areas such as the main content column or navigation: those may be exactly where a tablet layout regression appears.
5. Choose the screenshot scope
Use the smallest image that proves the behavior you care about. A viewport screenshot is usually easier to diagnose when the test concerns the visible tablet composition. A full-page screenshot helps when the entire document’s responsive layout matters, including content below the fold. A component-level screenshot can keep diffs local when the page contains unrelated areas.
toHaveScreenshot() supports screenshot comparison options, including full-page capture. For example:
await expect(page).toHaveScreenshot('tablet-full-page.png', {
fullPage: true,
});Check the assertion API for the options available in your installed version. Keep the scope consistent between baseline and later runs; changing from viewport to full page changes the image being compared.
6. Run the test in a stable browser environment
Keep the browser project and rendering environment stable across baseline creation and future runs. Playwright notes that browser rendering can vary with the host OS, browser version, settings, hardware, power source, and headless mode. A baseline made on one environment may therefore produce noisy diffs in another. See the official visual comparisons documentation.
For CI, use the same browser version and operating system for baseline updates and normal screenshot runs where practical. If developers update snapshots locally on different platforms, agree on a canonical environment and have changes reviewed there. Browser upgrades can change rendering; treat a bulk snapshot change after an upgrade as a review task rather than blindly accepting every new image.
7. Add more tablet targets without losing clarity
When one viewport is insufficient, create separate tests or Playwright projects for the sizes and browser engines that matter. Give each case an informative name and keep the dimensions visible in configuration. For example, a project matrix can represent a narrow tablet and a wide tablet; the exact values should come from your supported design targets.
When comparing environments, keep these axes explicit:
| Axis | Record | Why it matters |
|---|---|---|
| Viewport or preset | Width, height, and device preset if used | Changes responsive breakpoints and page composition. |
| Browser | Engine, project, and version | Rendering and layout behavior can differ. |
| Host environment | Operating system and relevant rendering setup | Can introduce screenshot variation unrelated to a code change. |
| Capture scope | Component, viewport, or full page | Controls which regressions the assertion can detect. |
8. Troubleshoot screenshot failures
| Symptom | Likely cause | Fix |
|---|---|---|
| Many pixels differ after a browser or machine change | The baseline and current capture use different rendering environments. | Run both in the same browser project and host setup where practical; review any intentional environment-wide baseline update. |
| The screenshot changes on each run | Dynamic data, animation, delayed content, or rotating elements. | Use stable fixtures, wait for a meaningful ready condition, and narrowly stabilize known volatile elements. |
| The page looks like desktop in a test called “tablet” | No tablet viewport or device context was applied, or project configuration overrode it. | Set an explicit viewport or verify the device preset and effective project configuration. |
| Snapshot differs in height or includes unexpected content | Capture scope changed, or the test now uses full-page capture. | Keep viewport/full-page settings consistent and inspect the assertion options. |
| Test times out at navigation | The route is unavailable, the base URL is wrong, or the page never reaches the requested load condition. | Check the app server and target URL, then wait for a page-specific readiness signal rather than requiring unnecessary network quiet. |
| Baseline update replaces numerous images | A design change, browser change, or broad capture difference affected many snapshots. | Review the image diffs by route and viewport; accept only the changes that match the intended behavior. |
| Preset lookup is undefined | The preset name is not present in the installed Playwright version. | Inspect that version’s device registry or use an explicit viewport. |
9. Performance, reliability, and cost
Screenshot tests consume browser time and produce image artifacts, so run a focused set of tablet targets on every change and reserve broader browser/viewport coverage for the schedule that fits your project. Keep each test’s setup small and avoid capturing the same large page repeatedly when one focused assertion answers the question.
Reliability comes mainly from stable state and environment: deterministic test data, a clear readiness condition, a consistent browser and host, and careful review of diffs. The screenshot assertion’s settling behavior is useful, but it cannot remove variability caused by changing page content or different rendering stacks.
There is no special per-screenshot service cost in the Playwright workflow described here; the operational costs are the compute and maintenance involved in running browser tests and storing/reviewing snapshots. If you instead need screenshots of public pages without maintaining browser setup, ScreenshotNeo offers an API and MCP server; its pricing is listed below.
Or skip the browser setup
ScreenshotNeo can capture a URL with one GET request, returning an image or PDF. It can emulate tablet presets or a chosen viewport, and supports full-page capture. Use it when you need a screenshot artifact or capture workflow without installing and maintaining a browser in your own script; Playwright remains suited to assertions against version-controlled visual baselines.
Cookie and consent banners are accepted and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents.
curl -G "https://api.screenshotneo.com/v1/shot" \
-d access_key=YOUR_API_KEY \
--data-urlencode url=https://stripe.com \
-d viewport=ipad \
-o tablet.webpSee the ScreenshotNeo API documentation for authentication and supported parameters. One thousand screenshots a month are free with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan. Sign up for the free plan.
FAQ
Does a tablet screenshot test prove the page works on physical tablets?
No. Device emulation exercises a configured browser context. It is useful for repeatable responsive checks, but the result is not a claim that every physical device behaves identically.
Should every tablet test use a full-page screenshot?
No. Use full-page capture when below-the-fold layout is part of the requirement. A viewport or component capture usually makes a focused regression easier to inspect.
Can I accept every generated snapshot update in CI?
Snapshot changes need review. Confirm that a change reflects an intended design update before replacing the reference image.
