PDFPatcher: a Windows PDF toolbox built on iText and MuPDF

What PDFPatcher solves, and for whom

Most PDF trouble is not authoring. It is repair. A scanned report has no bookmark tree, a vendor's brochure blocks printing, a merged bundle has three page sizes, and a document carries hidden data nobody wants to ship. PDFPatcher targets exactly that class of work. The README lists its scope plainly: modify document properties, page numbering and page links; unify page size; delete actions that open a web page automatically; remove copy and print restrictions; set the reader's initial mode; clean hidden junk data; recompress black and white images; rotate pages.

The audience is narrower than the feature list suggests. This is a Windows desktop application, written in C#, running on Windows 7 or later with .NET Framework 4.0 to 4.8. There is no server component and no documented command line interface. A person who processes a handful of documents a week, or a records team that receives scanned bundles, is the natural user. A backend service that must stamp ten thousand PDFs per hour is not, because nothing in the README describes a headless mode.

The bookmark editor is the part that stands out. It ships with a reading pane, including a right-to-left reading mode for vertical text, batch editing of bookmark attributes (colour, style, target page, zoom level), find and replace inside bookmarks with regular expression and XPath matching, and quick selection of chapter, section and subsection bookmarks. That combination is uncommon in free tools, and it is the reason someone would pick this over a generic viewer.

Inside the tool: iText for structure, MuPDF for rendering

PDFPatcher does not implement the PDF format itself. The README states the program uses .NET Framework and relies mainly on two open source component libraries, iText and MuPDF. The division of labour is explicit. iText is the .NET component with better interoperability with the main program, and the README credits it as stronger at parsing, generating and modifying PDF documents and at embedding TTF font subsets. MuPDF is written in C, and its advantage is rendering PDF pages to bitmaps. PDFPatcher calls that native library through P/Invoke, and the compiled dynamic library is published separately in the author's SharpMuPDF repository.

That split explains the feature set. Anything that rewrites the document graph, such as bookmark editing, page reordering, metadata changes or font replacement, goes through iText. Anything that needs pixels, such as page-to-image conversion, image export, or the rendering pane in the bookmark editor, goes through MuPDF. Other libraries fill in the desktop shell: ObjectListView for lists, FreeImage for decoding bitmap formats, Cyotek's ImageBox for displaying rendered pages, TabControlExtra for the tabbed document interface, and HTMLRenderer for HTML views.

The source layout mirrors the same separation. The App directory holds the main program, split into Common, Functions, Lib, Model, Options and Processor. The Processor directory holds the PDF algorithms, and its Mupdf subdirectory holds the P/Invoke classes. Model holds the higher level editing model, while the base data model comes from iText and MuPDF classes. Anyone reading the code to extend it should start there, because the boundary between managed document editing and native rendering is the boundary between the two component libraries.

Installing PDFPatcher and editing a bookmark tree

The README does not give an installer command line. It points to the project homepage and the two source repositories, and it states the runtime requirements: Windows 7 or later with .NET Framework 4.0 to 4.8. The practical install path is to obtain a release build from the project's distribution channel, run it, and confirm the app starts on a machine that already has a supported .NET Framework. If you build from source instead, the README recommends Visual Studio 2022 or newer with the .NET desktop development and C++ desktop development workloads, because the JBIG2 encoding component is C++.

Expect a target framework warning when you open the solution. The README says you may hit a message about the project targeting an unsupported .NET Framework and needing to update to .NET Framework 4.8, and that the simple fix is to retarget to 4.8. The repository root holds PDFPatcher.sln along with the App and doc directories, the manual and the licence text. Open the solution in Visual Studio 2022 and build.

git clone https://github.com/wmjordan/PDFPatcher.git

A first real use is the bookmark editor: open a PDF, switch to the bookmark panel, and edit the tree. The README describes selecting bookmarks in bulk, changing colour, style, target page and zoom level, and running find and replace across the selection with regular expressions or XPath. Matching happens over bookmark text, and a replacement can be applied to a whole selection rather than one node at a time. For documents with no bookmarks at all, the README links to a separate article on generating a bookmark tree automatically, which is the feature to look for when you receive a scan with a usable table of contents page.

Where PDFPatcher stops being the right tool

The platform boundary is the first limitation. Windows 7 or later, .NET Framework 4.0 to 4.8. There is no documented Linux or macOS build, and no documented Docker image. If your pipeline runs on Linux, this project does not fit, regardless of how well its bookmark editor works.

