RmlUi: HTML and CSS for a game engine, minus the browser

A libRocket fork that kept the document model and replaced the rest

The README states the lineage in one sentence: RmlUi is a fork of the libRocket project, introducing new features, bug fixes and performance improvements. That origin explains more about the design than any feature list does. libRocket was an HTML and CSS interface system for games, and it defined a way of describing interface in markup with a cascade attached. RmlUi inherited that and rebuilt the parts that had aged.

The positioning sentence is unusually concrete. RmlUi takes your HTML and CSS-like source files and turns them into vertices, indices and draw commands, and then you bring your own renderer to draw them. That is the whole contract in one line, and it is the reason the library fits inside an existing engine. Nothing here wraps a graphics API. Nothing calls into your windowing system. The output is buffers and a draw call description, and the translation to Direct3D, OpenGL, Vulkan, Metal or whatever your engine already uses happens on your side.

Alongside the buffers you get full access to the element hierarchy, event handling, and the interactivity and customizability you would expect. All of it is driven from C++, or optionally from scripting languages through plugins.

The README makes a size claim worth quoting with care, because it is the kind of number people repeat without the qualifier. It says the core library compiles down to fractions of the size it takes to integrate a fully fledged web browser. That is directionally true and quantitatively unanchored, since no byte counts are given and the comparison depends entirely on which browser and which build configuration you measure against. Treat it as a claim about the absence of a browser engine rather than as a number you can plan around.

The stated standards base is XHTML1 and CSS2, extended with selected HTML5 and CSS3 features, plus additions suited to real-time applications. RmlUi 6 sits at version 6.3, released 2026-08-22.

Conformity is traded away deliberately, and the README says so

Most UI libraries aimed at games are vague about standards. This one is not, and the honesty is useful. The README says it aims to support the most common and familiar features from HTML and CSS while keeping the library light and performant, and then says the decisive part: it does not aim to be fully compliant with CSS or HTML, in particular when it conflicts with lightness and performance. Users are generally expected to author documents specifically for RmlUi, but any experience and skills from web design should be transferable.

That last sentence is the practical instruction. Take a web developer's instincts as a starting point, not as a specification to code against, because the places where CSS is heavy or slow are exactly the places RmlUi diverges.

The supported CSS2 baseline is broad, and the CSS3 additions listed are the ones that matter for interfaces: animations and transitions, transforms with full interpolation support, flexbox layout, media queries, border radius, custom properties and variables, box shadows and mask images, gradients in linear, radial and conic form as decorators, and filters including backdrop filters with all the CSS filter functions. On the HTML side, most common elements are there, including `<input>`, `<textarea>` and `<select>`, which matters because those three are where hand-rolling goes wrong fastest.

Two links in that section are the real reference. The RCSS property index documents every supported property and the differences from CSS, and the RML element index does the same for elements. RCSS is the name for RmlUi's styling sheet, and treating it as a dialect rather than as CSS with bugs is the right mental model.

Worth flagging one overlap. The README lists custom properties and variables among the supported CSS3 features, while the 6.3 release notes name the addition of custom RCSS properties and variables as that release's biggest feature. Both statements are consistent if you read the first as the current state and the second as the change that produced it, but the pairing is a reminder to check the property index for the version you are actually building against rather than assuming a given feature existed before the release that introduced it.

You own the update loop, and the library never calls back

The Controllable section of the README is short and it is the part that decides whether RmlUi fits your architecture. You control your own update loop, calling into RmlUi as desired. The library strictly runs as a result of calls to its API, never in the background. Input handling and rendering is performed by you. The library generates vertices, indices and textures for you to render how you like. File handling and the font engine can optionally be fully replaced by you.

There is no thread, no timer, no callback from nowhere. This is a deliberate inversion of how most UI middleware behaves, and it has a concrete payoff in a game: your interface advances on the same clock as your simulation, so a paused game gets a paused menu, and a frame hitch in your render loop is a frame hitch in the UI rather than a desynchronisation you have to debug.

The replacement clauses matter just as much. Swapping the font engine means you are not obliged to accept FreeType, which on some targets is the difference between linking a third-party library with its own licensing and reading glyphs with platform APIs you already call. Replacing file handling means documents can come from an archive, an asset bundle, or memory the game built at load time, which is the normal shape of shipped games and not something a filesystem-only design supports well.

Extensibility follows the same philosophy. The README lists abstracted interfaces for plugging into any game engine, a decorator engine allowing custom application-specific effects that can be applied to any element, a generic event system that binds into existing projects, and easy integration with the Lua scripting plugin. Decorators are the unusual one and they are where the CSS-like layer earns extra credit: rather than styling only elements, a decorator can intercept rendering for all of them, which is how you get a consistent scanline or damage flash across a whole interface without touching the documents.

