This created a confusing situation where any automated browser test might pass in headful mode but fail in Headless mode, or vice versa - a major pain point for automation engineers. Because Headless was a separate implementation, it had its own bugs and features that weren’t present in headful Chrome. It doesn’t share any of the Chrome browser code in //chrome.Īs you might imagine, implementing and maintaining this separate Headless browser came with a lot of engineering overhead - but that wasn’t the only problem. Technically, the old Headless was a separate, alternate browser implementation that happened to be shipped as part of the same Chrome binary. Perhaps surprisingly, this wasn’t actually true. The command-line snippet we showed earlier uses the -headless command-line flag, suggesting that Headless is just a mode of operation of the regular Chrome browser. Here’s a minimal command-line example of using Headless mode to create a PDF file of a given URL: chrome -headless -print-to-pdf # What’s new in Headless?īefore we dive into the recent Headless improvements, it’s important to understand how the “old” Headless worked. Headless mode is a popular choice for browser automation through projects like Puppeteer or ChromeDriver. Essentially, running Chrome without chrome! # Backgroundīack in 2017, Chrome 59 introduced the so-called Headless mode, which lets you run the browser in an unattended environment without any visible UI. Chrome’s Headless mode just got a whole lot better! This article presents an overview of recent engineering efforts to make Headless more useful for developers by bringing Headless closer to Chrome’s regular “headful” mode.

Free download puppeteer headless