The OCR path is the second. Text recognition in images inside PDFs is done by calling Microsoft Office's image recognition engine, and the README specifies that this requires the Document Imaging component of Microsoft Office 2003 or 2007, known as MODI. That is a dependency on software Microsoft stopped shipping in later Office versions. Anyone whose workflow depends on converting an image-only PDF's contents page into bookmarks should verify that this component is present and working on the target machine before planning around it.

The licence is the third, and it is the one most likely to surprise a commercial team. The project is AGPL, and the README adds conditions on top: a user who benefits from the software should do one good deed after each use, and anyone who builds another program from the source and earns revenue from it should donate at least one thousandth of that revenue to disadvantaged groups. Redistribution must ship the complete, unmodified version and must not alter the licence. Attaching the software to commercial promotional activity or products requires written permission from the copyright holder. The README itself frames compliance as a matter of conscience. That framing does not change the legal weight of the AGPL base, and the repository does not carry an SPDX licence identifier, so a legal review is the responsible step before embedding anything here in a product.

How it compares with general-purpose PDF suites

The related searches around this project point at PDF24 and PDFgear, which is a fair comparison because all three are free desktop PDF tools. The difference is in where each puts its weight. PDF24 and PDFgear are built around a broad, consumer-facing operation set: convert, compress, protect, sign, fill forms, print. They are aimed at someone who wants a file converted now.

PDFPatcher is aimed at the document's internals. The README's feature list includes analysing document structure in a tree view, editing PDF nodes, and exporting the document to XML for analysis and debugging. It includes extracting or deleting specified pages, reordering pages, renaming files from PDF metadata, replacing fonts and embedding font libraries so text copies correctly and renders on devices without the font, such as Kindle readers. It includes high speed lossless image export. Those are not the operations a general converter leads with.

The bookmark handling is the clearest divergence. A general suite typically lets you add a bookmark. PDFPatcher lets you batch-edit bookmark attributes, target a bookmark to the middle of a page, and run regular expression or XPath replacements across a selection. If your problem is a badly structured bookmark tree across a hundred chapters, that is the difference that matters. If your problem is turning a DOCX into a PDF, PDFPatcher is the wrong tool and the general suites are the right ones.

Maintenance, releases and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-31. Recent tagged releases are v1.0.2 on 2024-06-13, v1.0.4 on 2024-09-30 and v1.1 on 2025-02-01. The gap between those tags is measured in months, so plan for a project that moves in steps rather than a continuous stream. The default branch is v1.2, which is ahead of the newest tag, so building from source gives you code that has not been released as a version.

The upgrade cost is dominated by the runtime, not the application. Because the target is .NET Framework 4.0 to 4.8, the tool depends on a framework that ships with Windows rather than on a self-contained runtime. That makes installation light and makes moving to a newer .NET impossible without a port that the README does not describe. The README's own build note about retargeting to .NET Framework 4.8 is the practical ceiling: 4.8 is the end of that line.

For change tracking, the repository carries 更新历史.txt at the root and a doc directory for usage documentation, plus a 使用手册.docx manual. Those are the files to read before upgrading a working installation, because the README itself does not document rollback or a downgrade procedure. Treat an upgrade as a one-way move unless you keep the previous build.

On licence, the AGPL base means anyone distributing a modified version, or offering the software as a network service, takes on the AGPL's source disclosure obligations. The additional conditions in the README layer charity and redistribution terms on top. Nothing here is legal advice; the concrete step is to read 授权协议.txt in the repository alongside the AGPL text and have counsel confirm how the combination applies to your distribution model.

Editorial conclusion

Adopt PDFPatcher if your work is Windows desktop PDF surgery: rewriting bookmark trees, merging scans with generated bookmarks, stripping print and copy restrictions, or dumping a document's object structure to XML for debugging. Do not adopt it if you need a Linux or macOS command line tool, a library to link into your own service, or a permissively licensed codebase, because the runtime is Windows 7 or later with .NET Framework 4.0 to 4.8 and the licence is AGPL with an added charity condition. Before relying on it, open the 更新历史.txt file for the changes between v1.0.2, v1.0.4 and v1.1, and confirm whether the OCR path you need still depends on the Microsoft Office 2003 or 2007 Document Imaging component.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wmjordan/PDFPatcher on GitHub