A local alternative to ChatPDF

"Chat with your PDF": the question is where

ChatPDF and the wave of tools it inspired made document Q&A feel effortless: drag a file in, ask a question, get an answer. The experience is genuinely useful and it works. The point isn't that these tools are bad. The point is what has to happen for them to work: your file leaves your computer.

The moment you drop a PDF into ChatPDF, or any similar service, it travels across the internet to a server you don't own, gets processed, gets indexed, and sits in someone else's infrastructure until it's deleted (whenever that is, under whatever terms you agreed to). For a restaurant menu or a product brochure, the risk is near zero. For a legal brief, a medical record, an investor presentation, or a personnel file, uploading to an uncontrolled third-party server is not a privacy-policy question. It's an architecture question.

Privacy by policy vs. privacy by architecture

Every cloud tool in this space has a privacy policy. Most of them are sincere. None of them are structural guarantees.

A privacy policy is a legal instrument. It tells you what the company intends to do with your data. It doesn't prevent a data breach. It doesn't block a government access request served under the US CLOUD Act. It doesn't stop a policy change six months from now. It is a promise, not a technical constraint, and promises change when companies get acquired, pivot, run out of money, or comply with law-enforcement demands.

Privacy by architecture is different. If your document never leaves your machine, there is nothing for a privacy policy to promise about, because there is nothing to govern. The data didn't travel. There is no server-side copy. The exposure is zero, not "low." That's the real meaning of running AI on your documents offline: the question of what the vendor does with your data becomes literally unanswerable, because the vendor never has it.

How to chat with a PDF without an upload

The local path sounds harder than it is. The missing piece was never really the model. It was the format that makes a PDF queryable.

PDFs are hard to read programmatically. They are layout-for-print files, not structured knowledge. Before you can ask a model questions about a PDF, the text needs to be extracted, chunked, and organised with enough context that the model can find the right passage and cite the right source. That's the real work, and it's exactly what pdf2okf does.

pdf2okf converts a PDF into an OKF-compatible knowledge bundle following Google's Open Knowledge Format, published in June 2026. The result is a set of Markdown files with frontmatter: each chunk carries its source document, section heading, and page reference. Everything stays on your disk.

From there, querying is straightforward. A local model (Ollama, llama.cpp, oMLX on Apple Silicon, or any OpenAI-compatible server) reads the bundle and answers your question with a reference to the original source. No upload required. No third party involved. The answer cites exactly where in the document it came from, because the frontmatter makes that information available at every step of the pipeline.

What this changes for sensitive documents

The architecture argument matters most for documents that can't be safely uploaded anywhere:

• Legal documents: draft contracts, M&A due-diligence files, litigation materials. Confidentiality obligations don't have a cloud-service carve-out.
• Medical records: patient data under GDPR Article 9 is special-category. Processing it through a cloud upload requires an explicit lawful basis that most organisations won't have.
• Financial documents: earnings models, acquisition targets, internal projections. Material non-public information has its own rules in every jurisdiction.
• HR files: salary bands, performance reviews, personnel notes. In Germany, often subject to works-council or collective-agreement restrictions.

For all of these, the relevant question isn't "does this service have a good privacy policy?" It's "does this service receive the data at all?" With a local OKF workflow, the answer is no.

The honest tradeoff

Local inference takes setup. You need a machine with enough RAM (a 7-billion-parameter model at 4-bit quantization fits comfortably in 8 GB) plus a way to run models locally and the pdf2okf CLI to prepare the bundle. It is not as instant as a browser tab. The conversion step is work.

What it gives you in return is something a browser tab cannot: the document stays on your machine, full stop. Not "stays in the EU." Not "is processed under our DPA." On your machine. That's a different category of protection, one that holds up when the policy promises are tested.

pdf2okf is in private build: join the waitlist if you want early access to the CLI and the OKF bundle format. If you're evaluating local document AI for a team or regulated workflow, that's exactly the use case it's built for.