"We never see your files" is easy to say
Every online PDF tool says something reassuring on its homepage. Most of them upload your document to a server, process it there, and delete it afterwards, which is a perfectly normal way to build software. The awkward part is that from the outside, a site that deletes your file an hour later and a site that doesn't look identical. You get a promise and a privacy policy, and no way to tell the difference.
PDkef processes PDFs in your browser without a PDF processing backend. The source is on GitHub so you can inspect how files are handled. Site usage analytics are separate from PDF processing; running locally does not mean the site makes no requests.
Check local processing with the network switched off
An offline test checks whether a task can finish without a processing server. First make sure the tool and its required fonts and assets are available locally. This test alone does not prove that software never queues data to send later; that needs a separate review of its code and network behavior.
- 1Open any tool here and let the page finish loading.
- 2Turn off your wifi, or open developer tools and set the Network tab to Offline. Then put the phone in airplane mode, if that's easier.
- 3Load a PDF, edit it, and download the result. Merge some files, sign a form, delete a paragraph. All of it still works.
Nothing about that is a trick of caching. The PDF is read, edited and written by your own browser, using your device's processor, and the finished file is handed back to you locally. There is no round trip to interrupt, which is also why you can install it and use it on a plane.
The site's Content Security Policy uses connect-src 'self' to restrict scripted connections to this site's origin. Same-origin requests are still allowed, so this is a safeguard, not proof that uploads are impossible. Keeping PDF contents out of network requests remains a requirement for the code itself.
What's underneath, and how to run your own
The heavy lifting comes from open source projects that were here long before this one. pdf.js reads and renders PDFs, pdf-lib writes them, Astro and Preact build the interface, and signature_pad handles the drawing surface. Every one uses a reviewed permissive license and makes no network calls of its own, which is a hard requirement here rather than a nice-to-have: a single dependency phoning home would undo the whole premise. The complete list with license texts is on the open source licenses page.
Running your own copy is genuinely simple, because there's nothing to run: clone the repository, build it, and serve the resulting folder from any static host, or straight off your own machine. No backend, no database, no keys to configure. If your workplace would rather this lived on an internal server than on someone else's domain, that's a completely reasonable thing to want, and the license says yes.