iperf3-win-builds: unmodified Windows binaries for a tool that stopped shipping them

A gap in upstream Windows binaries, filled by compilation

iperf3 measures maximum network throughput and reports throughput, jitter and packet loss, with tunable parameters for timing, buffers, protocols and stream counts. The upstream project lives at esnet/iperf. What this repository handles is narrower: the packaging for one operating system.

The reason it exists is stated plainly in the README. The last official binary release for Windows was 3.1.3 in 2016, and everything since has been source only. So the repository's stated goal is to produce an iperf3 Windows executable without any modification to the original source code. That constraint is the design decision worth noting: this is a build and release pipeline, not a fork. If a behaviour looks wrong to you, the answer is upstream, not here.

Each binary is checked with VirusTotal before upload, which addresses the obvious objection to running an unsigned executable of this kind. Licence handling is delegated too, with the esnet/iperf copyright and disclaimer applying to the distribution and the upstream LICENSE linked from the README. The repository itself is Apache-2.0 and carries a LICENSE file alongside the README.

Four zip files, and the choice is really OpenSSL or no OpenSSL

Release packaging is a table of four files, and reading it tells you most of what you need. The recommended artefact is `iperf-<ver>-win64.zip`, built without OpenSSL. Two variants add OpenSSL, `iperf-<ver>-win64-static-auth.zip` and `iperf-<ver>-win64-dynamic-auth.zip`, both carrying the authentication extra feature, with the difference between them being whether the OpenSSL libraries are linked statically or dynamically. A fourth file, `iperf-<ver>-win7-64Bit.zip`, exists specifically for Windows 7.

The build matrix tracks upstream versions against the toolchain used. Version 3.22 was built on Cygwin 3.6.10-1.x86_64 for Windows 11 64-bit with OpenSSL 3.5.8, 3.21 on Cygwin 3.6.7-1.x86_64 with OpenSSL 3.0.19, and 3.20 on Cygwin 3.6.5-1.x86_64 with OpenSSL 3.0.18. The OpenSSL column therefore describes the library available to the auth builds rather than what the plain zip links against.

One caveat about that table: it is not stable across versions. The 3.20 and 3.21 lines list OpenSSL 3.0.x while 3.22 moves to 3.5.8, so if you pin a specific zip for a specific test, record which line it came from.

Download, unzip, and check what the build can do

There is nothing to install. The releases page carries the zips, you extract one, and you run `iperf3.exe` from wherever you put it. Because the goal is unmodified upstream behaviour, the first thing worth doing is asking the binary what it can do:

iperf -v

The README flags a real trap here. Optional features in iperf3 are OS specific, since some depend on functions and modules available only under certain kernels, and `iperf -v` is the documented way to list which ones your build actually has. A feature missing on Windows is a platform property, not something this repository removed.

For a first real run, pick a server and use one of the four documented command shapes:

iperf3.exe -c <server> -P 10 -4 -R

That is TCP download with ten parallel streams over IPv4, the flag combination the README lists for TCP Download. TCP Upload drops the `-R` flag, and the UDP variants insert `-u` before the stream count. Running against a public server without a server of your own is possible, and the README recommends the R0GGER public-iperf3-servers list, with as62240.net/speedtest also listed.

Public servers are convenient and give you someone else's bottleneck

The README lists several public servers with their ports, which invites a mistake. A public endpoint measures the path to that endpoint, and it is almost always shared, rate limited and located somewhere you did not choose. nyc.speedtest.clouvider.net and la.speedtest.clouvider.net both offer ports 5200 to 5209, iperf3.velocityonline.net offers 5201 to 5210, and speedgauge2.optonline.net, charlotte02.speedtest.windstream.net and iperf.scottlinux.com are listed on port 5201.

If you want to know your own capacity, run the server mode on the far end of the link you care about and connect to it. The README states that every binary goes through download, upload, client mode, server mode and parallel stream tests before release, which tells you server mode works in these binaries.

There is also a documentation gap worth naming. The README does not document how to verify a download against a published checksum or signature. VirusTotal scanning is stated as the pre-upload check, which is not the same thing as a verifiable checksum for the person downloading.

Server mode, and the four test lines the maintainer runs

The release checklist in the README is worth reading as a statement about what is actually exercised. Five cases are run before a binary ships: Download, Upload, Client mode, Server mode and Parallel streams. Anything outside that list is unverified, which for a packaging repository is an honest and useful thing to publish.

Because the binary is upstream iperf3, the flags come from the upstream manual rather than from this project. Authentication on the OpenSSL builds corresponds to upstream iperf3 authentication support, and the fact that it is available at all is why the auth variants exist as separate zips instead of a single build.

Release cadence is regular. Version 3.22 was published on 2026-09-30, 3.21 on 2026-04-10 and 3.20 on 2025-11-15, and the last push to the repository was on 2026-09-30, the same day as the 3.22 release. That pattern suggests the cost of staying current is low and that versions arrive when upstream does.

Against building it yourself, and against a commercial speed test

The real alternative is compiling iperf3 from esnet/iperf yourself, which is what this repository exists to avoid. Doing that on Windows means setting up a Cygwin toolchain, matching the compiler and library versions in the build table above, and reproducing whatever the maintainer did that produced a working executable. That work is tractable but repetitive, and it lands on whoever needs the binary rather than on a maintainer.

The other comparison is a consumer speed test, and the difference in approach is what the README itself flags. People use iperf to evaluate internet speed and public servers are provided for that, but iperf3 exposes timing, buffers, protocol and stream count as parameters and reports jitter and packet loss, which puts it in the network engineering category rather than the ISP marketing one. The same README says iperf3 results are considered much more accurate and reliable, which is a claim the repository makes rather than something you can confirm from it.

Neither alternative changes the adoption question, which is about whether you trust a redistribution of an unsigned executable whose build script is not in the repository.

Editorial conclusion

Use this repository if you need iperf3 on Windows today and do not want to reproduce the Cygwin build yourself, since it tracks upstream releases rather than forking them. Do not use it if you need a signed installer or a build provenance chain you can audit, because the repository ships two files, LICENSE and README.md, with no build scripts to inspect. Before adopting, download `iperf-3.22-win64.zip` from the releases page and run `iperf -v` to confirm the feature list matches what your test needs.

Frequently asked questions

Official sources

1. ar51an/iperf3-win-builds on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases