# pdfium-binaries: a weekly PDFium build, named by platform, libc and V8 flavour

> pdfium-binaries publishes pre-compiled PDFium builds every Monday, tagged with the Chromium milestone they come from, for Android, iOS, Linux and more. It is a build and distribution project rather than a library, and its own table admits which targets are untested or failing.

**bblanchon/pdfium-binaries** — 📰 Binary distribution of PDFium

- Repository: https://github.com/bblanchon/pdfium-binaries
- Stars: 1,501 · Forks: 295
- Language: Shell
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/bblanchon-pdfium-binaries

## This repository builds PDFium, it does not contain it

PDFium is the open source library for PDF manipulation and rendering, and it lives in its own upstream repository. What this project adds is packaging. It hosts pre-compiled binaries of that library, and the README makes the disclaimer first among the substantive facts: this project isn't affiliated with Google or Foxit. That sentence is not boilerplate. You are downloading a native library that will parse untrusted documents inside your process, from a GitHub releases page, and if your organisation's supply chain review asks who stands behind the artifact, the honest answer is that this is an unaffiliated repackaging. What you get in exchange is the part that takes longest: a working PDFium without building the Chromium tree yourself.

## Builds are triggered every Monday and tagged by Chromium milestone

Automatic builds have run every Monday since 2017, and the release tags encode where each build came from. The three most recent are chromium/8100 corresponding to PDFium 157.0.8100.0, chromium/8086 for 157.0.8086.0, and chromium/8076 for 156.0.8076.0. Two things follow. First, a weekly cadence means a new artifact appears without anyone asking, so an unpinned download resolves to the most recently published artifact. Second, the Chromium milestone in the tag is the useful part of the version number: if a PDFium change you depend on is tied to a Chromium build, you can find the corresponding tag and stop there. The repository has a patches workflow badge, which tells you patches are applied during the build rather than the tree being consumed untouched.

## Every filename encodes four decisions you have to make

The download table has columns for OS, environment, CPU, PDFium and PDFium V8, and reading it as a decision list is the fastest way to use this project. OS picks the platform: Android, iOS or Linux in the visible part of the table. Environment picks the execution context, where Linux splits into glibc and musl, and iOS splits into catalyst, device and simulator. CPU picks the architecture: arm, arm64, x86, x64, and on Linux also mipsel, mips64el and ppc64. The last column is the interesting one: a second parallel set of archives marked PDFium V8, which is the build that embeds the V8 JavaScript engine instead of leaving it out, for hosts that need one. So a filename like pdfium-linux-x64.tgz has already resolved four questions for you, and picking the wrong one is the most common way this project wastes an afternoon.

## Downloading is one request to the latest release

The download links all point at the GitHub releases latest download path with the archive name, so the workflow is a plain fetch. For the glibc x64 Linux build the archive is pdfium-linux-x64.tgz and its link is the releases latest download URL followed by that filename, under the bblanchon/pdfium-binaries releases. The same pattern covers every cell in the table, substituting the platform, environment, architecture and V8 suffix, for example pdfium-v8-linux-x64.tgz or pdfium-ios-device-arm64.tgz. Note what the latest path does not give you: it resolves to whatever was published most recently at the moment you request it. For a build machine, point the same URL at a tagged release instead so it is stable, and record the tag in your build metadata. There is no package manager recipe on the README, so the archive and whatever your language's FFI or dlopen layer needs are the whole integration surface.

## The table admits which targets are untested and which one fails

This is the part of the README worth reading carefully, because it is where the project's real limitations are written down rather than implied. On Linux, the mipsel, mips64el and ppc64 rows have PDFium archives but their V8 column says not tested yet. The musl rows are worse: musl arm64 is marked failing, with issue 192 referenced, and the musl arm row is also not tested yet. Read that as a distribution with uneven coverage. The glibc x64 and arm64 and arm rows are the ones with V8 builds listed, so a musl based container image, which is where server side PDF rendering often ends up, is not a path this project has proven. If your target is Alpine style musl on arm64, verify before you plan around it.

## There is a NuGet package for the .NET crowd

Alongside the release archives the project publishes a NuGet package named bblanchon.PDFium, and the README badges it alongside the latest release. The repository layout backs that up with a nuget/ directory. If you are on .NET this is the path that removes the manual archive handling, because the package resolves a binary for your runtime rather than making you match libc and architecture by hand. That is also why the table matters less to that audience: the mapping happens in the package. For everyone else, the archives are the interface, and the example/ directory in the repository, which contains example.c and a CMakeLists.txt, shows the intended shape of a first native link.

## build.sh, steps/ and patches/ show what the project actually does

The repository root is a build recipe rather than a library: build.sh at the top level, steps/ for the sequence the automation follows, patches/ for the local modifications applied to the upstream tree, .github/ for the workflows including the patches badge you saw at the top of the README, and a .vscode/ directory for local work on the scripts. There is no source directory and no library API, because there is nothing to compile into your product here. If you need to change how PDFium is configured, the patch directory is where you would look first, and if you need to reproduce a specific build yourself, the steps directory is the closest thing to documentation. The primary language of the repository is listed as Shell, which matches that shape.

## Against building PDFium from the Chromium tree yourself

The alternative is to fetch PDFium upstream and build it yourself. The difference is entirely about who absorbs the cost. Building it yourself gives you a configuration you control, patches you apply yourself, and provenance that points straight at upstream, with a full toolchain setup as the price. Using these binaries avoids arranging your own build, at the cost of depending on someone else's build configuration and an unaffiliated release. A team with a security review process and a build team will probably build from source; a team with a deadline and one target platform will take the archive. The mitigation in either case is the same: pin a tag, record it, and re-check when you bump it.

## Conclusion

pdfium-binaries fits a C or C++ project that needs PDF rendering without arranging your own build, especially on a platform where a package manager has no PDFium package, and the V8 variant archives are there for hosts that need a consistent JavaScript engine. Do not take the latest link blindly in a release pipeline, because the table marks several Linux targets as not tested yet and musl arm64 as failing issue 192, so pin a specific tagged release such as chromium/8100 and record which archive you took. Before integrating, confirm the disclaimer is acceptable to you: the project states it is not affiliated with Google or Foxit, which matters if your legal review asks about the provenance of a binary you download from GitHub. The last push was on 2026-10-12 and the newest tag is chromium/8100, PDFium 157.0.8100.0.

## FAQ

### How often are new PDFium binaries released?

Builds have been triggered automatically every Monday since 2017, and each release is tagged with the Chromium milestone it came from, for example chromium/8100 for PDFium 157.0.8100.0.

### Which Linux architectures are known to be untested or failing?

On Linux, mipsel, mips64el and ppc64 have archives whose V8 variants are marked not tested yet, as is musl arm, while musl arm64 is marked failing with issue 192 referenced.

### Is there a NuGet package for PDFium?

Yes. The project publishes a NuGet package named bblanchon.PDFium alongside the release archives, which is convenient for .NET projects that would otherwise have to pick the archive matching their platform and architecture.

## Sources

- [bblanchon/pdfium-binaries on GitHub](https://github.com/bblanchon/pdfium-binaries)
- [Issues](https://github.com/bblanchon/pdfium-binaries/issues)
- [License: MIT](https://github.com/bblanchon/pdfium-binaries/blob/master/LICENSE)
- [README](https://github.com/bblanchon/pdfium-binaries/blob/master/README.md)
- [Releases](https://github.com/bblanchon/pdfium-binaries/releases)

---

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