Headless browser
A headless browser is a full web browser running without a visible window, driven by a script instead of a person. It loads pages, runs JavaScript, applies CSS and fires events exactly as the desktop version does, but renders to memory rather than to a screen, which makes it the standard engine for automated browser tests on servers that have no display.
The longer version
Headless mode is a flag on an ordinary browser engine, so the page under test sees the same parser, the same layout engine and the same JavaScript runtime it would see in a user's browser. An automation library opens the browser, navigates to a URL, waits for the page to settle, clicks and types through the same event system a real pointer uses, and reads the resulting DOM back. Screenshots are taken from the in-memory framebuffer, which is how visual comparison tests get an image from a machine with no monitor.
The nearest confusion is with an HTTP client or a scraper that fetches HTML and parses it. Those never execute JavaScript, so a page that renders on the client is empty to them. A headless browser executes everything, which is why it can test a single-page application at all. The other confusion is the reverse: assuming headless is identical to headed. It is the same engine, but window size, fonts, GPU acceleration and some media features differ by default, so a layout can pass headless and break on a user's screen.
The failures are environmental. A test passes locally in a headed window and fails in the pipeline because the headless default viewport is a different width and the layout breakpoint moved. Fonts installed on the developer's machine are missing on the build server, so text wraps differently and a screenshot comparison fails on every run. Bot detection on a third-party service recognises the headless browser and refuses it. None of these is a product bug, and each costs an afternoon before somebody spots it.
Headless browsers run the build verification and end-to-end suites in continuous integration, where no display exists, and they are the runtime behind lab measurement of page performance. They are not a substitute for the device axis of a test matrix: a headless run proves the page works in one engine at one configured size, and a real phone still has to be held.
Common questions
What is a headless browser used for?
A headless browser runs automated browser tests, screenshot comparisons and performance measurements on machines without a display, such as continuous integration servers. Because it executes JavaScript and applies CSS like a normal browser, it can exercise a single-page application end to end, which an HTTP client that only fetches HTML cannot.
Is a headless browser the same as a normal browser?
A headless browser is the same engine with no window. Parsing, layout, JavaScript and events behave identically, but defaults differ: the viewport size, available fonts, GPU use and some media features are not those of a user's machine, so a page that passes headless can still break on a real screen.
Why does a test pass in a headed browser and fail headless?
Usually the environment, not the code. The headless default viewport is a different width, so a responsive breakpoint changes; fonts on the build server differ from the developer's machine; or a timing assumption holds on a fast laptop and not on a loaded runner. Pinning the viewport and fonts in the test configuration removes most of these.
Can a headless browser take screenshots?
A headless browser renders the page to an off-screen buffer and can write that buffer to an image file on demand, which is how screenshot and visual regression tests get a picture from a server with no monitor. The image reflects the configured viewport and the fonts installed on that machine, so comparisons are only stable when both are pinned in the test setup.
Can a website detect a headless browser?
Websites and bot-protection services detect headless browsers through signals such as the user agent string, missing browser features and the absence of normal input timing, and some refuse to serve them. In testing, that shows up as a third-party page or payment sandbox that works in a headed browser and blocks the automated run; the fix is an allowlisted test account or a stubbed service, not a product change.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.