KillerPDF: a GPL-3.0 Windows PDF editor with a headless CLI and its own PDF 2.0 engine

What KillerPDF solves, and who it is actually for

The pitch is narrow and clear: a Windows desktop PDF editor that does not require an Adobe subscription, and that keeps document processing on the local machine. The README states there is no account and no telemetry, with the single exception of optional startup update checks that contact GitHub, enabled by default, and which require confirmation before downloading and installing an update. Those checks can be turned off in About or in the update dialog.

The audience is the person who already has a PDF problem and does not want a browser tab: annotate a contract, OCR a scan, fill a form, merge a folder of invoices, or flatten a document before sending it out. KillerPDF targets Windows 10 or 11 on x64 only. There is no macOS or Linux build documented, and the topics list confirms the platform scope. If you are on a Mac, this project is not for you, and no amount of feature coverage changes that.

The second audience is developers. KillerPDF 1.8 introduces The KillerPDF.Engine, described in the README as an independent and reusable .NET library for PDF 2.0, PDF/A and PDF/UA document processing, living in the same monorepo with its own public API, tests, corpus tooling and release history. The desktop application is built on that engine for parsing, writing, editing, repair, forms, annotations, signatures and preservation-sensitive page operations. So the engine is not a side project bolted on; it is the pipeline the app itself uses.

How the KillerPDF.Engine and the desktop app fit together

The repository layout makes the split visible at a glance. The top level holds the WPF application files (App.xaml, MainWindow.xaml, Controls/, Features/, Services/, Themes/, Strings/), and next to them sits engine/, a separate directory with its own README and tests. Both target .NET 10, with the application on net10.0-windows. The solution file KillerPDF.sln ties them together, and KillerPDF.Tests/ covers the app side.

Rendering is done with PDFium, described in the README as high-quality rendering with four view modes: Single, Continuous, Two-Page with a book layout option, and Grid. Documents open in tabs, and a split pane shows two documents side by side. Each tab carries its own undo and redo history, which matters more than it sounds: in a tool where you annotate across several files at once, a shared undo stack would be a usability trap.

Conformance is handled as a test suite rather than a promise. The README states that every release is tested against a 2,900-file veraPDF conformance corpus with a zero-regressions requirement, and points to validation/RESULTS.md for the output. That is the kind of claim a reader can check in the repository, which is the right place for it.

The engine targets PDF 2.0, PDF/A and PDF/UA. PDF/UA is the accessibility profile, and PDF/A is the archival profile. Those two standards constrain what an editor is allowed to write, which is presumably why the README frames page operations as preservation-sensitive. If your output has to satisfy an archival or accessibility checker, that is the part of this project worth reading first.

Installing KillerPDF and running a first headless merge

On Windows the fastest route is a package manager. The README gives both WinGet and Chocolatey commands.

winget install killerpdf

choco install killerpdf

If you prefer a direct download, the README lists two release assets: KillerPDF.exe, the standard installer, and KillerPDF-Portable.exe, the portable edition. The standard installer is framework-dependent and uses the .NET 10 Desktop Runtime, offering to install it when needed. The portable package includes its own runtime and works offline without installation. Choose the portable build if you cannot install a runtime on the target machine.

Building from source requires the .NET 10 SDK. The README gives this sequence:

git clone https://github.com/SteveTheKiller/KillerPDF.git
cd KillerPDF
dotnet publish -c Release

Output lands in bin/Release/net10.0-windows/publish/. Normal publishing produces the development build plus a versioned KillerPDF-<version>-src.zip; the release pipeline is what produces the installer and the portable executable.

The first genuinely useful thing to try is the command line, because it works even while the app is open. To merge two PDFs and a scanned JPEG into one file:

KillerPDF.exe --merge out.pdf a.pdf b.pdf scan.jpg

That single flag set tells you a lot about the design: the CLI accepts images alongside PDFs, so a scan can be folded into a merge without a separate conversion step. From there, `KillerPDF.exe --help` prints the full reference, and the README notes the CLI returns meaningful exit codes, which is what makes it usable inside a script.

The CLI flags worth knowing before you script anything

