Local PDF processing means the document work happens inside the browser instead of on a remote document server. The user opens a tool page, chooses a PDF from the device, the browser reads the file, and the PDF engine runs locally. The output is created locally and downloaded from the browser.
That is different from the common upload-processing model:
- You choose a file.
- The browser sends the file to a server.
- The server performs the PDF operation.
- The browser downloads the result.
Upload-based tools can be useful and legitimate. They can run heavy compute, centralize collaboration, and handle workflows that are hard to do on a phone. The trade is that your file leaves your device, and what happens to it next is up to the service.
Lemmafour’s local-only tools use a different boundary. The browser downloads the application assets, including JavaScript and WebAssembly. Then the selected document bytes are processed by the browser and local workers. The PDF file is not uploaded for the document-processing operation.
What WebAssembly has to do with PDFs
WebAssembly is the browser’s way of running fast, compiled code — the same kind of engine code a desktop app would use, delivered as part of a web page. That matters for PDFs because real PDF work is low-level: parsing the file format, rewriting objects, rendering pages, producing byte-exact output. JavaScript runs the interface; the WebAssembly engine does the document work, on your machine.
The user experience looks ordinary: open the page, choose a file, click a tool action. The architecture behind that experience is the important part. The file input gives the page access to the selected local file in the browser session. The PDF engine reads those bytes locally, performs the requested operation, and returns new PDF bytes for download.
This does not mean the site itself works without the internet on a first visit. The page, its scripts, fonts, and the engine all have to load like any website. The honest claim is narrower — and stronger for being narrow: once you choose a PDF, its bytes are not sent to a server for processing.
This distinction also keeps troubleshooting honest. If a browser extension, font request, or cached application file appears in the Network tab, that is not automatically a document transfer. The question to ask is narrower: after file selection, did the page send the selected PDF bytes, or a request body derived from them, to a server for the operation?
What still lives in browser storage
Some local workflows keep working files in the browser’s own storage so a refresh does not destroy your session. That storage lives on your device, in your browser profile. It is useful for recovery, but it is still storage. On a shared, managed, or untrusted device, clear your files and outputs when you finish.
Browsers give websites several kinds of on-device storage — localStorage, IndexedDB, origin-private file storage. The practical rule is simple: this storage keeps your work off remote servers, but it is still storage, on a device you control. Traces of your work can remain until you clear them.
For sensitive files, use a disciplined finish:
- Download the final PDF.
- Reopen the final PDF in a second viewer.
- Confirm the content, page count, and visible result.
- Clear the workspace or recent outputs when finished.
- Keep the original file separate from the edited output.
What the Network tab can prove
Every browser ships a Network tab (in its developer tools) that lists every request the page makes. It answers to the browser, not to us — which makes it the perfect independent check for a local-only PDF tool.
The proof is not “there are zero network requests.” There will be network requests when the app loads. The proof is narrower: after choosing a file, the PDF-processing workflow should not create a request carrying the document bytes to a server.
Lemmafour exposes that idea in the Local - 0 sent control on local-only tool pages. The panel counts outgoing request bodies after file selection and explains the scope. For a stronger manual check, load the tool page first, open DevTools Network, choose a small test PDF, run the operation, and watch for document-sized request payloads. You can also load the page, disconnect the network, and then choose and process a file. First-time app loading still needs the network; the processing operation should not.
Where PDF details make local processing harder
PDF is not a simple picture-of-a-page format. One file can contain text, images, vector artwork, embedded fonts, annotations, form fields, page boxes, metadata, and layered revisions of itself. The formal specification (ISO 32000) runs to roughly a thousand pages — and that complexity is exactly why different tools have different limits.
That complexity explains why different tools have different limits:
Text editing is only direct when the PDF contains editable text objects the engine can interpret. Scanned text is usually an image, so changing it requires OCR or visible overlay techniques. Lemmafour does not claim OCR.
Redaction must remove content. Drawing a white rectangle over text is visual cover, not secure removal. Lemmafour’s Redact tool is distinct from whiteout because sensitive content removal must not silently leave extractable text underneath.
Crop changes visible page boundaries. It should not be treated as redaction because content outside the crop area can remain in the file.
Compression may be lossy or structural depending on the file. Some PDFs are already compact and will not shrink meaningfully. Compression is also not metadata removal.
Signatures in Lemmafour are visual signatures. They are drawn, typed, or image-based page content, not cryptographic certificate signatures.
The security claim and the line it should not cross
Local processing is valuable because it reduces exposure: the document does not need to be transmitted to a server for processing. That is the claim.
It is not the same as a regulated compliance, certification, or encryption claim — those require separate evidence and operating controls. Lemmafour’s trust model is simpler: don’t transmit the document at all, make that boundary visible, and let you check it yourself.
That precision is more credible than a dramatic privacy promise. A local PDF tool should say exactly what happens, exactly what does not happen, and where your responsibility picks up again: your device’s security, your browser’s storage, the downloaded file, and whatever channel you use to send the finished document onward.
When local processing is the better fit
Local PDF processing is strongest for private one-person tasks: merge a contract packet, redact a payslip, fill a form, rotate scanned pages, add a visual signature, compress a file, or export images from a PDF. These tasks are usually bounded, fast enough for a browser, and do not require collaboration.
Upload-based tools can still be the better fit for heavy OCR, team workflows, automated server-side pipelines, very large files, or enterprise audit trails. Architecture is a tradeoff, not a morality test.
For Lemmafour, the product choice is to keep shipped PDF tools local, free to use, and account-free. That makes the privacy story small enough to verify: load the app, choose a PDF, watch the network, and inspect the output.
Sources for background concepts: MDN WebAssembly, MDN Web Storage API, Chrome DevTools Network panel, and PDF Association ISO 32000.