# LibVNCServer and LibVNCClient for C remote desktop applications

> LibVNCServer and LibVNCClient add RFB server and client capabilities to C programs across platforms. The libraries are a practical fit for embedded and native applications, but authentication support depends on the selected cryptographic backend.

**LibVNC/libvncserver** — LibVNCServer/LibVNCClient are cross-platform C libraries that allow you to easily implement VNC server or client functionality in your program.

- Repository: https://github.com/LibVNC/libvncserver
- Stars: 1,368 · Forks: 573
- Language: C
- License: GPL-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/libvnc-libvncserver

## LibVNCServer's RFB server and client scope

LibVNCServer addresses a specific native-application problem: exporting a framebuffer through the RFB protocol so that a VNC viewer can connect to it. Instead of implementing the protocol handshake, framebuffer updates, transports, and encoding negotiation from scratch, a C program can embed the library and connect its own screen data and input handlers. The same repository also contains LibVNCClient, which supplies the client counterpart.

The intended audience includes developers building administration interfaces, embedded systems, and applications with a graphical framebuffer that needs remote access. The README points to a tentative list of projects using either library, but it does not provide a complete compatibility list or qualify each listed deployment.

This is a code-level library, not a ready-made remote desktop daemon. An application still needs to expose its framebuffer, route pointer and keyboard input, create the server or client instance, and connect those operations to LibVNCServer or LibVNCClient. The linked API introduction and the example directories are therefore the first places to look for an application-specific design. The repository structure, with headers, C sources, tests, examples, and platform build files, reflects that role.

## RFB negotiation, transports, and encoding coverage

A VNC connection begins with RFB protocol negotiation. After the server and viewer agree on the protocol details, available security types, and encodings, the server can describe changes to its framebuffer. LibVNCServer handles the library side of that exchange while the host application supplies the pixels and handles user input. The README describes the broad purpose of RFB as exporting a framebuffer over the network; it does not document the low-level callback sequence, so that sequence must be confirmed in the API documentation or examples.

Encoding support differs between the server and client. Both sides list Raw, CopyRect, RRE, CoRRE, Hextile, Zlib, Tight, Ultra, ZRLE, and ZYWRLE. LibVNCClient additionally lists TRLE. LibVNCServer alone lists TightPNG. These are protocol capabilities, not a guarantee that every viewer will select the most efficient encoding for a particular framebuffer.

Transport coverage is asymmetric. Both libraries support RFB. LibVNCServer also supports WebSockets and encrypted WebSockets, which lets browser viewers such as noVNC connect when the server is configured for that transport. LibVNCClient lists encrypted RFB through VeNCrypt and AnonTLS. This split matters when designing an application that must connect to arbitrary enterprise VNC servers, because the client library has a broader documented set of transport and security options than the server library.

The server security table lists only None and VNC Authentication, while the client table additionally lists SASL, MSLogon, Apple ARD, TLS, VeNCrypt, and UltraVNC MSLogonII. An application should therefore choose a backend and security policy before assuming compatibility with a particular viewer.

## CMake build setup and backend selection

The documented build starts with CMake. Run the following commands from the repository root. CMake generates the build configuration in a separate `build` directory, and `cmake --build .` compiles the configured targets.

```bash
mkdir build
cd build
cmake ..
cmake --build .
```

This is the first executable verification available from the repository instructions. The README does not state the names or locations of every resulting library and example binary, so a reader should inspect the CMake output rather than expect a particular file name.

Authentication and WebSocket behavior depend on the cryptographic backend. OpenSSL is selected with `-DWITH_OPENSSL=ON -DWITH_GCRYPT=OFF`, while Libgcrypt is selected with `-DWITH_OPENSSL=OFF -DWITH_GCRYPT=ON`. The README states that either backend supports all authentication methods in both libraries and supports WebSockets in LibVNCServer. With both options off, the included backend supports only VNC authentication, although LibVNCServer still supports WebSockets.

The following command selects OpenSSL during configuration:

```bash
cmake .. -DWITH_OPENSSL=ON -DWITH_GCRYPT=OFF
cmake --build .
```

TLS support has a separate choice. The documented OpenSSL setting is `-DWITH_OPENSSL=ON -DWITH_GNUTLS=OFF`. GnuTLS is selected with `-DWITH_OPENSSL=OFF -DWITH_GNUTLS=ON`. The README does not give a detailed conflict matrix for every combination, so projects with existing OpenSSL or GnuTLS dependencies should inspect CMake's configuration results rather than assume that either selection is interchangeable.

## First server integration through the documented examples

The README does not include a complete server program, so it would be inaccurate to invent one here. Its direct instruction is to use the LibVNCServer API introduction for creating a server instance, wiring input handlers, and handling cursors. For a first integration, start from the server implementations in `examples/server` rather than writing callback setup from memory.

The examples are also the best available tutorial for the complete first use because the repository contains both the library sources and runnable example code. Open the relevant server example, identify how it constructs the server, how it supplies framebuffer data, and where pointer or keyboard events are attached, then adapt those calls to the application's event model. The API documentation is the authority for the current signatures.

