cpdf-binaries: prebuilt cpdf executables for every desktop platform

A binary drop, not a source tree

This repository holds the compiled cpdf executables for the Coherent PDF command line tools. The description puts it plainly: PDF Command Line Tools binaries for Linux, Mac, Windows.

The tree shows exactly what that means. There is no source code here, no build system and no package manifest. Instead there is a directory per platform: Linux-ARM-64bit, Linux-Intel-32bit, Linux-Intel-64bit, MacOS-ARM, MacOS-Intel, Windows-32bit and Windows-64bit. Alongside them sit ACKNOWLEDGEMENTS.md, Changes.txt, LICENSE.md, a man page in both plain text and HTML form as cpdf.1 and cpdf.1.html, and cpdfmanual.pdf, which is the PDF manual itself shipped inside the repository.

The primary language recorded for the repository is HTML, which is a consequence of the cpdf.1.html and the manual rather than of any logic in the tree.

So the model is: the tool itself is developed elsewhere, and this is where the artefacts land. That distinction matters for how you read the rest of the documentation, because almost everything a user needs to know about running cpdf is here, while everything about how it is implemented is not.

The repository is not archived, and the last push was on 2026-09-25. There are no GitHub releases, so the version history in this repository is the Changes.txt file rather than a release feed.

Install the binary, or take it from a package manager

The documentation gives two routes and the second one is usually the better one.

The manual route is described under To Install. The program cpdf, or cpdf.exe for Windows, is a single executable with no dependencies. You copy it to somewhere suitable on your platform and it runs. No runtime, no shared libraries, no installer.

The package manager route is the table of commands. Cpdf may be available in your package manager:

brew install cpdf

on macOS, and on Linux the same command shape appears for the RPM and Debian families:

dnf install cpdf

apt-get install cpdf

The full list covers Windows with winget install cpdf and choco install cpdf, macOS with brew install cpdf, Linux Fedora, RHEL and CentOS Stream with dnf install cpdf, Ubuntu with apt-get install cpdf where the universe repository must be configured, Debian with apt-get install cpdf, Arch through the AUR package cpdf, Gentoo with emerge app-text/cpdf, NixOS with nixshell -p OCamlPackages.cpdf, and Alpine with apk add cpdf.

Two details in that table are the kind that waste an afternoon. On RHEL and CentOS Stream the EPEL repository has to be configured first, and on Ubuntu the universe repository has to be configured first. Both are ordinary packaging friction, but both produce a confusing failure rather than an obvious one.

The NixOS entry also tells you something about the tool's implementation, since it pulls cpdf from an OCaml package set. That is consistent with the upstream project's use of OCaml, and it is a reminder that cpdf is not a Python or Node tool but a native command line program.

What the tool actually does, in the vendor's own list

The functionality list in the readme is long, and it is worth scanning because it shows the scope beyond the split and merge that most people know cpdf for.

On document structure: quality split and merge keeping bookmarks, extracting pages, splitting on bookmarks, copying, removing and adding bookmarks, putting multiple pages on a single page, building a table of contents, and reconstructing malformed files.

On protection and content: encrypt and decrypt including AES 128 and AES 256 encryption, and the ability to detect missing fonts and low resolution images.

On page appearance: scale, rotate, crop and flip pages, scale pages to fit, stamp logos, watermarks, page numbers and multiline text, with transparency, and embed TrueType fonts when adding text.

On interoperability, the list includes support for Unicode UTF8 text input and output, export and import of PDF files in JSON format, convert text to PDF, draw on PDF files with graphics and text, make PDF based presentations, rasterize PDF files, and create and process PDF/UA-1 and PDF/UA-2 files.

Two entries stand out for a technical audience. The JSON import and export means a PDF can round-trip through a scriptable intermediate format, which is the difference between cpdf being a tool you use by hand and a tool you drive from a pipeline. And the PDF/UA-1 and PDF/UA-2 support is accessibility work, with PDF/UA being the ISO standard for accessible PDFs.

There are also odds and ends that reveal the tool's history: thicken hairlines, blacken text, make draft documents, and list, copy, set or remove annotations.

The AGPL, and the commercial licence you may need instead

