FreeRDP: A Client and Library for RDP on Windows, Linux and macOS

What FreeRDP actually is, and who ends up using it

FreeRDP is a free implementation of the Remote Desktop Protocol, released under the Apache license, according to the README. That sentence carries more weight than it looks. RDP is a Microsoft protocol, and the README points readers at the Microsoft Open Specifications site and at a reference documentation page on the project wiki. So the project is not a wrapper around a Microsoft library. It is a from-scratch implementation of the protocol, written in C, with its own documentation trail back to the specification.

The repository layout tells you the shape of the thing. There is a libfreerdp directory, which holds the protocol library itself. There is a client directory, which holds the client programs built on top of that library. There is a server directory, a channels directory for the various RDP virtual channels, and winpr, a portability layer that lets the same C code build on Windows and on Unix-like systems. The uwac directory is a separate piece of the tree, related to Wayland, which is consistent with the search interest in running FreeRDP under Wayland.

So two audiences exist. The first is the application developer who wants RDP connectivity inside a C or C++ program and does not want to write the protocol handling. The second is the person who needs a client program on a desktop where the vendor client is absent or awkward. The README's own framing is about interoperability, and the downloads page at pub.freerdp.com/releases is where the project points for binaries.

How the library, the clients and the channels fit together

The architecture is layered, and the top-level entries make the layers visible. At the bottom sits winpr, the portability layer. Above it sits libfreerdp, the protocol implementation. Alongside both is channels, which holds the implementations of RDP's virtual channels: the mechanisms that carry clipboard data, audio, drive redirection and similar features over the same connection. Then client and server sit on top, each providing an entry point for programs that want to be one end or the other of a session.

This is why the same code base can produce a client and a server. The protocol work is shared, and the role you play is a matter of which side of the connection you instantiate. The README does not walk through the call sequence for either role, and the API documentation lives at a separate URL, pub.freerdp.com/api. That separation matters when you evaluate the project: the README is a signpost, not a manual. Anyone planning to embed the library should expect to read the generated API docs and the wiki, not the front page of the repository.

The channels directory is also where a lot of the practical behaviour lives. A minimal RDP session is mostly screen updates and input. The features people actually notice, such as copy and paste between local and remote machines, or seeing a local folder inside the remote session, are channel work. If you are evaluating FreeRDP for a specific feature, the channel directory is the first place to check whether that feature is implemented at all.

The build system is CMake. The repository carries CMakeLists.txt, CMakePresets.json and a cmake directory, and the README sends readers to a Compilation page on the wiki rather than listing flags inline. That is a deliberate choice: the option set is large and version-dependent, and the project keeps it in one maintained place instead of duplicating it in the README.

Building FreeRDP and getting a session running

The README does not print install commands. It gives a downloads page, pub.freerdp.com/releases, and a wiki page for compilation. If your distribution packages FreeRDP, that is usually the shortest path, because the packaging directory in the repository exists precisely so downstream projects can build distribution packages.

For a build from source, the project's own instruction is to start at the Compilation page on the wiki. The README does not reproduce the commands, so there is no build invocation to copy here. What the repository does show is that configuration goes through CMake: CMakeLists.txt sits at the top level, CMakePresets.json holds named presets, and the cmake directory holds the project's own modules. Read those three before running anything, because the option set is version-dependent.

For embedding, the library target is what you link against, and the API reference at pub.freerdp.com/api is where the entry points are documented. On the client side, the executables live in the client directory and are named for the protocol and the role, for example xfreerdp for the X11 client. The README does not document the flag set or the binary names, so take both from the client's own help output for the build you have. The command-line clients print diagnostics to the terminal, which is one reason they are useful in scripts and support contexts.

What FreeRDP does not do for you

The most common mismatch is expecting a desktop application. FreeRDP ships clients, and the search results around this project include people asking for a GUI, but the README describes a library and clients, not a connection manager. If you want saved profiles, a sidebar of hosts, a credentials vault and a settings dialog, you are looking at a different layer of software. FreeRDP is the engine that such a program might be built on.

