The Honest Open Source PDF Editor Survey for 2026

Search "open source PDF editor" and you get a wall of listicles that mash together three completely different things: free software, software with public source, and software that does not phone home. Same query, three answers. Pick the wrong one and you end up installing Docker to open a tax form.

This is the survey I wish existed before I went down that hole.

Quick answer

Match your actual intent to one of these before you install anything:

• Free as in beer — you don't want to pay, and you don't care who can read the source. A cloud tool's free tier gets you there fastest; see the free-as-in-beer math in the Sejda alternative if you keep hitting a task cap.
• Free as in freedom — you want auditable code, no telemetry, a license that lets you modify and redistribute. Stirling-PDF is the real answer: MIT-licensed core, about 50 tools, actively maintained. Run it yourself.
• Files never leave your machine — you care about where the document goes, not who can read the code. Self-host Stirling-PDF on the device itself, or use a browser-local tool like OxygenPDF's edit-pdf that never uploads the file. Source availability and data flow are separate questions.

The rest of this piece is the detail, the caveats, and the license history behind each of those three answers.

One query, three intents

People typing "open source PDF editor" usually want one of these:

• Free as in beer. "I refuse to pay Adobe $20 a month." Source code visibility is irrelevant. They want gratis.
• Free as in freedom. Auditable code, no telemetry, modifiable, redistributable. License matters. GPL, AGPL, MIT.
• Self-hosted or offline. "My documents do not leave my machine." This is about data flow, not source visibility.

These overlap, but they are not the same thing. Master PDF Editor 4 was free-as-in-beer on Linux and proprietary. Stirling-PDF is real FOSS, but if you point your browser at a friend's hosted instance, your PDFs travel through their server. Worth keeping straight before you commit to an installer.

Stirling-PDF, the heavyweight

Stirling-PDF is the closest thing the FOSS world has to an Acrobat replacement. About 92,700 GitHub stars as of September 2026 — it crossed 78,000 back in the spring, and star counts only move in one direction, so treat whatever number you see as a floor, not a ceiling. Java/Spring backend, TypeScript frontend. Roughly 50 tools covering edit, merge, split, OCR, redact, sign, convert.

It runs as a desktop app, a self-hosted server, or a Docker container. Most people meet it through Docker, which is the wall. The project's own quick-start is one line:

docker run -p 8080:8080 docker.stirlingpdf.com/stirlingtools/stirling-pdf

If Docker Desktop is already on your machine, that pulls the image and serves the UI at localhost:8080. If it isn't, you're now installing Docker Desktop first, which is the actual barrier — Stirling-PDF's own setup is genuinely one command. If you already run a homelab, Stirling-PDF is fantastic. If you don't, "install Docker" is a non-trivial afternoon for someone who wanted to fix a typo on a lease.

One more thing worth flagging. The project shifted to an open-core model. Some enterprise features (SSO, multi-tenant admin, some workflow automation) sit behind a commercial license. The base toolkit is still MIT, but "fully FOSS" needs that caveat now.

PDFsam Basic, the page-level utility

PDFsam Basic has been open source since 2006. AGPL-3.0, written in Java. Honest about what it does: split, merge, mix, rotate, extract. That is the whole list. No text edits, no image insertion, no annotation.

Two things to know. The free Basic version pushes upgrade prompts toward the paid Enhanced and Visual editions. And calling it a "PDF editor" is a stretch. It's a page-level utility. Use it for splitting and merging. Pair it with something else when you need to touch content.

LibreOffice Draw, the surprising part-time editor

LibreOffice Draw can open a PDF and let you edit it. In theory. In practice, missing fonts get rendered as boxes or substituted poorly, line wrapping breaks, text drifts past margins on export. The upstream bug report has been open long enough to qualify as a feature.

It's fine for filling forms or fixing a typo on a PDF you generated yourself, where the fonts are predictable. Painful for editing PDFs from third parties, which is the case most people actually have.

Inkscape, Xournal++, Okular: purpose-built tools

Inkscape treats a PDF page as a vector canvas. It imports one page at a time. A multi-page extension exists, and it is unreliable. The Poppler/Cairo importer turns text into uneditable paths. Useful for touching up a logo or a single-page diagram. Not a document editor.

Xournal++ is built for handwritten annotation. You import a PDF as a notebook background and write on top with a stylus. Highlights, shapes, text boxes, stamps. Markup, not modification. Erase your annotation and the underlying PDF is unchanged. Excellent at what it does, which isn't what most people mean by "edit."

Okular is the KDE viewer. It supports native PDF annotations and digital signatures. Cross-platform on Linux, macOS, Windows. Also a viewer, not a content editor.

Command-line tools: qpdf, pdftk-java, and mutool

Everything above assumes you want a window with buttons in it. If you're comfortable in a terminal, or you need to batch-process a folder of PDFs without opening a GUI for each one, the FOSS command-line stack is arguably more mature than the desktop-app stack.

• qpdf — Apache-2.0, around 5,400 GitHub stars as of September 2026. It bills itself accurately as a "content-preserving PDF document transformer": decrypts, re-encrypts, splits, merges, and linearizes PDFs without touching page content. Its own docs are explicit that it "does not render PDFs or perform text extraction" — structure only, by design.
• pdftk-java — GPL-2.0-or-later. This is the actively maintained fork of the original PDF Labs pdftk, which stalled once its bundled Java runtime and PDFBox dependency fell behind. One pdftk command handles merging, splitting, page rotation, form filling, and metadata edits.
• mutool, part of MuPDF from Artifex — AGPL-3.0, with a paid commercial license for anyone who can't comply with AGPL's terms (source disclosure on distribution). It renders, converts, and extracts text and images faster than most GUI tools, and its rendering engine sits inside several other FOSS PDF projects as a dependency.

