# pdfium-lib builds Google's PDFium for seven platforms from one patched checkout > pdfium-lib is a MIT licensed Python project that compiles PDFium, the PDF engine from Chromium, to iOS, macOS, Linux, Windows, Android and WebAssembly, with per-platform GitHub Actions workflows and prebuilt binaries on the releases page. The author is explicit that the project only patches PDFium to make it build for those targets, and that the licence and official details belong to Google. **paulocoutinhox/pdfium-lib** — PDFium - Project to compile PDFium library to multiple platforms. - Repository: https://github.com/paulocoutinhox/pdfium-lib - Website: https://pdfviewer.github.io/ - Stars: 1,072 · Forks: 125 - Language: Python - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/paulocoutinhox-pdfium-lib ## The project patches PDFium, it does not replace it The description says this is a project to compile PDFium library to multiple platforms, and the note under the platform list is where the actual relationship is explained. PDFium project is from Google and I only patch it to compile to all platforms above. The reader is told to check all official details and the PDFium licence at pdfium.googlesource.com. That sentence matters for two reasons. It sets the scope: this is a build engineering project, a set of patches and scripts that make an upstream C++ library compile for a wider set of targets, and the upstream project remains the source of truth for behaviour, for the API and for the licence. And it sets the licensing boundary: the MIT licence here covers the personal project, and the licence section says the same thing, that this licence information is about this personal project and not about the Google PDFium Library, with the MIT text and the copyright line Copyright (c) 2018-2026, Paulo Coutinho. So the deliverable is a patched PDFium with a build system around it, not a PDF library. The patch is applied to a specific PDFium git branch, and the branch is configured in one place. The tools are Python, and the top-level entries reflect the structure of the work. There is make.py, which is the build driver, a modules/ directory holding the configuration including modules/config.py, requirements.txt for the Python dependencies, docs/ with the per-platform guides, extras/ with the images and assets, a docker/ directory, and three sample applications: sample/, sample-apple/ and sample-wasm/. The primary language recorded for the repository is Python, and the topics list chromium, cpp, google, library, pdf, pdfium and webassembly, which is the dependency chain in one line: a Chromium component, written in C++, built for the web. ## Seven targets, and a workflow badge for each The platform list is explicit about what is covered. * iOS device, arm64 * iOS simulator, x86_64 and arm64 * Android, armv7, armv8, x86 and x86_64 * macOS, x86_64 and arm64 * Linux, x86_64 * Windows, x86_64 * WASM, Web Assembly Above that list sit six workflow badges in the README header, one for iOS, one for macOS, one for Android, one for Linux, one for Windows and one for WASM, each pointing at its own GitHub Actions workflow file. So every target is built by CI rather than by a person's machine, which is what makes the prebuilt binaries trustworthy and keeps the platform matrix from rotting when only one maintainer is working on it. The matrix also shows where the value is. Desktop Linux, Windows and macOS are the platforms where PDFium is easiest to obtain, since it ships inside Chromium and can be built with the ordinary Chromium toolchain. The interesting entries are the ones that are not desktop: iOS device and simulator, Android across four architectures, and WebAssembly. A team that needs a PDF renderer inside an iOS or Android application, or a PDF viewer that runs entirely in a browser tab, is exactly the audience for a project whose job is to make an upstream C++ library build for those targets. The WebAssembly build is worth singling out, because it is the one that changes what is possible. The README says that since this project generates a WASM version, a demo was published that you can test PDFium directly in a web browser. ## The shared setup fetches Depot Tools and puts it on the path There are general steps that have to be executed before all the other platform steps, and they are the same on every platform. First, get the source. ```bash git clone https://github.com/paulocoutinhox/pdfium-lib.git cd pdfium-lib ``` Second, install the Python requirements. ```bash python3 -m pip install -r requirements.txt ``` Third, get Google's Depot Tools. ```bash python3 make.py build-depot-tools export PATH=$PATH:$PWD/build/depot-tools ``` The three observations that follow are practical rather than decorative. The make.py file needs to be executed with Python version 3, so the interpreter choice is not optional. These steps only need to be done one time, which matters because the next step is per platform and per architecture. And if you want to change the pdfium git branch, you edit the file modules/config.py and other places with the same branch name, which tells you that the upstream revision is a single setting that has to be changed in more than one spot. The build requirements are short, and listed in the README as Ninja Build, Python 3 and PIP, with a note that Python 3 generally already comes with PIP installed, and a way to check it with the command python3 -m pip --version. The build itself is driven by make.py, and the per-platform work is delegated to documentation rather than to the README, which keeps the top-level file short and puts the platform-specific instructions where they belong. ## Each platform has its own document, and the browser demo proves the WASM build After the shared steps, the README hands off to a separate document per platform. Build for iOS is docs/BUILD_IOS.md, macOS with Apple Silicon, M1, is docs/BUILD_MACOS.md, Linux is docs/BUILD_LINUX.md, Windows is docs/BUILD_WINDOWS.md, Android is docs/BUILD_ANDROID.md, and WASM is docs/BUILD_WASM.md. There is a seventh document that is not about a platform at all, How to include files, which is docs/HOW_TO_INCLUDE_FILES.md and covers extending PDFium. That last one is the most consequential of the seven for an adopter. PDFium on its own renders PDF; the reason people embed it rather than shelling out to a browser or a converter is usually that they need to get at the document structure, the text, the images or the rendered pages programmatically. The include-files guide is where the project explains how to bring your own files into the build, and it is the part of the documentation that determines whether the library is useful to you rather than merely buildable. The demo is the other way to judge the WASM output without building anything. The published site is at pdfviewer.github.io, and the README shows that it can be pointed at a public PDF with a parameter, for example the tracemonkey sample from the Mozilla pdf.js sample files repository, passed as a url parameter alongside a title parameter. ```text https://pdfviewer.github.io/?title=Demo%20PDF%20with%201MB&url=https://raw.githubusercontent.com/mozilla/pdf.js-sample-files/master/tracemonkey.pdf ``` For people who just want the library, there is also the prebuilt binary route. The README says to access the releases page to download prebuilt binaries, and the release tags in this repository are PDFium revision numbers rather than project versions, which is a useful thing to know when you are tracking what you are shipping. ## Four Python dependencies, and one of them is a WebAssembly runtime The requirements file is short and each entry tells you something about how the build works. ```text docopt black pygemstones>=0.0.13 wasmtime ``` docopt is a command-line argument parser, and the README's own note that the make.py file needs to be executed with Python version 3 points at a command line tool with a real interface. black is the formatter, which is a style decision rather than a functional one. pygemstones is a gem packaging tool, which fits the pattern of a project that builds several different artefacts from one source tree. The interesting one is wasmtime. That is a WebAssembly runtime, and its presence in a build dependency list says that the WASM output is not only compiled but also exercised, that the build runs the produced module, and that the project can run the WebAssembly build locally to check it rather than trusting the CI badge alone. There is also a docker/ directory at the root, which is the obvious way to reproduce the environment without installing Ninja, Python and the toolchain by hand, and the sample directories show the shape of a consumer: sample/ with a CMakeLists.txt, an assets/ folder and a src/ folder, plus the platform-specific sample-apple/ and sample-wasm/ variants. The other top-level file worth noting is CLAUDE.md, which sits next to the README and the LICENSE.md, and an .editorconfig and a .github/ directory for the workflows. ## The licence boundary is the thing to get right The licence section of the README is short and does the most important work in the file, and the distinction it draws is the one a reader has to carry away. This license informations is about this personal project, not the Google PDFium Library. The MIT text follows, with Copyright (c) 2018-2026, Paulo Coutinho. So there are two licences in play and they cover different things. The MIT licence covers the build scripts, the patches, the configuration and the samples in this repository. The PDFium licence covers the library itself, and it is the one that governs what you ship if you embed PDFium in a product. The README sends you to pdfium.googlesource.com for the official details and the licence, and the right reading of that instruction is that the upstream terms, not the MIT text here, are what apply to the compiled artefact. This is a licensing fact rather than legal advice. The practical advice is to treat the upstream terms as governing and to check them for the platforms you ship to, because a library embedded in a mobile application is a distribution and a library embedded in a browser as WebAssembly is a distribution too. On maintenance, the repository is not archived, the default branch is master, and the last push was on 2026-09-10, the same day as the newest release tag, 8046d, with 8046c and 8046 in the days before it. The release tags track the PDFium revision, so a stable tag means the embedded engine is pinned to a specific upstream commit rather than to a project version. The project is funded through Ko-fi, with the README describing it as support for the continuous development of this project, and the same page links to the author's other projects. ## Conclusion pdfium-lib fits a developer who needs PDFium, the Chromium PDF engine, on a platform that does not ship it, especially iOS, Android or WebAssembly, and who would rather not assemble the toolchain themselves. It does not fit someone who needs PDFium on desktop, where building it from the official sources is a documented path, and it does not fit anyone who wants the PDFium licence terms changed. Before building, read the per-platform guide in docs/, and take the PDFium licence from pdfium.googlesource.com rather than from this repository. ## FAQ ### What is pdfium-lib and how does it relate to Google's PDFium? It is a Python project to compile the PDFium library to multiple platforms. The README says the PDFium project is from Google and that the author only patches it to compile to all the listed platforms, with the official details and the PDFium licence at pdfium.googlesource.com. ### Which platforms does pdfium-lib build for? iOS device on arm64, the iOS simulator on x86_64 and arm64, Android on armv7, armv8, x86 and x86_64, macOS on x86_64 and arm64, Linux on x86_64, Windows on x86_64, and WASM. Each has its own GitHub Actions workflow and its own build document under docs/. ### What are the requirements to build pdfium-lib? Ninja Build, Python 3 and PIP, with a note that Python 3 usually already has PIP and that you can check with python3 -m pip --version. You also need Google's Depot Tools, which the build fetches for you with python3 make.py build-depot-tools and then puts on the path. ### How do I change which PDFium revision pdfium-lib builds? Edit the file modules/config.py and other places with the same branch name. The README notes this as part of the general setup steps, and the release tags in the repository track the PDFium revision, so a tag such as 8046d pins a specific upstream commit. ### Can I use pdfium-lib in the browser? Yes. The project generates a WASM version and the README publishes a demo that tests PDFium directly in a browser at pdfviewer.github.io, which can also be pointed at a public PDF with a url parameter. The build guide for it is docs/BUILD_WASM.md, and the Python dependencies include wasmtime, a WebAssembly runtime. ## Sources - [License: MIT](https://github.com/paulocoutinhox/pdfium-lib/blob/master/LICENSE) - [paulocoutinhox/pdfium-lib on GitHub](https://github.com/paulocoutinhox/pdfium-lib) - [Project website](https://pdfviewer.github.io/) - [README](https://github.com/paulocoutinhox/pdfium-lib/blob/master/README.md) - [Releases](https://github.com/paulocoutinhox/pdfium-lib/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/paulocoutinhox-pdfium-lib