Excellent question! The answer is simple: we're known on the market, and trusted by our customer for this secure handling of PDFs. Should we decide to change that (unbeknownst to them), we would effectively kill our reputation and the company by extension.

> Is it possible to download as an app and disable internet (not sure if it's a feature of any browsers).

Back in the days, SimplePDF used to work offline. However maintaining that in conjunction with our paid customers features (where the online connectivity is mandatory) was too big of a maintenance burden. We decided a year ago to drop this support (silently), and no one has complained since then, confirming our hunch that it is not a high-demand feature.

It’s the 31st of May

On "what are we trying to solve":

Forms (PDFs, scanned paper) are still everywhere and aren't going away. SimplePDF Copilot exists to make the transition less painful. A few concrete use cases:

- Pre-filling repetitive forms from existing data sources (CRM, EHR, etc. via MCP/RAG). In most industries, employees fill forms by copy-pasting or retyping. With AI + tool calling, most of the form arrives pre-filled and the employee just corrects or adds the missing bits.

- Filling foreign-language forms. If you've moved to a new country, or know someone who has, you've had to fill out forms in a language you don't master.

- Understanding a contract before signing it. "Can I actually trust all the clauses here?" Reading proficiency changed the world by giving people a way to understand what they were signing. This extends it to legalese and odd clauses.

On Claude Cowork:

Different shape, and a different privacy model. Cowork drives a sandboxed virtual desktop: you can't see exactly what it's doing while it fills, and correcting a wrong value means another back-and-forth with the LLM.

Copilot works inside your editor: every change is visible as it happens, you can amend any field with one click, and the document never leaves your browser + it's LLM agnostic: bring your own (local or hosted).

Preview was an inspiration when I started SimplePDF, my goal was to make the "Preview" of the web, so that people without a Mac would benefit from a software matching Preview in ease of use and overall polish.

Adobe Acrobat: SimplePDF has "Simple" in the name as the philosophy is to keep it simple (both in ease of use, and features): I don't intend to support everything that Adobe Acrobat does. There's a lot of features that I could build that I intentionally do not, as they would bloat the UI and hard the overall usability. Most people have very simple needs and don't need advanced features (like scripting, etc).

- A privacy-focused PDF editor, free for individuals, used by 200k users monthly: https://simplepdf.com/editor

- The same editor, embeddable into one’s app for companies, with the same privacy guarantees (everything happens in the browser) + the resulting PDF is stored in their own storage (« bring your own storage »).

The majority of our paid customers are in healthcare where privacy is non-negotiable. Co-pilot extends that to the AI world (« bring your own AI »)

What are you using the PDF editor for?

In the video I let the chat fill my name, then have it skip the second field (business), then fill LLC, it makes a mistake and I correct it

I tried with various: "Skip it", "None, leave blank", "Skip this field" and all worked for me, but if may very well be missing something very obvious?

It supports AcroForms (like in the example) but not XFA.

Why are you asking? gov forms support?

Anything you see missing in Copilot to achieve that?

Not sure if you noticed, but there's an arch-diagram in the info popup [1].

[1] https://copilot.simplepdf.com/?share=a7d00ad073c75a75d493228...

But you're right that it's not as evident as I wanted to, I'm making a small copy update to make it clearer: "Public demo. Your chat messages leave your device and are sent to the selected AI provider. Use sample data only."

(Since there's support for local models, the popup is only displayed when NOT using your own model)

Thanks!

EDIT: the copy update is live, thanks again!

Use cases range from:

- Filling foreign-language forms

- Navigating a contract before signing: "can I trust ALL the clauses here?"

- Pre-filling repetitive forms from existing data sources (CRM, EHR, etc. via MCP/RAG)

Copilot is designed to be embedded; our customers ship it white-labeled inside their own products.

I built SimplePDF Copilot: an AI assistant that can interact with the PDF editor. It fills fields, answers questions, focuses on a specific field, adds fields, deletes pages, and so on.

It's built on top of SimplePDF that I started 7 years ago, pioneering privacy-respecting client-side pdf editing, now used monthly by 200k+ people.

As for the privacy model: the PDF itself never leaves the browser. Parsing, rendering, and field detection all run client-side.

The text the model needs (and your messages) goes to whatever LLM you point at. By default that's our demo proxy (DeepSeek V4 Flash, rate-capped), but you can BYOK and point it at any cloud provider, or go fully local (I've been testing with LM Studio).

Unlike the existing "Chat with PDF" tools that only retrieve the text/OCR layer, Copilot can act on the PDF: filling fields, adding fields (detected client-side using CommonForms by Joe Barrow [1], jbarrow on HN with some post-processing heuristics I added on top), focusing on fields, deleting pages, and so on.

I built this because SimplePDF is mostly used by healthcare customers where document privacy is paramount, and I wanted an AI experience that didn't require shipping PII to a third party. Stack is pretty standard:

- Tanstack Start

- AI SDK from Vercel

- Tailwind (I personally prefer CSS modules, I'm old-school but the goal since I open source it, I figured that Tailwind would be a better fit)

The more interesting part is the client-side tool calling: events are passed back and forth via iframe postMessage.

If you're not familiar with "tool calling" and "client-side tool calling", a quick primer:

Tool calling is what LLMs use to take actions. When Claude runs grep or ls, or hits an MCP server, those are tool calls.

Client-side tool calling means the intent to call a tool comes from the LLM, but the execution happens in the browser.

That matters for: speed, you can't go faster than client-to-client operations and also gives you the ability to limit the data you expose to the LLM. For the demo I do feed the content of the document to the LLM, but that connection could be severed as simply as removing the tool that exposes the content data.

The demo is fully open source, available on Github [2] and the demo is the same as the link of this post [3]

What's not open source is SimplePDF itself (loaded as the iframe).

I could talk on and on about this, let me know if you have any questions, anything goes!

[1] https://github.com/jbarrow/commonforms

[2] https://github.com/SimplePDF/simplepdf-embed/tree/main/copil...

[3] https://copilot.simplepdf.com/?share=a7d00ad073c75a75d493228...

Comments URL: https://news.ycombinator.com/item?id=47984675

Points: 60

# Comments: 29

Use cases range from:

- Filling foreign-language forms

- Navigating a contract before signing: "can I trust ALL the clauses here?"

- Pre-filling repetitive forms from existing data sources (CRM, EHR, etc. via MCP/RAG)

Copilot is designed to be embedded; our customers ship it white-labeled inside their own products.

I built SimplePDF Copilot: an AI assistant that can interact with the PDF editor. It fills fields, answers questions, focuses on a specific field, adds fields, deletes pages, and so on.

It's built on top of SimplePDF that I started 7 years ago, pioneering privacy-respecting client-side pdf editing, now used monthly by 200k+ people.

As for the privacy model: the PDF itself never leaves the browser. Parsing, rendering, and field detection all run client-side.

The text the model needs (and your messages) goes to whatever LLM you point at. By default that's our demo proxy (DeepSeek V4 Flash, rate-capped), but you can BYOK and point it at any cloud provider, or go fully local (I've been testing with LM Studio).

Unlike the existing "Chat with PDF" tools that only retrieve the text/OCR layer, Copilot can act on the PDF: filling fields, adding fields (detected client-side using CommonForms by Joe Barrow [1], jbarrow on HN with some post-processing heuristics I added on top), focusing on fields, deleting pages, and so on.

I built this because SimplePDF is mostly used by healthcare customers where document privacy is paramount, and I wanted an AI experience that didn't require shipping PII to a third party. Stack is pretty standard:

- Tanstack Start

- AI SDK from Vercel

- Tailwind (I personally prefer CSS modules, I'm old-school but the goal since I open source it, I figured that Tailwind would be a better fit)

The more interesting part is the client-side tool calling: events are passed back and forth via iframe postMessage.

If you're not familiar with "tool calling" and "client-side tool calling", a quick primer:

Tool calling is what LLMs use to take actions. When Claude runs grep or ls, or hits an MCP server, those are tool calls.

Client-side tool calling means the intent to call a tool comes from the LLM, but the execution happens in the browser.

That matters for: speed, you can't go faster than client-to-client operations and also gives you the ability to limit the data you expose to the LLM. For the demo I do feed the content of the document to the LLM, but that connection could be severed as simply as removing the tool that exposes the content data.

The demo is fully open source, available on Github [2] and the demo is the same as the link of this post [3]

What's not open source is SimplePDF itself (loaded as the iframe).

I could talk on and on about this, let me know if you have any questions, anything goes!

[1] https://github.com/jbarrow/commonforms

[2] https://github.com/SimplePDF/simplepdf-embed/tree/main/copil...

[3] https://copilot.simplepdf.com/?share=a7d00ad073c75a75d493228...

Comments URL: https://news.ycombinator.com/item?id=47947347

Points: 7

# Comments: 1

Anyone who has achieved “distribution” knows. Anyone else is just lacking experience.

Answering like you did is akin to gatekeeping. The world is better with more builders. We should encourage anyone who wants to give it a shot

Now I know what would have happened if I had accepted.

SIM-based solutions on their way out is a non-issue. For eSIM to support that use case, political will only is needed: the EU got Apple to abandon the lightning cable, this is not any different.

Instead they could have mandated the use of eIDAS 1 to all countries + extend it with attribute/credential support, and let countries choose their implementation (cards, SIM, server-side).

Instead we’re back to the drawing board with the big shortcomings highlighted in this thread.