Chromium Screenshot vs Chrome Screenshot: Are the Results Different?

Short answer: not necessarily. Chrome is built on the Chromium open-source browser project, and both support the Chrome DevTools Protocol screenshot command. That shared foundation means a screenshot is not inherently different just because one browser is called Chrome and the other Chromium. It does not guarantee pixel-identical output across builds, operating systems, page states, or capture settings. The official sources cited here do not report a controlled, version-matched Chrome-versus-Chromium pixel comparison.

For a meaningful comparison, hold the page state, browser version, operating system, headless or headed mode, viewport, device scale factor, capture options, and image format constant. Then compare the decoded images. If you are investigating a mismatch, check those inputs before attributing it to the browser name.

Chrome for Developers describes Chrome as built on the Chromium open-source browser project. Chrome also includes additional features and services, such as proprietary media codecs, optional error reporting, Google Account features, automatic updates, and additional release-channel testing. Those product differences do not establish that ordinary webpage screenshots differ.

The Chrome DevTools Protocol (CDP) instruments Chromium, Chrome, and other Blink-based browsers. Its Page.captureScreenshot command provides a common automation route for capturing a rendered page. A shared protocol helps make the comparison possible, but does not prove every browser build renders every page identically.

Sources: Chrome for Developers: Chrome and Chromium, Chrome DevTools Protocol, and the Page.captureScreenshot reference.

2. Why screenshots can differ

A screenshot captures a particular rendered state in a particular environment. Differences in any of these inputs can complicate a browser-to-browser comparison:

Input	What to hold constant or record
Browser build	Product name, exact version, and Chromium distribution. A Chromium package may include distribution-specific modifications.
Operating system and rendering environment	OS version and relevant font, color, and graphics environment details where known.
Page state	Same URL, content, cookies, authentication, storage, network responses, animation state, and timing.
Viewport and scale	Viewport width and height, plus device scale factor.
Browser mode	Headless or headed mode, and any relevant launch configuration.
Capture settings	Format, quality, clip, surface source, and whether capture extends beyond the viewport.

The protocol reference documents capture settings that affect what is requested: PNG is the default format, fromSurface defaults to true, and captureBeyondViewport defaults to false. The command also supports clipping; JPEG and WebP formats are available, and JPEG accepts a quality setting. A comparison that changes any of these is not isolating the browser build.

Full-page behavior has explicit conditions in Chromium’s implementation: the full-page-size path is used when capture is from the surface, beyond-viewport capture is enabled, and no clip is supplied. Different settings may take a different path. Chromium browser tests also exercise device-scale-factor overrides, clipping, transparency, and platform-specific behavior. This makes environment control useful; it does not show that a particular setting always causes a Chrome-versus-Chromium difference.

For distribution details, consult the Chromium project’s Linux-specific comparison. Its packaging notes are about Linux and should not be generalized to every platform or Chromium build.

3. Run a controlled comparison

Use the same test page and capture procedure in both browsers. Record the browser product and version alongside each image. The example below uses Playwright’s Chromium browser type, which can launch a supplied Chromium-based executable such as Chrome. Install Playwright and its browser dependencies according to the official Playwright setup guide, then set BROWSER_BIN to the executable you want to capture with. Run the script once per browser and use different output filenames.

import { chromium } from 'playwright';

const executablePath = process.env.BROWSER_BIN;
if (!executablePath) {
  throw new Error('Set BROWSER_BIN to the browser executable path');
}

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

const context = await browser.newContext({
  viewport: { width: 1365, height: 900 },
  deviceScaleFactor: 1,
  colorScheme: 'light',
});

const page = await context.newPage();
await page.goto('https://example.com', {
  waitUntil: 'networkidle',
  timeout: 60000,
});

// Keep the page still before capture where animations affect the result.
await page.addStyleTag({ content: `
  *, *::before, *::after {
    animation: none !important;
    transition: none !important;
    caret-color: transparent !important;
  }
` });

await page.screenshot({
  path: process.env.OUTPUT ?? 'capture.png',
  type: 'png',
  fullPage: false,
});

console.log(await browser.version());
await browser.close();

Example runs:

BROWSER_BIN=/path/to/chromium OUTPUT=chromium.png node capture.mjs
BROWSER_BIN=/path/to/chrome OUTPUT=chrome.png node capture.mjs

Executable paths vary by operating system and installation method. Use the exact binaries under comparison; a Playwright-managed browser download is not automatically the same build as the system Chrome or Chromium installation. If you need to compare headed mode, set headless: false for both runs and keep the rest fixed.

Compare the images

First compare dimensions and image metadata. Decode both images to pixels before computing a difference so the comparison is not confounded by file encoding. For a simple visual inspection, open them side by side or create an overlay. A pixel diff can identify changed pixels, but antialiasing and small rendering variations may produce differences that are not meaningful to your application. Define an acceptable threshold based on the purpose of the test; do not interpret any nonzero difference as proof that one browser is wrong.

