Kavra LabWhat a headless browser is
A normal browser draws every page on your screen and waits for you to move the mouse or type. A headless browser does the same work in memory: it downloads the page, runs its scripts, builds the layout and keeps cookies, but it never shows anything. Instead of a person, a program tells it what to do: open this address, fill in this field, press this button, save what comes back.
Most headless browsers today are ordinary browsers started in a special mode. Chrome and Firefox both have one. Automation frameworks such as Playwright, Puppeteer and Selenium start the browser, send it commands and read the results. The same frameworks can also drive a visible window, which some bots do on purpose to look less automated.
How a headless browser session works
- 01
Launch
A script starts the browser in headless mode, often on a server or in a container, and can run dozens of copies side by side.
- 02
Navigate
The script opens a page. The browser runs the site's JavaScript exactly as it would for a visitor, which is why simple HTTP scrapers are being replaced by it.
- 03
Act
The script types, clicks and scrolls through the automation framework. Actions are instant unless the author adds fake delays.
- 04
Collect
The script reads the page content, takes screenshots or captures network responses, then moves to the next page or account.
Legitimate and abusive uses
The tool is neutral. What matters is who runs it and what it does on your site.
| Use | Who runs it | Typical effect on your site |
|---|---|---|
| Automated testing | Your own QA team | Expected traffic from known networks |
| Page previews and monitoring | Link unfurlers, uptime services | Light, usually declared |
| Web scraping | Competitors, data resellers | Prices and content copied at scale |
| Credential stuffing | Account takeover crews | Mass login attempts that run your real login page |
| Signup and bonus automation | Multi-account operators | Fake accounts that pass front-end checks |
| Checkout bots | Scalpers | Limited stock bought in seconds |
Why headless traffic is hard to spot
Early headless browsers were easy to catch: they announced themselves in the user agent, had no plugins and reported odd screen sizes. Modern headless Chrome shares almost all of its code with the regular browser, and stealth plugins patch the remaining giveaways, such as the flag that tells a page it is under automation. Add a residential proxy and each session looks like a home user in the right city.
What stealth tools cannot easily fix is consistency. A headless browser running on a server has no real screen, no real graphics card behind it and no human hand on the mouse. Patches hide one symptom at a time, and they often contradict each other or the network the traffic comes from.
How to detect a headless browser
Look for contradictions between layers rather than a single flag: a browser that claims a laptop but renders like a server, a device whose reported values change between two reads, input with no natural movement, or a connection that does not match the browser it claims to be. Kavra checks these layers on every visit, including the real connection seen by its own edge network, and returns a plain-language verdict your backend can act on. See headless browser and automation detection for the full list of signals.