Reading the web without a desktop compositor

Lightpanda Browser’s output boundary asks a practical question: once a live DOM has been built and JavaScript has changed it, which representation should a person, crawler, or agent receive? The answer is not simply “render the page” or “dump the HTML.” Lightpanda omits a general desktop compositor, but it retains several targeted ways to expose page state. Choosing among them means deciding how much source fidelity, visible reading order, accessibility meaning, actionability, and visual resemblance the task actually needs.

Headless does not mean output-free

The project’s statement that Lightpanda has no graphical rendering engine is easy to misread. It does not mean that the browser can produce only an invisible DOM or that screenshots are impossible. It means that a full desktop graphics stack is not the default foundation of every page. The repository instead contains distinct paths for HTML serialization, Markdown conversion, semantic inspection, and a targeted renderer used for screenshot and PDF-oriented output.

That boundary follows the product’s workload. A crawler often needs text and links, not a faithful repaint of every pixel. An agent needs to know which controls are visible and what they mean. A debugging tool may need the source-like DOM, including attributes and frames. A screenshot can be useful as a bounded visual reference, but it should not silently become a promise of full browser visual fidelity.

The difference between a desktop compositor and a targeted renderer is a difference in what the system treats as primary. A desktop browser usually turns layout, painting, fonts, layers, and device surfaces into a general visual environment. Lightpanda’s output paths start with the live page state and derive the representation a consumer asks for. Some derivations preserve markup. Some follow the composed, visible tree. Some reduce the page to accessible controls. The output is therefore a view with a purpose, not a neutral mirror.

flowchart LR DOM["Live DOM + composed tree"] --> HTML["HTML serialization\nsource fidelity"] DOM --> MD["Markdown visible reading view\nreadability"] DOM --> SEM["Semantic / interactive tree\nactionability"] DOM --> R["Text-oriented renderer\nPNG / PDF output"] HTML --> F["structure and attributes"] MD --> V["visible content and links"] SEM --> A["roles, names, values, node IDs"] R --> B["bounded visual reference"]

The diagram’s arrows are transformations, not four independent browsers. Every view begins with page state, and every view can omit something that another consumer needs.

HTML is the fidelity-oriented view

HTML output is the closest of these paths to a source-like representation. Lightpanda can serialize a whole document or a selected subtree, include a base URL when relative links need to be interpreted later, include frame content when requested, and strip categories such as scripts, stylesheets, interface elements, invisible elements, or page shell. These controls let a caller choose between inspecting what the document contains and producing a cleaner body for downstream processing.

HTML is the right starting point when the structure itself matters.