A first real use should verify three integration boundaries. First, confirm that the host application's framebuffer format is compatible with the encoding and cursor path selected by the example. Second, confirm that client input is delivered to the correct application or UI event target. Third, confirm that the build includes the transport needed by the intended viewer. Browser access through noVNC depends on the server's documented WebSocket support rather than on WebSocket support in LibVNCClient.

The README does not document a rollback procedure, a daemon package, a default listening port, or a sample client configuration. Those details must not be inferred. The project offers building blocks and examples, while deployment policy, network exposure, and authentication configuration remain application responsibilities.

## Security backend limits client compatibility

The largest practical limitation is the difference between protocol capability and build configuration. LibVNCClient documents support for TLS, SASL, MSLogon, Apple ARD, VeNCrypt, and UltraVNC MSLogonII. The README states that OpenSSL or Libgcrypt supports all authentication methods in LibVNCClient and LibVNCServer, whereas the included backend supports only VNC authentication.

That distinction affects more than a checkbox in CMake. A client compiled with only the included backend may be unable to negotiate the security type expected by a particular remote server. A server compiled with only the included backend has a narrower documented security set even though it can still serve WebSocket clients. None means no VNC Authentication, but the security consequences depend on deployment and are not explained as a policy recommendation in the README.

WebSocket support should not be confused with encrypted WebSocket support. Both appear in the server transport table, but the README does not explain their configuration or negotiation details in this section. It also does not publish a production hardening checklist in the excerpt. Developers should use `SECURITY.md`, the API documentation, and the exact build options when designing an exposed deployment.

This makes LibVNCServer less suitable as a drop-in choice when a fixed viewer ecosystem demands a security type that the selected configuration does not provide. It remains appropriate when the application controls the server side, can select a supported backend, and can state its accepted authentication methods clearly.

## Maintenance, licensing, and alternatives

The repository is not archived, and the last push was on 2026-10-07. That is the maintenance information available here. The README also identifies `NEWS` as the place for users who have worked with LibVNCServer before, and the release procedure lists updates to `AUTHORS`, `NEWS`, `CMakeLists.txt`, generated API documentation, and `ChangeLog`. Those files indicate that upgrades require attention to release notes, version changes, and documentation, but the README does not describe a formal compatibility policy.

The repository identifies the project under the GPL-2.0 license and includes `COPYING`. Distribution and linking implications depend on the application's own structure and use, so this review does not provide legal advice. The important operational point is to check the actual `COPYING` file and the way the library is incorporated before shipping a product.

A real alternative is implementing the RFB protocol directly in an application-specific networking and framebuffer layer. That approach avoids adopting this library's callback and build structure, but leaves the application responsible for protocol negotiation, encodings, transports, and security types. LibVNCServer is the better fit when those mechanisms already exist in a C library. Direct implementation may be preferable when the protocol surface is a formal application requirement, the build cannot accept the library's configuration model, or the required transport is absent from the documented table.

A complete remote desktop product may also use an existing VNC server or client rather than embedding either library. The README does not compare those products, so the practical distinction is architectural: LibVNCServer supplies reusable C protocol code, while a standalone application supplies the complete user-facing remote desktop environment.

## Conclusion

Adopt LibVNCServer when a native or embedded product needs to export an RFB framebuffer or connect to VNC services, and consider LibVNCClient when the same C codebase needs the corresponding client side. Do not assume that the default build provides the authentication methods required by your deployment. Verify the `WITH_OPENSSL` and `WITH_GCRYPT` configuration against the required RFB security types, then inspect `examples/server` or `examples/client` for the integration path that matches your application.

## FAQ

### How do I build LibVNCServer with CMake?

Create a `build` directory, run `cmake ..` from inside it, and then run `cmake --build .`. The README lists CMake as the build system and links Unix and Windows CI configurations as more comprehensive build references.

### Can LibVNCServer connect through an in-browser VNC viewer?

Yes. The README states that LibVNCServer supports WebSockets, allowing an in-browser viewer such as noVNC to connect. It also lists encrypted WebSockets as a server transport, but does not provide detailed configuration instructions in the excerpt.

### Which authentication methods does LibVNCClient support?

The client security table lists None, VNC Authentication, SASL, MSLogon, Apple ARD, TLS, VeNCrypt, and UltraVNC MSLogonII. The README states that OpenSSL or Libgcrypt supports all authentication methods, while the included backend supports only VNC Authentication.

## Sources

- [Issues](https://github.com/LibVNC/libvncserver/issues)
- [LibVNC/libvncserver on GitHub](https://github.com/LibVNC/libvncserver)
- [License: GPL-2.0](https://github.com/LibVNC/libvncserver/blob/master/LICENSE)
- [README](https://github.com/LibVNC/libvncserver/blob/master/README.md)
- [Releases](https://github.com/LibVNC/libvncserver/releases)

---

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