---
title: "Headless browser"
url: https://proxy.wiki/glossary/headless-browser/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Web scraping"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Headless browser

> A real browser engine driven programmatically with no visible window. Powerful, slow and expensive in bandwidth.

**A headless browser is a full browser engine controlled by code instead of a person.** Chrome, Firefox and WebKit all support this mode, driven through tools such as Playwright, Puppeteer or Selenium.

## When it earns its cost

- Content rendered by JavaScript after page load.

- Flows requiring genuine interaction — clicks, scrolling, form entry.

- Targets whose [anti-bot systems](/glossary/anti-bot-system/) require a real client-side environment.

## What it costs

| Cost | Compared with an HTTP client |
| --- | --- |
| Memory and CPU | Substantially higher per worker |
| Latency | Full page load rather than one request |
| [Bandwidth](/glossary/bandwidth-billing/) | Often 10 to 50 times more, since every asset is fetched |

## The optimisation people miss

Block images, fonts, media and analytics at the request-interception layer. On a per-gigabyte plan this frequently cuts the bill by most of its value while leaving the rendered content intact.

## Deciding whether you need one

A browser costs orders of magnitude more memory and time than an HTTP request. Establish that you need it before you pay for it.

| Situation | Browser needed? |
| --- | --- |
| The content is in the HTML you already receive | No |
| The page fetches its data from an API you can call directly | No, call the API |
| Rendering requires JavaScript execution | Yes |
| The site issues a JavaScript challenge | Yes |
| The flow needs real interaction | Yes |

The second row is the one people miss most often. Open the network panel and watch what the page requests. A single JSON endpoint frequently carries everything you are trying to extract from the rendered HTML.

## The default that gives it away

Automation frameworks announce themselves unless told not to. Default window sizes, missing plugin lists and automation flags exposed to page scripts are all readable by the site. A headless browser left at its defaults is easier to identify than a plain HTTP client, because it claims to be a browser and then fails the checks a browser passes.

Consistency matters as much here as in [fingerprinting](/glossary/browser-fingerprinting/) generally: the address country, the timezone and the language headers must agree.

## Frequently asked questions

### When should I use a headless browser instead of an HTTP client?

Only when the content genuinely requires JavaScript execution, or when the flow needs real interaction. Check the network panel first, because pages that appear to need rendering often fetch their data from an API you can call directly.

### Are headless browsers easy to detect?

At their defaults, yes. Automation frameworks expose flags and default values that page scripts can read. A configured browser is much quieter, but it will always cost more resources than a plain request.

### Does a headless browser hide my address?

No. It is a browser, not a proxy. Route it through a proxy if you need a different address, and make sure its timezone and language settings agree with the country you chose.

## Sources

1. [W3C WebDriver: the automation protocol browsers expose](https://www.w3.org/TR/webdriver2/)