One dependency, one standard requirement, three package managers

The dependency list is short enough to state in full: FreeType, and the standard library. A C++17 compatible compiler is required. That is the entire external surface, and the README notes that FreeType can be fully replaced by a custom font engine.

FreeType is the interesting one. Most libraries with a text rendering requirement either accept it as given or hide a heavier text stack behind an abstraction, and RmlUi's position is that FreeType is the default and the interface is the extension point. Whether you take the default depends on your target, since on console and mobile platforms a system font API is often already present and already licensed for the platform's terms.

Building is a CMake job, and the README points at a build documentation page for the options, with prebuilt Windows binaries published for the latest release. Three acquisition routes are documented. vcpkg installs it in one command:

vcpkg install rmlui

Conan carries it in ConanCenter, which the README calls out as readily available. And building from source with the samples needs vcpkg to supply the dependency, git, and CMake presets:

vcpkg install freetype glfw3
git clone https://github.com/mikke89/RmlUi.git
cd RmlUi
cmake -B Build -S . --preset samples -DRMLUI_BACKEND=GLFW_GL3 -DCMAKE_TOOLCHAIN_FILE="<path-to-vcpkg>/scripts/buildsystems/vcpkg.cmake"
cmake --build Build

That block shows three things about the build at once. Presets are used rather than a long flag list, so the interesting option is `--preset samples`. Backends are selected by name with a CMake variable, and `GLFW_GL3` is the OpenGL one. And the toolchain file is passed by path, which the README reminds you to replace, a step that catches people out because the command is otherwise copy-pasteable.

The samples build produces executables in the `Build` directory, with the `invaders` sample built as the `rmlui_sample_invaders` target. Extra sample backends and features come from installing `lua lunasvg rlottie harfbuzz` and configuring with `--preset samples-all`, so the four packages map to the scripting plugin, SVG image loading, vector animation, and font shaping support respectively.

What the releases actually changed, and what the repository does not say

Three releases are visible, and their contents describe where the project is spending its effort. Version 6.1 on 2025-04-20 is described as following up on one of the largest releases yet, with quality-of-life improvements and some bug fixes, and the overall aim being that the library feels more polished. Version 6.2 on 2026-01-11 concentrates on fixing small issues throughout the library and improving developer experience, while still shipping features, among them native touch input handling and a data model explorer. Version 6.3 on 2026-08-22 lists new features, bug fixes and better CSS conformance, with custom RCSS properties and variables as the headline, positioned as a way to define style values once and reuse them across style rules, and combined with media queries.

Read together, that is a project two releases into spending effort on developer experience rather than on new subsystems. Native touch input and a data model explorer are both tools for the person building the interface, not features for the person using it, and the 6.3 note about variables being a great help for defining style values once is the same register.

The cadence is roughly every six to eight months, and the last push was 2026-09-14, so the branch is receiving work between releases rather than sitting still after one. With 4,455 stars, 475 forks and 53 open issues, this is a project with a real user base and a real queue, and the 53 is worth reading as an active backlog rather than as neglect.

Two things the repository does not say are as informative as the things it does. It publishes no topics at all, an unusual choice for a project at this visibility, which means topic-based search tells you nothing about it. And the source files are lowercase: `readme.md`, `contributing.md`, `changelog.md`. That is cosmetic on a case-insensitive filesystem and only matters on Linux, where it will bite anyone scripting against the old capitalised names. The tree is otherwise conventional and unusually clear: `Include/` and `Source/` for the library, `Backends/` for the renderer and platform layer, `Samples/`, `Tests/`, `Utilities/`, `Dependencies/` and `CMake/`, plus a `.clang-format` and a top-level `AI_POLICY.md`. The MIT licence sits in `LICENSE.txt`.

Editorial conclusion

RmlUi occupies a specific gap that no other library quite fills: real HTML and CSS authoring for a game, with a layout engine small enough to ship and an output shape of raw vertices that fits any renderer. The fork history explains the architecture, since libRocket's bones are why the document model and the CSS-like styling sheet exist at all, and the 6.x line has been spent making that older base behave like modern CSS rather than replacing it. Expect to author for RmlUi rather than for the web, because the README says outright that full compliance is not the goal and that conflicts with lightness or performance are resolved against compliance. Two practical notes first. FreeType is the only real dependency and the README says it can be replaced wholesale with a custom font engine, so a missing system font library is not a blocker. And the project publishes zero topics despite 4,455 stars, so topic-based discovery tells you nothing about it. Track 6.3 from 2026-08-22 rather than master, and bring your own renderer and update loop, since the library never calls you back.

Frequently asked questions

Official sources

1. License: MIT
2. mikke89/RmlUi on GitHub
3. Project website
4. README
5. Releases