Current Version of Puppeteer

As of September 23, 2026, the current Puppeteer release listed in the official changelog is 25.12.0. The official compatibility table pairs Puppeteer 25.12.0 with Chrome for Testing 154.0.8037.57 and Firefox 156.0.1. Check the changelog and browser table immediately before publishing or upgrading because these versions change frequently.

Use the package version, not a globally installed browser version, as your starting point. Puppeteer normally downloads a compatible browser for you. If you configure your own browser or use puppeteer-core, verify the pairing in the official supported-browser table.

What is the current Puppeteer version?

The official Puppeteer changelog currently lists:

Item	Current documented value
Puppeteer	25.12.0
Release date shown in changelog	September 23, 2026
Chrome for Testing pairing	154.0.8037.57
Firefox pairing	156.0.1
Previous changelog entry	25.11.0, September 13, 2026

The changelog is the source for the package release. The compatibility table is the source to use when selecting a browser build. Do not assume that any arbitrary Chrome or Firefox build is supported.

How to check the version you have installed

From a project directory

npm list puppeteer puppeteer-core
npx puppeteer --version

npm list reports the dependency resolved in your project. The CLI command reports the Puppeteer package version available through npx. If your project uses a lockfile, inspect that lockfile as well: the declared range in package.json and the resolved version can differ.

From JavaScript

const puppeteer = require('puppeteer');

console.log('Puppeteer version:', puppeteer.LATEST_VERSION || 'see package metadata');

For an unambiguous value in automation or CI, read the installed package metadata:

const packageJson = require('puppeteer/package.json');
console.log(packageJson.version);

With ECMAScript modules:

import packageJson from 'puppeteer/package.json' with { type: 'json' };
console.log(packageJson.version);

With npm metadata

npm view puppeteer version
npm view puppeteer versions --json

The first command asks the npm registry for its current package version. It is useful for checking whether a newer release exists than the one in your lockfile.

Using cURL

curl -s https://registry.npmjs.org/puppeteer/latest

The response contains the registry’s latest package metadata, including version. Treat registry data as a live lookup; it may change after this article is published.

Using Python

import json
import urllib.request

with urllib.request.urlopen("https://registry.npmjs.org/puppeteer/latest", timeout=20) as response:
    metadata = json.load(response)

print(metadata["version"])

Install Puppeteer 25.12.0

The normal package install downloads Puppeteer and its compatible browser. The official getting-started guide covers launching or connecting to a browser, creating pages, and using the API.

mkdir puppeteer-version-check
cd puppeteer-version-check
npm init -y
npm install puppeteer@25.12.0

Pin the exact version when reproducibility matters. Use a lockfile and commit it:

npm install --save-exact puppeteer@25.12.0

Complete runnable screenshot example

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  try {
    const page = await browser.newPage();
    await page.goto('https://example.com', { waitUntil: 'networkidle2' });
    await page.screenshot({ path: 'example.png', fullPage: true });
    console.log('saved example.png');
  } finally {
    await browser.close();
  }
})();

Run it with node screenshot.js. The default download behavior is convenient for local development and CI systems that allow browser downloads.

Chrome and Firefox support

Puppeteer uses Chrome DevTools Protocol (CDP) by default for Chrome. For Firefox, Puppeteer uses WebDriver BiDi by default. The official FAQ describes BiDi support as production-ready for both browsers from Puppeteer 23 onward, while Chrome CDP remains supported.

Browser	Default protocol	25.12.0 pairing
Chrome for Testing	CDP	154.0.8037.57
Firefox	WebDriver BiDi	156.0.1

Puppeteer v20 and later downloads and works with Chrome for Testing. Stable Firefox support begins with v23. Use the table rather than inferring compatibility from a browser’s marketing version or from a system package that happens to be installed.

Upgrade safely

Read the changelog for the target release.
Check the browser compatibility table.
Update the dependency in a branch and regenerate the lockfile.
Run representative navigation, PDF, screenshot, download, authentication, and failure-path jobs.
Record the Puppeteer version and browser revision in CI logs.

npm install --save-exact puppeteer@25.12.0
npm list puppeteer
npx puppeteer browsers list

Do not copy a version pin from an old article without checking the current official instructions. Distinguish puppeteer, which manages a browser download by default, from puppeteer-core, which is intended for connecting to a browser you manage.

Browser download and configuration choices

The installation documentation supports selecting a browser or skipping browser downloads. These are the main deployment patterns:

