How SnackPDF is tested

Last verified: 31 August 2026 · Test material: synthetic PDFs only

SnackPDF says that supported PDF jobs run in your browser. That claim is narrower than “the website makes no network requests”: the application still has to be delivered, and managed hosting can handle ordinary request information. The tested claim is that SnackPDF application code does not send the selected document, its name, password, extracted text, metadata or hash away for processing.

Processing boundary

A selected PDF is read into memory in the current tab and transferred to a dedicated browser Worker. The Worker loads the processing program from SnackPDF's own origin and uses an in-memory virtual filesystem. Inputs and outputs are cleared after completion, cancellation or reset; the saved result is offered through the browser's normal download behaviour.

The release checks reject document telemetry APIs, upload forms, persistent document storage and third-party runtime requests. The site's security policy also restricts connections and Workers to the same origin.

Network and storage inspection

The browser suite uses synthetic fixtures containing unique markers for a filename, visible text, metadata, password and document hash. It records browser requests and instruments fetch, XMLHttpRequest, WebSocket, EventSource, sendBeacon and form submission while every advertised operation completes.

The same run inspects localStorage, IndexedDB and every Cache Storage response. A release fails if a marker or fixture byte sequence appears in a request, URL, console record or persistent browser store. Cache Storage is allowed to contain the application itself, but never a selected or finished document.

Determinism and output checks

Each shipped transformation is run three times against known fixtures. The tests compare output names and SHA-256 hashes, reopen PDF results, count their pages and confirm the requested order. Split is checked for one reopenable PDF per page; text extraction is checked against both stored text and an image-only fixture that must truthfully produce an empty result.

Fidelity fixtures contain colour, vector shapes, text and mixed page boxes. Compression profiles are checked against fixed rendered-difference limits. The grayscale check renders the output and verifies effectively equal red, green and blue channels. These checks support the stated behaviour, but they do not prove that every interactive PDF structure is preserved.

Offline, browser and accessibility gates

The Service Worker treats the complete application as one version. Every route, script, style and local processing asset must be cached before “Ready for offline use” appears. Browser tests then disconnect the network, reopen the routes and process a fixture locally.

The release matrix covers Chromium, Firefox and WebKit, plus phone-sized Chromium and WebKit runs. It checks one H1 per route, visible focus, the skip link, keyboard page ordering, touch-sized controls, narrow layouts, deterministic downloads and the complete offline workflow.

Known limits

• The processing WebAssembly file is 15,533,045 bytes before transfer compression, so the first complete offline installation is much larger than the visible page.
• Large files, many pages and 300-DPI images can exceed practical browser memory. SnackPDF estimates memory and stops rather than knowingly starting an unsafe job.
• Synthetic fixtures cannot represent every valid or malformed PDF. Keep the original and inspect every important output.
• Browser extensions, the operating system and hosting infrastructure sit outside SnackPDF application code and its document-processing tests.

Reproduce the checks

1. Use a synthetic or otherwise non-sensitive PDF and open the browser's Network panel before selecting it.
2. Complete the intended operation and confirm that document markers do not appear in requests.
3. Inspect localStorage, IndexedDB and Cache Storage; only application files should persist.
4. Wait for the offline-ready message, disconnect, reopen a tool and process the fixture again.
5. Download the corresponding source, verify its checksum and run the documented release suite for the exact implementation.

Licence materials and source traceability are listed on Source and licences. You can also follow the practical local-processing verification guide, read the privacy boundary and review offline preparation. Results on this page are updated only when the described release checks are run again.