Keep the page state reproducible

Use a stable test URL and consistent test data.
Set cookies, local storage, authentication, and permissions identically.
Wait for the same readiness condition. Network idle can be unsuitable for pages with persistent requests; a specific selector or application-ready signal can be more reliable.
Disable or freeze animations, clocks, and rotating content when they are not part of the test.
Use the same fonts and ensure they have loaded before capture.
Record the command options and retain the exact browser versions with the images.

4. Capture settings to match

CDP’s screenshot command accepts several parameters. For a fair comparison, explicitly match settings rather than relying on defaults that may change between automation wrappers or code paths.

Setting	Comparison guidance
`format`	Use the same format. PNG is the protocol default; JPEG and WebP are also available.
`quality`	Relevant to lossy formats such as JPEG. Match it exactly or use PNG for a lossless capture comparison.
`clip`	Match the same rectangle, or omit it in both runs.
`fromSurface`	Match this option; its protocol default is `true`.
`captureBeyondViewport`	Match this option; its protocol default is `false`. Full-page capture behavior depends on this and other conditions.
Viewport and device scale factor	Set these in the browser context or emulation configuration and verify output dimensions.

The exact automation API varies. If using CDP directly, consult the protocol version relevant to your browser rather than assuming a moving protocol reference precisely describes an older installed build. The CDP project publishes its protocol definitions and references at chromedevtools.github.io/devtools-protocol.

5. Troubleshooting mismatches

Symptom	Likely check	Fix
Images have different dimensions	Viewport, device scale factor, full-page mode, or clip differs.	Set the same viewport and scale factor; match clip and beyond-viewport settings; inspect the resulting dimensions.
Text wraps differently	Fonts, viewport width, font loading, or page content may differ.	Use the same font environment, wait for fonts to load, and verify the page state and viewport.
Only dynamic regions differ	Animation, timestamps, ads, personalization, or delayed content.	Freeze or disable dynamic content where appropriate and wait for a consistent readiness condition.
Full-page output differs from viewport output	Capture settings may select different paths; lazy content may not have loaded.	Match surface and beyond-viewport settings, omit or match clipping, and ensure below-fold content is ready before capture.
Colors or edges differ slightly	Platform, color environment, graphics path, or image encoding may differ.	Compare lossless PNGs first, record OS and rendering environment, then decide whether tolerance is appropriate for the test.
Automation launches the wrong browser	The executable path or installed package may not be the intended build.	Pass the explicit executable path and log the browser version returned by the automation library.
Capture fails or times out	Browser startup, navigation, or page readiness may exceed the configured timeout.	Check the executable and launch dependencies, inspect navigation errors, and choose a readiness condition suited to the page.

These checks identify comparison inputs to investigate; they are not a universal explanation for a mismatch. The official documentation reviewed does not name one root cause that applies to all Chrome-versus-Chromium screenshot differences.

6. Performance, reliability, and cost

Running both browsers adds a second launch and capture to the comparison, so browser startup and page loading can dominate the work. Reuse a browser process for multiple pages when appropriate, while creating isolated contexts when each run needs separate cookies or storage. Keep the target page and readiness condition stable; a fast but inconsistent capture is not a useful comparison.

For reliable visual checks, pin browser versions and the operating system image in your automation environment, save the captured files and metadata together, and rerun only after recording any environment change. A page with dynamic content may need deterministic test data or a controlled test environment.

Local browser automation has no per-screenshot service charge, but it uses compute, storage, and maintenance time. Hosted capture can reduce browser setup and operational work, with usage cost depending on the service and plan. Do not infer pixel parity from either approach: both still depend on the browser build, page state, and capture settings.

7. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF; its capture flow accepts cookie and consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets before capture. Each of those steps can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status.

Example request using cURL, with the same target URL as the browser example:

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

See the ScreenshotNeo API documentation for request options. Python and Node.js examples are available there as well. An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

Create a free ScreenshotNeo account to get 1,000 screenshots a month with no card.

8. FAQ

Does Chrome use Chromium?

Chrome is built on the Chromium open-source browser project, with additional Google features and services.

Does using the same CDP command guarantee identical screenshots?

No. It gives both browsers a shared screenshot interface, but does not guarantee identical rendering across different builds, environments, page states, or settings.

What is the first thing to check when two screenshots differ?

Compare dimensions, viewport and device scale factor, capture mode and clip, output format, page state, and exact browser versions.

Is Chromium always an open-source build with the same configuration?

No. Build and packaging details can vary by distribution. The Chromium project’s comparison page describes Linux specifically, so consult the documentation for the platform and build in question.

Sources

The sources establish product relationship, protocol support, and capture options; they do not provide a controlled, version-matched pixel-parity result. Consult documentation and source matching the binaries under investigation.