How to Compare Full-Page Screenshots in Applitools Eyes

To compare a full page in Applitools Eyes with Playwright, call eyes.check() with fully: true. A minimal checkpoint also sets a match level, such as Strict:

import { test } from '@applitools/eyes-playwright/fixture';

test('Compare the full homepage', async ({ page, eyes }) => {
  await page.goto('https://example.com');

  await eyes.check('Homepage', {
    fully: true,
    matchLevel: 'Strict',
  });
});

This asks Eyes to capture the page beyond the visible viewport and compare that checkpoint against its baseline. The integration guide’s example uses the Playwright fixture import shown above. If your capture is incomplete or assembled incorrectly, first determine whether the issue is capture coverage, page loading, or comparison sensitivity; those are different problems and need different fixes.

1. Add a full-page checkpoint to a Playwright test

Use test from @applitools/eyes-playwright/fixture.
Navigate to the page you want to check.
Call eyes.check() with a descriptive checkpoint name and fully: true.
Choose a match level that fits what the test is intended to catch. The example uses Strict; it is not a required setting for every test.
Run the test in your existing Playwright and Eyes setup, then review whether the captured page covers the expected content and whether the reported differences are meaningful.

The code above is the complete checkpoint example from Applitools’ Playwright integration guide. Project setup and authentication depend on your existing Eyes and Playwright configuration; the available research does not establish a universal install command or credentials flow, so use the current setup instructions for your project.

2. Choose a full-page capture mode

Applitools provides CSS and scroll capture modes. CSS mode is the default and is recommended for pages with fixed-position elements, such as a fixed header or floating bar, because those elements can otherwise appear repeatedly in an assembled full-page image. Scroll mode uses standard JavaScript window scrolling. Applitools describes the setting as defining the method used for a full-page screen capture.

If the full-page result looks wrong, try the alternative capture mode and inspect the resulting image. Treat this as a diagnostic step: the better mode depends on the page’s layout and scrolling behavior. The documentation also notes floating regions and displacement handling as advanced options. Consider them when the page and test require them; they are not mandatory additions to every full-page checkpoint.

3. Separate capture problems from comparison problems

A screenshot can be complete and still produce an unexpected visual result because the comparison policy is too sensitive for dynamic content, or because it overlooks a difference important to the test. Check these questions in order:

Is the full page present? If not, investigate the scroll root, capture mode, and content loading.
Is the page stable before capture? If content appears while scrolling, allow that loading behavior to happen before the checkpoint.
Is the difference meaningful? Choose the match level for the purpose of the test. Use ignoreRegions for dynamic areas when those areas should not drive the comparison.

Match level controls how the checkpoint image is compared with its baseline. Ignored regions control which areas should not be part of that visual comparison. These settings affect comparison sensitivity; they do not make an incomplete capture cover missing content.

4. Troubleshoot full-page capture issues

Only the visible viewport appears

A nested scroll container can explain why a checkpoint shows only the viewport. Eyes normally attempts to scroll the body or document, but the page may keep its content inside a different scrollable element. Use browser developer tools to find the element whose scroll position changes as you move through the content. Configure the appropriate scroll root for a full-window capture or check the scrollable region fully, as appropriate for the page. Do not assume that body is the scroll root.

Content is missing from the bottom or middle

Scroll-triggered lazy loading can leave a capture short or incomplete, especially when the page grows as new content loads. Applitools’ support guidance recommends scrolling to the bottom and back up before taking the full-page screenshot so the page’s loading behavior has a chance to run:

await page.goto('https://example.com');

await page.evaluate(async () => {
  window.scrollTo(0, document.body.scrollHeight);
  await new Promise((resolve) => setTimeout(resolve, 500));
  window.scrollTo(0, 0);
});

await eyes.check('Homepage', {
  fully: true,
  matchLevel: 'Strict',
});

The delay in this illustrative preparation step is an example, not a guaranteed wait time. Adapt readiness checks to the application. Scrolling down and back up is documented troubleshooting guidance, not a guarantee that every site’s lazy-loading logic will be satisfied.

Fixed headers or floating bars repeat in the stitched image

Try CSS capture mode, which Applitools recommends for fixed-position items. If the result remains problematic, test scroll mode and inspect both captures. Also check whether the element is truly fixed or whether the page layout changes while scrolling.

The page looks right, but Eyes reports too many differences

This is more likely a comparison-policy issue than a full-page coverage issue. Review the chosen matchLevel and whether dynamic content belongs in an ignoreRegions area. Make the policy reflect what the test must detect; do not ignore a region if changes there should fail the visual check.

The result differs between capture modes

Capture mode changes how the full-page image is assembled. Compare the outputs around fixed elements, page boundaries, and regions that load during scrolling. Keep the mode whose capture represents the intended page state, and investigate whether a nested scroll root or delayed content is involved.

5. Reliability, runtime, and cost considerations

Full-page checks depend on the page state at capture time. Content that loads after navigation, content triggered by scrolling, and nested scrolling can affect coverage. For repeatable results, ensure the page is in the state the test is meant to verify before calling the checkpoint, and keep capture settings consistent across runs.

A full-page capture can involve more page content than a viewport capture, and preparing lazy-loaded pages may require additional scrolling and waiting. The provided sources do not give a runtime benchmark, cost estimate, or universal timeout recommendation, so measure these in your own test environment rather than relying on a general figure. If a comparison fails, inspect the captured image first: this helps distinguish incomplete capture from a real visual change or an overly sensitive comparison policy.

6. ScreenshotNeo as an alternative for standalone captures

Eyes is the subject of this guide: it captures a checkpoint and compares it with a baseline. If you need a standalone website screenshot rather than an Eyes baseline comparison, ScreenshotNeo is a website screenshot API and MCP server for developers. It can capture full pages and load lazy images. Its clean-shot flow accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers indicate the page verdict and whether the shot was billed. Its MCP server provides screenshot and PDF tools for AI agents.

Or skip the browser setup

Use this one-call request for a full-page screenshot; see the ScreenshotNeo API documentation for parameters and options. Save the response as an image file:

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

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. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Does `fully: true` compare the page with a baseline?

It requests a full-page checkpoint through eyes.check(). Eyes compares that checkpoint with its baseline; the setting itself specifies capture coverage.

Should I always use Strict match level?

No. The integration example uses Strict, but the appropriate comparison sensitivity depends on what changes the test should detect.

Can ScreenshotNeo replace an Applitools Eyes visual test?

ScreenshotNeo returns screenshots and PDFs through an API or MCP server. The supplied product facts do not describe baseline comparison, so use Eyes when your task is to compare a checkpoint with an Eyes baseline.

Sources

Applitools Eyes Playwright integration guide — full-page checkpoint example, match level, ignored regions, and advanced comparison options.
Applitools Eyes Visual AI settings: capture mode — CSS and scroll modes and guidance for fixed-position elements.
Applitools support: determining the scrollable element — nested scroll roots and full-page capture.
Applitools support: missing content due to lazy loading — scrolling down and back up before capture.