# litehtml: An HTML/CSS Layout Engine That Leaves Drawing to You

> litehtml parses HTML with gumbo-parser and positions elements with CSS2/CSS3 rules, but it never draws a pixel. Here is what that split means for embedding HTML text in a C++ application, and where the engine stops.

**litehtml/litehtml** — Fast and lightweight HTML/CSS rendering engine

- Repository: https://github.com/litehtml/litehtml
- Website: http://www.litehtml.com/
- Stars: 2,452 · Forks: 305
- Language: C++
- License: BSD-3-Clause
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/litehtml-litehtml

## The layout engine that refuses to draw

Most rendering libraries bundle parsing, layout and drawing into one package. litehtml splits that stack and keeps only the first two. The README states that litehtml itself does not draw any text, pictures or other graphics, and that it does not depend on any image, draw or font library. What it does is parse HTML and CSS, then place elements at the correct positions. Everything visual is delegated to a callback interface called document_container, which the host application implements.

That division is the whole pitch. If your application already has a font stack, a GPU surface or a framebuffer, litehtml will not drag in a second one. The README frames the target use case directly: showing simple HTML tooltips or HTML-formatted text, where pulling in something like WebKit would be disproportionate. The same paragraph warns against the opposite expectation, saying that using litehtml as a full-featured HTML engine is not recommended. Read those two sentences together and the scope is clear. This is a component for applications that need formatted text, not a browser engine.

## gumbo-parser for HTML, litehtml for CSS and boxes

HTML parsing is not handled in-house. The README states that litehtml uses gumbo-parser, described there as an implementation of the HTML5 parsing algorithm written as a pure C99 library with no outside dependencies. Gumbo produces the document tree; litehtml walks that tree, applies CSS2 and CSS3 rules, and computes where each box goes. The repository layout matches this description: include/ and src/ hold the engine, containers/ holds container-related code, and support/ sits alongside cmake/ and the top-level CMakeLists.txt for building.

The output of that pipeline is geometry plus the callbacks your container receives. Because litehtml does not own text measurement, your container has to report font metrics back to the engine before the engine can finish positioning. That is the practical consequence of the design: layout quality depends partly on how faithfully your container answers those measurement questions. A container that reports approximate text widths will produce approximate line breaks.

The project also constrains its input format. The README states that litehtml supports only UTF-8 strings. If your application stores text in UTF-16, you convert before handing it over.

## Building litehtml and rendering a first document

The repository ships a CMakeLists.txt at the top level, and the README points to the source code on GitHub as the place to get it. There is no package-manager install line in the README, so the build starts from a clone. The README does not document build commands, so the exact configure and build invocations come from the CMakeLists.txt and the cmake/ directory in the repository rather than from the project documentation.

Once the library is built, the real work is the container. The README links the document_container wiki page and describes the interface as really simple, while also stating that a document_container implementation is required to render HTML correctly. The shape of the integration is: you create a document, hand it HTML, and the engine calls back into your container for drawing and measurement. The README does not include a complete code sample, so the wiki page is the reference for the exact method signatures.

For a quick visual check without writing a container, the README points to litebrowser, a simple browser available as a download from litehtml.com. Source for it is published for Windows, Linux and Haiku. Running litebrowser against a page is the fastest way to see what the engine does with a given stylesheet before you commit to an integration.

## Where litehtml stops: standards coverage and missing pieces

The README is unusually direct about this. It states that litehtml is not fully compatible with HTML/CSS standards and that there is lots of work to do to make it work as well as modern browsers. The supported CSS properties are listed in an external spreadsheet linked from the README, which means coverage is something you check property by property rather than assume.

That has a concrete consequence for adoption. If your HTML arrives from a third party, or if your stylesheets use layout modes outside the supported table, you will spend time discovering what silently degrades. The README notes that pages built with the bootstrap framework are usually well formatted, which is a useful data point but not a guarantee for arbitrary CSS.

The larger gap is scripting. The README does not describe a JavaScript engine, and the related searches around litehtml and JavaScript are not answered by anything in the project description. If you need dynamic behaviour in the rendered document, you implement it in the host application by manipulating the document tree yourself. For tooltips and formatted text this is fine. For anything resembling a real web page, it is a wall.

## Alternatives: Lexbor, RmlUi and Qt WebEngine

The related searches name several adjacent projects, and the differences matter more than the labels.

