Nuklear: a single-header immediate mode GUI library in ANSI C

What Nuklear solves, and who it is written for

Nuklear is a minimal-state, immediate mode GUI toolkit written in ANSI C. The README describes it as a simple embeddable user interface for applications, and the emphasis is on embeddable. It does not create a window. It does not read input from the operating system. It does not draw anything. What it does is take a mirrored input state, run your UI code for the frame, and emit a list of draw commands describing primitive shapes.

That shape of library suits a specific kind of developer: someone who already has a rendering loop, usually in C or C++, and wants widgets inside it without adopting a framework. Game tools, debug overlays, small editors and internal utilities fit naturally. The project targets C89, so it compiles in environments where a modern C compiler is not a given, and the README states there are no dependencies, not even the standard library if you do not want it.

The trade-off is blunt. Every abstraction a normal GUI toolkit hands you (event queue, window management, font loading, texture upload) is work you do yourself. Nuklear gives you a widget layer and a draw command stream. Everything on either side of that is your problem.

The frame loop: input in, draw commands out

Nuklear's model is a per-frame cycle. Once at startup you initialise a context and a font. Then, every frame, you mirror the window's input into the context, build the interface with widget calls, and hand the resulting commands to your renderer.

The README gives the general structure directly. Setup happens once, with a fixed memory buffer and a user font whose width function you supply:

struct nk_user_font font;
struct nk_context ctx;

font.userdata = nk_handle_ptr(your_font_data);
font.height = your_font_height;
font.width = your_text_width_calculation;
nk_init_fixed(&ctx, calloc(1, MAX_MEMORY), MAX_MEMORY, &font);

Input mirroring is bracketed by nk_input_begin and nk_input_end, with motion, button and key calls in between. UI construction happens between nk_begin and nk_end for each window. Drawing walks the command list with nk_foreach and switches on the command type, dispatching each one to a function you wrote. The frame ends with nk_clear.

Two details matter more than they look. First, the command stream is the only output. If your renderer cannot draw lines, rectangles or text, nothing appears. Second, the README warns that every time you include nuklear.h you must define the same optional flags, and that failing to do so leads either to compiler errors or, worse, stack corruptions. That is not a stylistic preference; it is a structural constraint of the single-header approach.

Installing Nuklear and building the GLFW demo

There is no package manager step in the README. The library is the file nuklear.h at the repository root, so installation means copying that file into your project and defining NK_IMPLEMENTATION in exactly one translation unit before including it:

#define NK_IMPLEMENTATION
#include "nuklear.h"

Every other file that includes nuklear.h omits that define and gets only declarations. If you include it in a header of your own, keep the optional flags identical everywhere, per the warning above.

The fastest way to see it running is the demo folder, which holds ready-to-use backends for GLFW, SDL, X11, GDI, Direct3D, Vulkan and others. Each has its own build instructions. The README gives one example:

make -C demo/glfw_opengl3

That builds the GLFW and OpenGL 3 backend. Running the resulting binary should show a window containing the sample interface from the README: a button, two option labels, a volume label and a slider, inside a movable, closable window with a border. The demo folder is the practical starting point, because it contains both the backend glue and a working main loop you can read. The example folder holds more complete programs.

Where Nuklear is the wrong tool

The library's own framing is the clearest limitation: it has no default render backend and no OS window or input handling. If your project does not already own a window and a render loop, Nuklear hands you a second problem before it solves the first. A desktop application that just needs a settings dialog is better served by a toolkit that manages its own windows.

The single-header build model has a sharp edge. The README's warning about defining the same optional flags on every include is explicit that mismatches cause compiler errors or stack corruption. In a large codebase with several translation units including nuklear.h, that is a discipline problem, not a one-time setup step.

Memory is your responsibility too. The README example uses nk_init_fixed with a caller-allocated buffer and a fixed size, which means the ceiling is set by you and behaviour past it is not described in the README. The project advertises a low memory footprint with total control over memory usage, and that control cuts both ways.

Finally, the bindings list comes with a disclaimer. The README states the author cannot attest to the quality of the third-party bindings for Java, D, Go, Rust, Nim, Python, C# and others, and that there is no guarantee they stay up to date. If you are not writing C or C++, you are depending on code the project does not stand behind.

Nuklear vs Dear ImGui: retained state against immediate mode

The comparison people reach for is Dear ImGui, and the difference is not cosmetic. Both are immediate mode, so both rebuild the interface every frame. The split is in what ships alongside the widget layer.

Dear ImGui is C++, and the Nuklear README credits it as the inspiration for the library. Nuklear is C89, single-header, and has no default render backend. Its demo folder holds ready-to-use backends for GLFW, SDL, X11, GDI, Direct3D, Vulkan and more, each with its own build instructions.

The language difference is not incidental. Nuklear's C89 target means it compiles where C++ does not, and its no-dependency stance means it can be dropped into a constrained build.

The second real alternative is to write the widgets yourself against your renderer. For a handful of buttons and a slider that is genuinely less code than integrating any library, and it avoids the include-flag discipline entirely. Nuklear starts paying off when the widget count grows past what you want to maintain by hand.

Licence, maintenance and upgrade cost

The README introduction states the library is licensed under public domain, while its License section says it is available under either the MIT License or public domain. The repository's licence metadata is recorded as NOASSERTION, which means the automated classifier did not match the LICENSE file to a standard identifier. Those two facts sit together awkwardly, and anyone embedding this in a commercial product should read the LICENSE file at the repository root rather than relying on either summary. Nothing here is legal advice.

On maintenance, the last push to the repository was on 2026-11-01, and the most recent release listed is v4.13.4 from 2026-10-31. The repository is not archived. The README does not document a deprecation policy, a support window or a rollback procedure.

Upgrade cost is dominated by the single-header model. Because the implementation is generated from the source files under src/ by the top-level Makefile, the shipped nuklear.h is a build artefact. That means an upgrade replaces one file, which is cheap, but any local patch to that file is lost. The README does not describe a supported way to carry local modifications forward, so if you patch nuklear.h you own the merge on every version bump.

Editorial conclusion

Adopt Nuklear when you already have a window, an input loop and a renderer, and you want a small C89 UI layer you can compile into that program without pulling in a framework. Do not adopt it if you want a toolkit that opens a window for you, or if you need a rendering backend the demo folder does not already cover. Before committing, verify two things: that you can define the same optional flags everywhere nuklear.h is included, and that one of the demo backends matches your platform closely enough to adapt.

Frequently asked questions

Official sources

1. Immediate-Mode-UI/Nuklear on GitHub
2. Issues
3. Project website
4. README
5. Releases