What local PDF processing protects—and what it does not

Keeping a document in your browser can avoid sending it to a conversion server. That is a useful privacy property, but it is important to understand the boundary between local document work and ordinary website activity.

Separate the document from the application

When you visit a browser-based tool, your device downloads a page, scripts and other assets. A local-processing tool then opens the file you choose using browser APIs and performs its supported operations on your device. A server-processing tool sends the document to a remote system to perform the work there. Both can present a similar-looking file picker, so the button’s wording does not establish the architecture.

In SandboxPDF, the processing code works with locally selected files. The document’s bytes, extracted text, passwords and certificate material are not submitted to a processing API. A download is generated from the result held in browser memory. The website host supplies software and assets; it does not receive a document library containing your chosen PDFs.

This arrangement reduces one important exposure: transferring document contents to a separate processing service. It does not mean that visiting the website creates no network traffic. Your browser still needs to fetch the application, and optional engines or models may require additional downloads. Privacy explanations should identify those requests instead of pretending that a web application never communicates over a network.

What a model download reveals

OCR and language features may require trained model files. Downloading a model is different from uploading the text on which it will run. The provider of the model file can receive ordinary request information, such as an IP address, browser headers and the requested asset. The document itself need not be included in those requests.

SandboxPDF uses downloadable local models for supported recognition and language tasks. The interface should tell you when initialization is necessary and when a large download is starting. The model can then process supported inputs within the tab. This distinction matters particularly on a mobile connection: “local AI” describes where inference happens, not whether the first use consumes data.

If your organisation prohibits contact with particular external domains, even a model download may need approval. Follow that organisation’s network and software rules. A local-processing claim does not grant permission to bypass a corporate policy, and a browser tool cannot determine whether your chosen workflow is approved for a particular document classification.

Your device remains part of the trust boundary

Local processing cannot protect a document from someone who controls your device, a malicious browser extension with broad access or an untrusted operating-system account. Screen recording, clipboard history, cloud backup and downloaded-file indexing can all affect where information is accessible. These are separate from whether the PDF tool uploads the document.

Use a browser and operating system that receive security updates. Review extension permissions, especially on a device used for confidential work. Avoid processing sensitive files on a public or shared computer unless your organisation provides an appropriate environment. If you copy text from a summary, remember that the clipboard may be visible to other applications or synchronised according to your device settings.

The download folder also matters. A result saved into a cloud-synchronised folder may later be uploaded by that synchronisation service, even though the PDF tool never uploaded it. Choose the destination intentionally. Local processing describes the application’s handling; it does not override the behaviour of every other program on the machine.

Browser memory and storage have different roles

An open workspace uses memory for selected files, previews, intermediate representations and results. Closing or refreshing the tab releases the application’s references to those objects. That is different from a promise of forensic erasure from physical memory or operating-system swap. General browser software cannot make that broad guarantee.

Preferences and model caches can survive between visits. A saved theme is not a saved PDF, and a cached language model is not your chat history. It is useful to distinguish these categories when reviewing browser storage. Clearing the site’s storage may reset settings and cause models to download again without deleting copies that you deliberately saved elsewhere.

Private browsing changes some storage behaviour but does not make the device or network invisible. It may also prevent large models from being retained. If a feature fails to reuse a previous download, check browser storage limits and mode before assuming the document was sent to a server. Storage eviction is a normal constraint of browser applications.

Offline use requires a specific test

“Works offline” can mean several things. An already initialized model may continue processing without a connection, while a fresh tab still needs application files. A cached engine might be available, but a newly selected language may need a separate model download. An app can therefore support a narrow offline workflow without being a fully installable offline application.

For SandboxPDF document chat, initialize the optional model online and keep that tab open before relying on offline inference. Check the feature’s current instructions. Do not assume that closing the browser, restarting the computer or clearing storage will preserve a ready session. Model assets may be cached, but the application still has to initialize them.

If offline operation is essential, test the exact sequence using a non-sensitive sample: load the page, initialize the relevant feature, disconnect, process the sample and save the result. Then test whether a restart changes the outcome. A successful demonstration of one already-open session is not proof that every tool and language works after a cold start.

Contact forms are intentionally different

A support message must leave your browser to reach the operator. A privacy-respecting application should make that difference explicit. The contact form is a communication feature, not part of the local document-processing pipeline. The message and contact details you enter are sent through the configured delivery service and stored by the recipient’s inbox provider.

Do not paste confidential document text, passwords or private certificate keys into a bug report. Describe the tool, browser, approximate file size, page type and observed behaviour first. A small synthetic sample that reproduces a problem is often more useful than a complete confidential file, but only share a sample when you understand the destination and are authorised to do so.

SandboxPDF’s contact form does not automatically attach files open in the workspace. That separation helps prevent accidental disclosure. Nevertheless, anything you type into the message field is information you are choosing to transmit, so review it before sending.

How to evaluate a privacy claim sensibly

Read the policy and the feature-specific explanation. Look for a clear distinction between document contents, operational requests, optional model downloads, local storage and support correspondence. Broad phrases such as “100% secure” are less useful than a concrete explanation of the data flow and its limits.

For a technical check, a browser’s network panel can help reveal requests during a sample operation. Use a harmless test document and examine request destinations and payloads. This is informative, but it is not a complete security audit: browser internals, extensions and future software updates complicate the picture. The purpose is to verify a stated behaviour, not to infer universal safety from one quiet-looking request list.

If you are making an organisational decision, combine technical observation with policy, maintenance practices and the sensitivity of the files. Some work may require an approved desktop application, a managed device or a formal assessment. Local browser processing can be a good fit without being the answer to every confidentiality requirement.

A practical workflow for sensitive paperwork

Start with a trusted device and a separate original. Open the specific tool, review its limitations and initialize any necessary engine using a harmless sample if possible. Process only the pages needed for the task. Keep the browser responsive by avoiding several heavy conversions at once, particularly on a phone or a machine with limited memory.

Inspect the exported file and choose a suitable storage location. If sharing is intended, remove sensitive visible content and review hidden information as separate steps. Send the verified copy through an approved channel. Close the workspace when finished and clear site storage if your device policy requires it, remembering that this does not remove your downloaded files.

The useful promise is specific: supported document processing happens on your device, reducing the need to send the document to a remote processing service. Pair that architecture with careful device use, output verification and sensible sharing practices. Read the privacy policy for the current data categories, and metadata guide before preparing a public copy.

For shared devices, also consider what happens after processing. A downloaded file may appear in a recent-files list, a cloud-synchronised folder or a device backup even though the website never uploaded it. Check the destination before saving confidential material. If someone else uses the same browser profile, saved preferences and cached application resources may remain visible to them. Closing a tab is useful housekeeping, but it is not equivalent to securely erasing every copy created elsewhere on the device. Follow the storage and disposal rules that apply to your work.