Lexbor is a C HTML parser and CSS engine. The distinction from litehtml is the language boundary and the packaging: litehtml is C++ and expects a C++ container to do the drawing, while Lexbor is aimed at C consumers. If your application is C throughout, that boundary is the deciding factor.

RmlUi takes a different route entirely. It defines its own subset of HTML and CSS, oriented around user interfaces, and it renders. litehtml instead accepts real HTML5 parsing through gumbo-parser and asks you to supply the renderer. If you want a UI toolkit with a rendering backend included, RmlUi is closer to that shape. If you want to render existing HTML and keep your own drawing code, litehtml is.

Qt WebEngine sits at the other end. It embeds a full browser engine, with the binary size and build complexity that implies. The README's own framing is the comparison to keep in mind: for simple HTML tooltips or formatted text, something like WebKit is more than the job needs.

One more distinction worth stating. litehtml is a library you link into a C++ program, not a standalone application. The litebrowser projects exist to demonstrate the engine, not to be the product.

## Licence, releases and the cost of upgrading

litehtml is distributed under the New BSD License, which the README links to the BSD-3-Clause text. That is a permissive licence with attribution requirements, and it is compatible with closed-source integration in the usual way permissive licences are. The dependency is a separate matter: the README states that gumbo-parser is distributed under the Apache License, Version 2.0. Two licences, two sets of obligations, and the Apache patent grant is part of what you inherit. Whether that fits your distribution model is a question for your own counsel, not for this article.

The release history is uneven. v0.8 was released on 2023-05-19, v0.9 on 2024-01-31, and v0.10 on 2026-06-13. That is roughly one release per year or slower, with a long gap between v0.9 and v0.10. The repository's last push was on 2026-09-28, so development activity is current even though tagged releases are infrequent.

Plan upgrades around that cadence. There is no documented migration guide in the README, so the practical approach is to pin a tag, read the diff between it and the next one, and re-run litebrowser against your own test pages before moving. Because layout changes can shift text positions, visual diffing of your actual documents is more useful than reading a changelog.

## Conclusion

Adopt litehtml if you need HTML-formatted text or a small browser view inside a C++ application and you are prepared to write a document_container that handles fonts, images and clipping yourself. Do not adopt it if you need JavaScript, a complete CSS implementation, or a drop-in widget that renders out of the box; the README states plainly that using it as a full-featured HTML engine is not recommended. Before committing, verify the CSS property table against the stylesheets you actually ship, and confirm that your toolchain builds the CMakeLists.txt target on the platforms you support.

## FAQ

### What is litehtml 0.9?

v0.9 is a tagged release of litehtml, published on 2024-01-31, between v0.8 (2023-05-19) and v0.10 (2026-06-13). The README describes litehtml generally as a lightweight HTML rendering engine with CSS2/CSS3 support that parses and positions elements but does not draw them.

### What are the alternatives to litehtml?

The README compares litehtml against full browser engines, noting that something like WebKit is unnecessary for simple HTML tooltips or formatted text. Related projects that come up alongside it include Lexbor, a C HTML parser and CSS engine, and RmlUi, which defines its own HTML/CSS subset for user interfaces and includes rendering.

### Does litehtml support JavaScript?

The README does not describe a JavaScript engine or any scripting support. litehtml parses HTML with gumbo-parser, applies CSS, and places elements; anything dynamic has to be driven by the host application through the document tree and the document_container callbacks.

### What do I have to implement to render with litehtml?

A document_container. The README states that litehtml draws no text, images or graphics itself and that implementing this callback interface is required to render HTML correctly. It handles the drawing and the font and image work your application needs.

### Which platforms does litehtml support?

The README states that litehtml is compatible with any platform supported by C++ and STL, and recommends MS Visual Studio 2013 for Windows. It also states that only UTF-8 strings are supported.

### How do I try litehtml without writing a container?

Download litebrowser, the simple browser the README points to for testing the rendering engine. Source code for it is published for Windows, Linux and Haiku.

## Sources

- [License: BSD-3-Clause](https://github.com/litehtml/litehtml/blob/master/LICENSE)
- [litehtml/litehtml on GitHub](https://github.com/litehtml/litehtml)
- [Project website](http://www.litehtml.com/)
- [README](https://github.com/litehtml/litehtml/blob/master/README.md)
- [Releases](https://github.com/litehtml/litehtml/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/litehtml-litehtml