Examples
A headful browser is usually the thing you reach for when a target works fine in your laptop browser but starts breaking once you automate it headless.
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=False)
page = browser.new_page()
page.goto("https://example.com", wait_until="networkidle")
print(page.title())
browser.close()
You also use headful mode a lot for debugging:
python scrape.py
# opens a visible browser so you can see redirects, login flows, cookie banners, and bot checks
Practical tips
- Use headful mode first when debugging: redirects, CAPTCHA walls, cookie prompts, broken clicks, lazy-loaded content.
- Don't assume headful automatically means undetectable: plenty of anti-bot systems still catch bad fingerprints, weird timing, noisy IPs, or obvious automation patterns.
- Expect higher cost: more CPU, more memory, more startup overhead, and usually lower density per machine.
- In production, headful is often a fallback, not the default: headless is cheaper when it works, headful is useful when a site gets picky.
- If you're routing scraping jobs across providers, this is exactly the kind of thing you don't want hardcoded into one brittle setup: some targets need cheap headless, some need a headful browser, some need a different anti-bot stack entirely.
- With ScrapeRouter, this kind of browser-mode decision can sit behind one API instead of turning into custom routing logic in your app.
Use cases
- Debugging flaky scrapers: you want to actually see what the page is doing instead of guessing from logs and screenshots.
- Sites that behave differently in headless mode: some flows render, redirect, or challenge differently once they detect automation.
- Login and consent flows: SSO popups, cookie banners, MFA prompts, and other UI-heavy steps are easier to inspect in a visible browser.
- Bot-sensitive targets: not because headful is magic, but because sometimes a real desktop browser environment behaves closer to what the site expects.
- QA before production rollout: verify selectors, waits, pagination, and interaction steps in a visible session before trying to optimize for scale.