NetImgui: running a Dear ImGui debug menu on a second machine over TCP

A debug menu that lives on a different machine

NetImgui is a library to remotely display and control Dear ImGui menus with an associated NetImgui Server application, and the README says it is designed to painlessly integrate into an existing codebase with few changes required. The mechanism is specific: any program using Dear ImGui receives input from a remote PC and then forwards its UI rendering to it, including textures, vertices, indices and draw commands. The program itself does not change where it runs or how it draws. It keeps drawing its ImGui content as usual, and NetImgui carries the result elsewhere. The origin story explains who this is for. It was initially created to assist game developers debugging a game running on a game console or smartphone from a PC, and the README says its use extends to wider applications. The stated requirements are modest: the program uses Dear ImGui with C++, and TCP/IP communications are available. No engine, no platform framework and no asset pipeline are assumed.

The six-step loop between client and server

The README describes the runtime as a cycle with two halves. The NetImgui Server captures the user's inputs with mouse and keyboard, sends those inputs to the client and requests a draw update. The NetImgui Client then draws the Dear ImGui content normally, without needing to display it on the client, and sends the drawing results back to the server, which receives them and displays them. Then the loop starts again at step one. The important consequence is where the Dear ImGui backend lives. Because the client still calls the normal rendering path, the drawing calls happen on the machine running the program, while the presentation and the input happen on the desktop. That split is what makes the technique work on a device with no display at all. The library handles the transport of the geometry and the input events; it does not reimplement Dear ImGui or attempt to render on the remote machine.

Three reasons the UI moves off the device

The README groups the motivations into three numbered cases, and each is a distinct engineering problem rather than a restatement. The first is UI for devices without display or input. Some applications lack display and input access, which prevents feedback and easy control, for example a program running on a Raspberry Pi device or Unreal 4 running in server mode, and NetImgui lets you display an interface with full control on your PC while the logic stays in the client application. The second is ease of use. Inputs might be available on a particular device, keyboard or gamepad, but still be inconvenient for certain aspects, and text entry is more comfortable on a physical keyboard than on a smartphone, with the same argument for console controllers and for VR development. The third is decluttering. Dear ImGui is often used to show debug information during development, and those UI elements can obscure the regular content, so sending them to a remote window leaves the original display clean and free for more elaborate content. The README includes before and after captures for that case.

The integration is three calls and two substitutions

The integration steps are numbered in the README and are short enough to reproduce. You download the latest version of the NetImgui library from the releases page and add the content of Code/Client to your codebase. In your codebase the calls are placed like this:

   - [once]
     - Call `NetImgui::Startup()` *(at program start)*.
     - Call `NetImgui::ConnectToApp()` or `NetImgui::ConnectFromApp()`.
     - Call `NetImgui::Shutdown()` *(at program exit)*.
   - [every redraw]
     - Draw your ImGui menu as usual.

So the change is three calls at program start and exit, plus a frame-handling substitution on every redraw if you are on Dear ImGui 1.80 and lower or want frameskip support: replace the call to ImGui::NewFrame() with NetImgui::NewFrame(), and the call to ImGui::Render() or ImGui::EndFrame() with NetImgui::EndFrame(). The library is C, the topics list dear-imgui and remote-access, and the licence is MIT. More integration detail lives in the project wiki, and the repository includes multiple samples that the README says provide further insight, including SampleNoBackend, a console application that connects to the NetImguiServer and draws its ImGui content with no rendering or input backend of its own.

Four ways to establish the connection

How the two halves find each other is a separate decision, and the README enumerates four options. The first is that the server waits for a connection and the client calls ConnectToApp() with the server address. The other three have the client call ConnectFromApp() and then wait, with the server either configured with the client's address and connecting to it, launched with the client's address on the command line, or receiving the client's address from another application through a Windows named pipe at the path \\.\pipe\netImgui. That last option is the interesting one for a studio setup, because a build or launcher process can point the debug server at a running instance without the developer typing an address. The named pipe route is Windows specific, while the other three are ordinary TCP/IP. Two further capabilities are documented. Different Dear ImGui content can be displayed locally and remotely at the same time, and NetImgui::IsConnected() and NetImgui::IsDrawingRemote() can be called during Dear ImGui drawing to make selective decisions about which debug UI content to show based on the connection state.

Version compatibility and platform limits

Two constraints are stated plainly and both matter before you start. On compatibility, the README says NetImgui is tested against Dear ImGui versions 1.71 to 1.92.5, with a note that other versions should be supported without too much difficulty, and points to Build/GenerateCompatibilityTest.bat for an exact list of tested versions. The version numbering explains the NewFrame substitution in the integration steps: the frame handling changed in Dear ImGui 1.80, and NetImgui's replacement calls are needed for 1.80 and lower or when you want frameskip support. On platforms, the NetImgui Server application currently compiles under Windows and Mac, and the README says few changes are required to get it running under other operating systems, naming the one it knows of: modify NetImguiServer_App.h to enable the GLFW_GL3 rendering API to compile for Mac. There is a related project for Unreal, the Unreal NetImgui plugin, which adds access to Dear ImGui and NetImgui functionality to Unreal 4. The repository top level is consistent with a C project: Code, Build, a GenerateProject.bat alongside a GenerateProject.sh, and a Clean.bat.

What this is not, and what it costs to maintain

The boundaries are clear enough to state. NetImgui is a debugging and inspection aid, not a remote desktop: it transports Dear ImGui content, so anything you cannot express as an ImGui widget does not travel. It also does not remove the need for a rendering path on the client, since the client draws the content normally, which is why SampleNoBackend is highlighted as demonstrating Dear ImGui with no backend implementation at all. On the server side you are running a real window application with a real mouse and keyboard, so it belongs on a machine with a display. The maintenance picture is a single C library maintained by one author, with the newest tagged release being v1.13 on 2026-01-05, preceded by v1.12.1 on 2024-12-13 and v1.12.0 on 2024-12-08, while the last push to the repository was on 2026-10-17. The source is ahead of the tag, and the MIT licence means you can vendor the Code/Client directory into a closed-source codebase without a licensing negotiation, which is the arrangement most studios will end up with.

Editorial conclusion

NetImgui suits a game or tool developer whose Dear ImGui interface is drawn on a device with no usable display or input, such as a console, a smartphone or a server-mode Unreal build, and who wants the debug menu moved to a desktop without redesigning it. It is the wrong tool for a project that already has a good debug display, since the whole point is to remove the local UI, and it is the wrong tool for a Linux server, because the NetImgui Server application is documented as compiling under Windows and Mac with only small changes needed elsewhere. Verify first that your Dear ImGui version falls inside the tested range of 1.71 to 1.92.5, and note that the newest release is v1.13 from 2026-01-05 while the last push to the repository was on 2026-10-17, so the source tree is ahead of the tagged release.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sammyfreg/netImgui on GitHub