The licensing arrangement is the first thing in the readme after the logo, and it is not a formality.

Cpdf is distributed under the AGPL, and the readme states it plainly: if you are unable to abide by the terms of the AGPL, you will need a commercial license. For commercial licenses you email [email protected] or visit the vendor's site.

So the practical question for anyone picking this up is whether their use triggers AGPL obligations. The AGPL is the copyleft licence designed for software that runs as a service over a network, and the vendor's own framing is that you need a commercial licence if you cannot abide by it. This is a licensing matter to settle with your own legal advice, not something this article can decide for you, but the fact that the vendor sells an alternative licence is itself informative: the AGPL here is a chosen business model, not an accident.

The repository also carries an ACKNOWLEDGEMENTS.md file, which for a binary distribution is the place to record what went into the build, and a Changes.txt file, which is the changelog for a project that does not use GitHub releases.

Support is routed through the issue tracker in this repository or by email to the vendor. There is also a very low volume cpdf-announce mailing list on Google Groups, which the readme recommends for keeping up to date.

Where this repository is the wrong answer

There is a clear set of cases where pulling binaries from here is the wrong move.

The first is when your platform already packages cpdf. Nine of the entries in that table cover mainstream distributions, and a package manager gives you a version that the distribution has tested against its own libraries and will update for you. Downloading a static binary by hand to a machine that already has a package is pure downside.

The second is supply chain hygiene in a managed environment. A binary copied into a filesystem by a person is not in your configuration management, is not covered by your distribution's security updates, and has to be tracked by hand. The package manager route, or your own build, is what most security policies will accept.

The third is platform coverage. The tree has Linux on ARM 64 bit, Intel 32 bit and Intel 64 bit, macOS on ARM and Intel, and Windows on 32 bit and 64 bit. There is no Android build here, and the readme points to an unofficial third-party Android build of cpdf in someone else's repository. If you are deploying to Android, you are outside the officially supported set, and the readme's warning about third party sources in general is worth extending to that link.

The fourth is the macOS experience. The executable is codesigned but not notarized, so if it refuses to run the first time you go to System Preferences, then Security and Privacy, and click Allow anyway. That is a Gatekeeper prompt on every fresh machine, which is friction in any deployment where the machine is not interactive.

The fifth is old systems. The last version of cpdf compatible with Windows XP is v2.2.1, which is a useful marker for how far back the tool reaches, and a reminder that if you are running something that old, the current binaries are not for you.

Against your package manager, and against writing it yourself

Two comparisons make the decision simple.

The first is against the package manager route, which is covered above and is nearly always better where it exists. The difference in approach is that the package manager gives you a build made by the distribution, tracked by the distribution, updated on the distribution's schedule, with the source package available for audit. The binary repository gives you the vendor's own artefact, which is closer to what the vendor tested, and which is the only option on platforms nobody packages for.

The second is against writing your own PDF manipulation code. The functionality list is the argument here. Reconstructing malformed files, detecting missing fonts and low resolution images, producing PDF/UA-1 and PDF/UA-2, encrypting with AES 256, and round-tripping through JSON are each a project on their own, and most of them need a PDF parser and a PDF writer that agree with each other and with the specification. cpdf is a single dependency free executable that does all of it, and the manual PDF at the root of this repository is the reference for how to drive it.

The one thing the binaries do not remove is the licensing question. Whether you take the binary from this repository, from a package manager, or build from the upstream source, the AGPL terms are the same. The choice between these routes is about distribution and maintenance, not about licensing.

Editorial conclusion

Adopt cpdf-binaries when you need the cpdf command line tools on a platform your package manager does not cover, or when you want the exact upstream executable rather than a distribution build. Skip it if your platform already packages cpdf, because the package manager route is simpler to update. Verify first that the AGPL terms suit your use, since the project states that users unable to abide by the AGPL need a commercial licence, and check the architecture folder you download against your machine, since the tree carries separate 32 bit and 64 bit builds plus ARM variants.

Frequently asked questions

Official sources

1. coherentgraphics/cpdf-binaries on GitHub
2. Issues
3. License: AGPL-3.0
4. README