How we audit local PDF processing (and what "no upload" actually proves)

Audit of local PDF processing and the implications of "no upload" claims

The audit process starts with a static source review of all 74 public tool pages and their associated scripts. The focus is on identifying any direct calls to upload data to a ToolVero document-processing server. By searching for four common browser data transmission methods—fetch(), XMLHttpRequest, WebSocket, and sendBeacon—no direct upload endpoints were found.

This finding forms the basis for the "Private browser processing" badge, which indicates that 42 out of the 74 file tools reviewed had no first-party upload paths. However, a static review has limitations. It does not examine third-party library internals, monitor runtime network traffic, or ensure that no network requests are made at all.

A page could still load libraries from CDNs, generate analytics, or serve ads, all of which involve network activity but do not involve uploading files to the ToolVero server.

A stronger approach involves designing the exfiltration process so that data is removed or made impossible to exfiltrate from the start. In the case of the Image Metadata Remover tool, the design ensures that sensitive data like EXIF information cannot be included in the output. The image is decoded, rasterized, and rebuilt into a fresh PNG that only retains essential data such as the signature and IHDR, IDAT, and IEND chunks.

This design eliminates the possibility of sensitive data being present in the output, making the audit focus on verifying the design rather than trusting the server's security. Another example is the Word-to-PDF converter, which was found to be inserting unsanitized HTML from a DOCX conversion library into the output. This was addressed by rebuilding only certain text, tables, and images, excluding scripts, event handlers, styles, and unsafe URL attributes.

The audit results should be transparently published, including any fixes implemented. In the Word-to-PDF converter case, the audit page noted that some advanced DOCX formatting was lost and that the tool was updated to remove potentially unsafe elements. However, the audit also highlights that there are still areas needing improvement, such as externally hosted library scripts, analytics, and advertising scripts, which remain unaddressed.

Furthermore, the audit emphasizes the importance of keeping different categories—privacy design, technical audit, third-party scans, and formal certification—separate. Each category has its own limitations and should not be confused with others. For builders, the recommended audit process involves searching for exfiltration points across all pages and scripts.

While a brute-force method like this can catch obvious issues, it is preferable to design clean-by-construction pipelines that ensure sensitive data cannot be exfiltrated even if the developers intended it to be.

The audit process is an ongoing commitment. If a tool transitions from local to server-side processing, the privacy explanation must adapt accordingly, reflecting the new risk profile. The audit behind "no upload" claims must be public, dated, and honest about its limitations. This transparency builds trust and ensures that the claims made about data handling are credible and verifiable. Ultimately, the strength of any "no upload" claim lies in the thoroughness and honesty of the audit process behind it.