Pattern	Use it when	Typical concern
`puppeteer` default	You want Puppeteer to obtain a compatible browser	CI needs network access during installation or a cached browser layer
Configured browser	Your image or host already manages Chrome or Firefox	You must keep the installed browser aligned with the support table
`puppeteer-core`	Your application supplies the browser executable or remote endpoint	Version mismatches become your responsibility
Skip downloads	Images are built offline or browsers are provisioned separately	Launch fails if the executable path or permissions are wrong

Browser-management commands and configuration options are documented in the official installation guide and configuration API. Keep configuration in source control so local, CI, and production launches use the same policy.

Common errors and fixes

“Could not find Chrome” or an executable-path error

Cause: Browser downloads were skipped, or the configured executable path does not exist.

Fix: Install the compatible browser through Puppeteer’s browser-management workflow, remove the skip-download setting, or provide the actual executable path. Confirm the browser version against the support table.

Browser revision mismatch

Cause: puppeteer-core or a manually installed browser is being used with a different Puppeteer release.

Fix: Align the browser with the documented pairing, or use the standard puppeteer package so the compatible browser is downloaded automatically.

Installation fails in CI

Cause: The build cannot reach the download host, lacks disk space, or runs under a user that cannot write the cache.

Fix: Cache the browser between builds, allow the required download during image creation, or provision the browser in the image and configure Puppeteer to use it. Log the resolved package and browser versions.

Firefox behaves differently from Chrome

Cause: Firefox uses WebDriver BiDi by default, while Chrome uses CDP. Some browser-specific behavior and protocol coverage differ.

Fix: Check the FAQ and support table, reproduce the issue in the target browser, and avoid assuming a Chrome-only CDP behavior applies to Firefox.

Cause: The page has long-running requests, bot checks, an unreachable dependency, or a wait condition that never resolves.

Fix: Set an explicit navigation timeout, choose an appropriate waitUntil condition, capture console and request failures, and test the target URL from the same network used by automation.

page.setDefaultNavigationTimeout(45_000);
page.on('requestfailed', request => {
  console.error('request failed:', request.url(), request.failure()?.errorText);
});
page.on('console', message => console.log('page:', message.text()));

Works locally but fails in a container

Cause: Missing sandbox permissions, shared libraries, fonts, writable temporary storage, or a different browser binary.

Fix: Compare the container’s executable, libraries, fonts, user identity, and environment with local development. Prefer a maintained base image and avoid adding launch flags blindly; each flag changes the security and compatibility profile.

Performance, reliability, and cost

Reuse a browser process: Launching one browser and creating separate pages is usually cheaper than launching a browser for every URL.
Control concurrency: Limit simultaneous pages to the CPU and memory available. Excessive parallelism causes crashes, throttling, and slower navigation.
Set bounded waits: Use navigation and operation timeouts, then close pages in finally blocks.
Cache browser binaries: A cached download makes CI faster and avoids repeated network dependency.
Pin versions: Exact package and browser pairings make failures reproducible. Recheck the official table before planned upgrades.
Measure the whole job: Track install time, browser launch time, navigation time, memory, failed requests, and output size.
Budget infrastructure: Puppeteer itself is a JavaScript dependency, but browser processes consume compute, memory, storage, and network bandwidth. Your hosting bill depends on workload and deployment, not only the npm package.

Or skip the browser setup

ScreenshotNeo provides a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Its capture flow accepts cookie and consent banners before the shot and removes more than 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 are not billed, and response headers identify the page verdict and billing status.

See the ScreenshotNeo API documentation for all options, including full-page capture, CSS-selector elements, dark mode, device presets, retina scale, PDF settings, custom CSS and JavaScript, clicks, waits, request blocking, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, TTL caching, signed links, asynchronous jobs, webhooks, bulk capture, usage reporting, and the OpenAPI specification.

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

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

An MCP server lets Claude, Cursor, and other MCP clients use take_screenshot, get_page_info, and capture_pdf. The Free plan includes 1,000 shots each month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Is Puppeteer 25.12.0 the newest version forever?

No. It is the version listed in the cited official changelog as of September 23, 2026. Recheck the changelog before publishing or upgrading.

Which Chrome version works with Puppeteer 25.12.0?

The official table pairs it with Chrome for Testing 154.0.8037.57.

Does Puppeteer support Firefox?

Yes. The official table pairs 25.12.0 with Firefox 156.0.1, using WebDriver BiDi by default.

Should I use Puppeteer or Puppeteer Core?

Use puppeteer when you want the package to manage a compatible browser. Use puppeteer-core when your application deliberately supplies the browser or connection.

Where should I verify future releases?

Use the official changelog for package releases and supported-browser table for browser pairings.