The second limitation is documentation depth. The README is short by design and defers to the wiki and to generated API docs. That is fine for a library with a stable public surface, but it means the cost of adopting FreeRDP as a library is not zero: you will spend time in the API reference and in the issue tracker. A team that needs a documented, versioned integration guide before it starts will find less of that here than it might want.

The third is that RDP itself is the boundary. FreeRDP implements a Microsoft protocol, and the README points to the Microsoft Open Specifications for the source of truth. When Microsoft changes behaviour, FreeRDP follows. That is inherent in the project's purpose, not a defect, but it means protocol-level surprises are always possible and the security policy page at github.com/FreeRDP/FreeRDP/security/policy is worth reading before you deploy it in a sensitive network.

Finally, the project is C. If your application is not C or C++ and has no comfortable binding, you are either writing a binding or shelling out to a client binary. Shelling out is a legitimate pattern, and the command-line clients support it, but it gives you a process rather than a session object.

FreeRDP compared with xrdp and with Remmina

The two comparisons people actually search for are xrdp and Remmina, and the difference is direction of travel. FreeRDP is primarily a client-side implementation: the library lets you connect to an RDP server. The server directory exists, and there is search interest in running a FreeRDP server, but the project's identity as described in the README is the protocol implementation and the clients.

xrdp solves the opposite problem. It lets a Linux machine act as an RDP server so that Windows clients can connect to it. If your goal is to log into a Linux desktop from a Windows machine using the built-in Windows client, xrdp is the component you want, and FreeRDP on the Linux side is not the answer. The two can coexist in the same environment, but they occupy different ends of the connection.

Remmina is a graphical remote desktop client. The search question about whether Remmina uses FreeRDP is the interesting one, because it points at the real relationship: a graphical client can be built on top of an RDP library rather than implementing the protocol itself. That is the same relationship described above between FreeRDP and any connection manager. Choosing between them is choosing between a library and an application, not between two implementations of the same thing.

There is also the vendor client. On Windows, the platform ships its own RDP client, and the search data shows people asking how to install FreeRDP on Windows anyway. That is a reasonable question if you want the same client behaviour across platforms, or if you need the library for development on Windows. It is a poor use of time if all you want is to reach a remote Windows machine from a Windows machine.

Maintenance, releases and the licence

The repository is not archived. The last push was on 2026-08-26, and the most recent release listed is 3.31.0 on the same date, following 3.30.0 on 2026-07-16 and 3.29.0 on 2026-07-14. That cadence, with two releases two days apart in July and another in August, suggests a project that ships frequently and does not hold changes for long. For an adopter, frequent point releases mean security and protocol fixes arrive quickly, and also that pinning a version and reading its changelog is more useful than tracking the branch.

The repository carries a ChangeLog at the top level and a SECURITY.md, plus a security policy URL in the README. There is no separate upgrade guide in the top-level listing, so the practical upgrade path is to read the ChangeLog between your pinned version and the target version. The presence of an ABI checker workflow in the README badges is a signal worth noting for library consumers: the project runs an ABI check, which implies an intent to keep the binary interface stable across releases. That is a claim to verify for your own version range, not to assume.

The licence is Apache-2.0. For most users that is permissive and compatible with both open and closed products, and it includes an explicit patent grant, which matters for a protocol implementation. It is not a copyleft licence, so it does not require you to publish your own source. This is a description of the licence text, not legal advice; if your organisation has a licence review process, the LICENSE file in the repository is the document to send through it.

Editorial conclusion

Adopt FreeRDP if you are writing a C program that must speak RDP, or if you need an RDP client on Linux, macOS or Windows that you can drive from a script. Do not adopt it if you want a graphical remote desktop manager with saved connection profiles and a settings dialog; that is a different category of tool. Before you commit, read the Compilation page on the wiki for the options of the version you intend to ship, and read the security policy page so you know how vulnerabilities are reported and handled.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes