What Is Xvfb? – Definition and How It Works
Learn what Xvfb is, how a virtual framebuffer runs GUI browsers headlessly, and when it beats a browser's built-in headless mode.
Xvfb — X virtual framebuffer — is an X11 display server that renders into memory instead of to a screen. It lets GUI applications, including full browsers, run on a machine with no display attached.
1. How It Works
Xvfb implements the X protocol and provides a display number that clients connect to, drawing into a memory buffer nothing ever shows.
Xvfb :99 -screen 0 1920x1080x24 &
export DISPLAY=:99
google-chrome --no-sandbox https://example.com
Chrome believes it has a 1920×1080 24-bit display. Nothing is visible, and everything works.
2. Why It Still Matters
Browsers ship a headless mode, so the obvious question is why a virtual display is needed at all.
| Reason | Detail |
|---|---|
| Headed mode differs | A browser in headless mode is detectably different from a headed one |
| Extension support | Some extension APIs behave differently or not at all headless |
| Screen APIs | screen.width, availHeight, and related values are real under Xvfb |
| Features gated on a display | Certain media and rendering paths require a display server |
| Legacy applications | Non-browser GUI tools have no headless mode at all |
Running a headed browser on a virtual display gives you headed behaviour on a server, which is the reason it persists in automation work.
3. The Convenience Wrapper
xvfb-run handles server startup, display allocation, and cleanup:
xvfb-run --server-args="-screen 0 1920x1080x24" python collect.py
Preferable to managing the server by hand, because it avoids the classic failure of a leftover :99 from a previous run and a lock file that blocks the next one.
4. Where It Fits in a Container
Xvfb in a container is the standard pattern for headed browser automation, and needs three things beyond the browser:
- Xvfb installed and started before the application.
DISPLAYexported to the application's environment.- Enough shared memory — the default
/dev/shmin many container runtimes is too small for Chrome and causes crashes that look like random tab failures.
5. Screen Geometry Is a Real Setting
The framebuffer geometry becomes the browser's screen size, and screen dimensions are a fingerprinting signal. A 1024x768x24 framebuffer produces a screen resolution that is unusual on modern devices.
Choose a common desktop geometry, and keep the browser window smaller than the screen, since a window exactly equal to the screen in every dimension is itself an unusual combination.
6. Alternatives
Browser headless mode — simplest when detection and extensions do not matter.
Xwayland or a nested compositor — for stacks that assume Wayland.
A managed browser service — no display server to operate at all, which is generally the right trade when the alternative is maintaining container images for browser dependencies.
7. Common Problems
Cannot open display— Xvfb not running, orDISPLAYnot exported into the right process.- Stale lock file — a crashed server leaves
/tmp/.X99-lock, blocking restart. - Crashes under load — undersized
/dev/shm. - Missing fonts — text renders as boxes, breaking screenshots and any text measurement.
- Zombie servers accumulating across runs and exhausting memory.
8. Summary
Xvfb is an X server that renders into memory, letting GUI applications and headed browsers run without a display.
It remains useful because a headed browser on a virtual display behaves differently from a headless one, supports extensions, and reports real screen metrics — with the operational cost of managing the server, sizing shared memory, installing fonts, and picking a plausible screen geometry.