None of these three "edit" a PDF the way a word processor does — there's no clicking into a paragraph and retyping a sentence. They edit PDF structure: pages, metadata, encryption, form fields. If your actual task is scriptable — strip permissions off 200 invoice PDFs, split a scanned book into per-chapter files — one of these three is faster and more reliable than driving a GUI 200 times by hand, open source or not.

Master PDF Editor, the asterisk

Master PDF Editor v4 was free for non-commercial use on Linux. Full editing, no watermark. Then v5 turned proprietary. Editing text, inserting images, and other tools watermark the output until you buy a license. It still gets recommended in old listicles. The rules changed.

What is actually missing

Most open source PDF tools are split-purpose. Stirling-PDF gets closest to a unified suite, and the typical install path is Docker. LibreOffice Draw is the only zero-friction option for non-form text edits, and its font handling is a known problem. Annotators don't change the underlying document. PDFsam doesn't touch content. Inkscape does one page at a time. The command-line trio edits structure, not content.

So if you want one tool that edits text, manages pages, fills forms, redacts, OCRs, and runs without a server you administer, there isn't a clean FOSS answer. That's the gap. Laid out by how much friction each option costs you before you've done anything useful:

Open source is not the same as private

This part deserves bluntness. Open source does not mean private if you don't control where it runs.

• Stirling-PDF on your laptop via Docker → private. Files stay on the machine.
• Stirling-PDF on a $5 VPS → your PDFs traverse and live on someone else's hardware. Code is auditable. Storage is not private.
• A "free PDF editor" web app whose source you have never read → you're trusting both the code and the operator.

If your concern is "my data should not leave my device," self-hosting on the device itself is the only configuration that delivers it. That's the same argument in more detail in why local-first PDF tools matter — the license question and the privacy question are just measuring different things, and conflating them is how people end up defending a choice on the wrong grounds.

Where browser-local fits

Honest disclosure first. OxygenPDF is not open source. The source isn't published. On the freedom axis, that's a fail.

On the data never leaves your machine axis, it qualifies. Files are read into browser memory and processed locally in the tab — OxygenPDF's edit-pdf tool runs on pdf-lib and pdfjs-dist, both JavaScript, entirely client-side. No upload, no account, nothing to phone home to. Verify it yourself. Open the browser's Network tab while you use it and watch it stay empty.

The same is true of the heavier jobs. OxygenPDF's OCR tool runs Tesseract compiled to WebAssembly in the tab, and Redact PDF rebuilds the page as an image so the removed text isn't sitting underneath a black box. Neither is open source either — but neither needs an install, a server, or an upload.

If your priority is auditable code, install Stirling-PDF. If your priority is "don't make me install Docker, just don't upload my PDF," browser-local is a closer match. Different answers for different definitions of the same word.

Side-by-side

FAQ

Is Stirling-PDF really free?

The base toolkit is, under an MIT license — merge, split, OCR, redact, convert, roughly 50 tools total, no cost. The project moved to an open-core model, so a handful of newer enterprise features (SSO, multi-tenant admin, some workflow automation) sit behind a paid tier. Running it as a Docker container or desktop app for your own document work won't hit that wall.

What's the most private open source PDF editor?

Depends what "private" means to you. If it means "auditable code," Stirling-PDF's source is public no matter how you run it. If it means "my file never leaves this device," the answer is the same tool, but only when you run it locally — Docker on your own laptop, not a hosted instance someone else administers. Point your browser at a friend's server instead and the code stays auditable while your file still travels through their hardware.

Can I edit a PDF without installing anything?

Yes, but not with a fully open-source tool today. Browser-local tools like OxygenPDF's edit-pdf process the file client-side with no upload, which solves the privacy half of the problem, but the source isn't published, so it fails the auditability half. Wanting both — nothing installed, code fully public — is a real request that nothing on this list satisfies yet; the closest you get is reading Stirling-PDF's source and then still needing Docker or a server to actually run it.

Is LibreOffice Draw good enough to edit a PDF?

For a PDF you generated yourself, with a standard font, yes — good enough to fill a form or fix a typo. For a PDF someone else made, with an embedded or unusual font, the odds of clean output drop fast: fonts get substituted, text reflows, margins shift on export. Treat it as a tool for your own documents, not other people's.

What happened to Master PDF Editor's free version?

Version 4 was free for non-commercial use on Linux, full editing, no watermark. Version 5 turned proprietary: the free build still opens and views files, but editing text, inserting images, and most other content tools now watermark the output until you buy a license. Old blog posts recommending it as a free option are describing v4, which isn't what you'd download today.

Do the command-line tools (qpdf, pdftk-java, mutool) count as PDF editors?

Not in the sense most people mean. They change structure — pages, metadata, encryption, permissions, form field values — not content. None of them let you click into a sentence and retype it. If your task is "batch-process a folder of PDFs the same way," they're the right tool and faster than any GUI. If your task is "edit the text on this one page," they're the wrong tool entirely.

Pick by intent, not by buzzword

The honest answer to "what is the best open source PDF editor?" depends entirely on which of those intents you actually have.

Want auditable code and you run a homelab? Install Stirling-PDF. The 50-tool toolkit is real and the project is active.

Want a unified tool that doesn't upload your file and doesn't require Docker? OxygenPDF's edit-pdf tool works right in your browser, with the honest caveat that the source isn't public.

Want to merge a PDF and stop thinking about it? Neither label matters. Use whatever's in front of you and works.

The label is a proxy for what you actually care about. Skip the proxy.