The README lists the headless operations directly, and they map onto the GUI feature set. Page extraction takes a range expression: `KillerPDF.exe --extract-pages in.pdf 1-3,5 out.pdf`. Splitting writes one file per page into a directory: `KillerPDF.exe --split in.pdf pages\`. Decryption prompts for a password, or takes one inline: `KillerPDF.exe --decrypt locked.pdf open.pdf [--password p]`.

Image export carries its own parameters. `KillerPDF.exe --to-image in.pdf imgs\ --dpi 300 --format jpg` sets resolution and format per invocation. Flattening is a separate operation, `KillerPDF.exe --flatten in.pdf flat.pdf`, and the README describes Save Flattened in the GUI as rasterizing to a fully uneditable PDF. That is a destructive step by design, so keep the source file.

OCR is bundled rather than cloud-based: `KillerPDF.exe --ocr scan.pdf searchable.pdf --lang eng`. The README states Tesseract is bundled and extra languages download on demand. Printing from the CLI takes a printer name, page range and copy count: `KillerPDF.exe --print in.pdf --printer "HP LaserJet" --pages 1-4 --copies 2`. For bulk work there is `KillerPDF.exe --batch-resave inDir\ outDir\ --log report.csv`, which writes a CSV report. If you are processing a directory of documents unattended, that log is the only audit trail the README mentions, so plan to keep it.

One gap worth naming: the README documents no rollback or dry-run mode for batch operations. `--batch-resave` writes into an output directory, which limits the blast radius, but there is no documented preview pass.

Where KillerPDF is the wrong tool

The platform constraint is the first real limitation. Windows 10 or 11, x64, and nothing else. The README does not mention a macOS or Linux build, and the repository topics list windows and wpf. If your team is mixed-platform, this is a single-platform tool no matter how good the feature list looks.

The second limitation is the licence. KillerPDF is GPL-3.0. That is fine for internal use and fine for anyone who accepts the copyleft terms, but it is a genuine constraint for a company that wants to embed the engine in a closed product. The README notes that each release ships corresponding source as KillerPDF-<version>-src.zip, which is the GPL obligation being met in the open. Anyone planning to redistribute KillerPDF or build on The KillerPDF.Engine should read the licence before writing code, not after.

The third limitation is scope of automation. The CLI covers merge, split, extract, decrypt, image export, flatten, print, OCR and batch resave. It does not expose annotation, form filling, comparison or transform as headless operations in the README. If your workflow is "fill this form field programmatically," the documented interface does not do it.

Finally, there is a maintenance detail a reader should weigh: the release history shows v1.8.5 on 2026-09-15, then v1.8.6 and v1.8.61 on 2026-09-22. That is a burst of releases on a single day, which is normal for a project fixing issues quickly, but it also means version numbers move fast. Pin a specific release if you are deploying to a fleet rather than tracking latest.

How KillerPDF differs from browser-based PDF tools

The obvious alternatives people search for alongside KillerPDF are PDFgear, PDF24 Creator, iLovePDF and Smallpdf. The first two are desktop applications; the last two are primarily browser services. The difference that matters is where the document is processed.

With a browser service, the file leaves your machine. KillerPDF's README states document processing stays on your computer, with no telemetry, and the OCR is bundled Tesseract rather than a cloud call. For a scanned contract, a medical record, or anything under a data-handling policy, that distinction is the whole decision. It is also the reason a browser tool can offer features a local one cannot easily match, such as heavy server-side conversion. KillerPDF does not try to compete there.

Against PDFgear and PDF24 Creator, the split is different. Those are also local Windows tools, so the privacy argument does not separate them. What separates KillerPDF in the README is the engine: a separately versioned .NET library for PDF 2.0, PDF/A and PDF/UA with its own tests and conformance corpus, plus a documented headless CLI with exit codes. A desktop tool that also ships a scriptable command line and a reusable library is a different kind of dependency than one that only ships a window. If you need to put PDF merging into a build pipeline, that is the axis to compare on, not the toolbar.

A reader searching for a KillerPDF review will find feature lists everywhere. The more useful question is whether the CLI and the engine are things you will actually use. If not, the desktop feature set is the comparison, and it is competitive but not unique.

Maintenance, upgrade cost and the licence in practice

The repository is not archived, and the last push was on 2026-09-22, the same day as the two most recent releases. That is a project being worked on right now, and the release cadence suggests fixes ship quickly rather than accumulating.

Upgrade cost is low by design. The standard installer supports per-user or machine-wide deployment, and the README notes that installed shortcuts launch the inner app directly for faster startup. Updates are manual-ish: the optional startup check contacts GitHub, and downloading and installing an update requires confirmation. For a managed fleet, that means either accepting the prompt or turning checks off in About and distributing new versions yourself via WinGet, Chocolatey or the release assets. The portable edition is the simplest path for machines where you do not control the runtime.

On the licence: GPL-3.0 applies to the application and, based on the repository layout, to the engine in the same monorepo. Using KillerPDF internally to edit documents is not redistribution. Shipping it inside a product, or linking the engine into your own software, is where the copyleft terms start to matter. The README's release notes confirm corresponding source is published per release as a zip. This is not legal advice; if your use case involves redistribution, get the licence reviewed.

The .NET 10 requirement is the other ongoing cost. Both the engine and the app target .NET 10, and the standard installer depends on the .NET 10 Desktop Runtime. That is a moving target as the runtime evolves, and it is the reason the portable edition exists.

Editorial conclusion

Adopt KillerPDF if you work on Windows 10 or 11, want annotation, OCR, forms and printing without a subscription, and value a headless mode you can script. Do not adopt it if you need macOS or Linux, or if you cannot accept the GPL-3.0 obligations that come with redistributing it. Before committing, verify two things: that your machine has the .NET 10 Desktop Runtime (or use the portable edition, which bundles it), and that your intended workflow is covered by the CLI flags listed under `KillerPDF.exe --help`, since the README documents no plugin API or scripting surface beyond those flags.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. SteveTheKiller/KillerPDF on GitHub