How to Verify Local Screenshot-to-PDF Processing in Browser DevTools

“Processed locally” should be testable. A privacy statement is useful, but a browser tool can also expose observable evidence: which network requests occur, what request payloads contain, when optional analytics loads, and whether an uploaded image ever leaves the browser.

This guide documents the current Screenshot PDF 0.0.13 architecture and provides a reproducible DevTools procedure. It is not a formal penetration test, and an empty network panel cannot prove that all future versions will behave the same. Record the version and repeat the check after material changes.

What local processing means here

In the editor, the browser reads the selected image with FileReader, decodes it into an image element, draws pixels into Canvas, creates annotation snapshots as local object URLs, and generates PDF data with jsPDF. Screenshot contents, annotation pixels, watermark text, previews, and generated PDF bytes are not sent to a Screenshot PDF application server.

The website itself still requires normal infrastructure requests for HTML, JavaScript, styles, fonts or images. Cloudflare can process connection metadata such as IP address and request headers. Optional Google Analytics is a separate path and only loads after analytics consent. Local document processing does not mean the page makes zero network requests.

Prepare a non-sensitive test file

Do not begin a privacy test with a bank statement or private conversation. Create a synthetic PNG containing a colored grid, a unique phrase, and a known dimension such as 1200 × 3000 pixels. The unique phrase helps you search DevTools payloads without exposing real information.

Record a hash of the test file if your operating system provides one. A hash can help distinguish the exact test input, although it does not by itself prove where the file was processed.

Open DevTools before selecting the file

1. Open the Screenshot PDF editor in a fresh tab.
2. Open Chrome DevTools and select Network.
3. Enable Preserve log and disable cache for the test session.
4. Clear existing requests.
5. Leave optional analytics disabled in Privacy Choices for the first pass.
6. Upload the synthetic image, add a visible annotation and watermark, preview pages, and export a PDF.

Chrome's Network panel documentation explains request inspection, filtering, and payload views.

Inspect requests by type and payload

Filter for fetch and xhr, then inspect any request that occurs during upload, annotation, preview, or export. Check URL, method, request headers, query string, form data, request payload, and response.

Search the preserved log for the synthetic phrase and file name. Also look for unusually large request bodies whose timing matches the upload. Image pixels might be binary or encoded, so absence of the phrase alone is insufficient; payload size and content type also matter.

Static image requests from the blog or interface are not uploads of the user's document. A blob: URL is a browser-local object reference, not a remote network destination. A data: URL embeds data in the current document context and likewise does not represent an HTTP upload.

Compare consent states

Repeat the session after granting optional analytics consent. The Google Analytics library may now load and send usage events. Screenshot PDF's analytics layer records product events such as editor opening, export start, success or failure, page count, locale, and broad usage context. It is designed not to include screenshot contents, file names, watermark text, email addresses, or direct identifiers.

Inspect event parameters rather than assuming an analytics request is harmless. Confirm the synthetic phrase and file name are absent. Advertising consent remains disabled during the AdSense application stage, so ad requests should not appear merely because analytics was accepted.

Verify failure paths

Privacy behavior should not change when an operation fails. Try a small unsupported file or cancel the file picker. Confirm no document payload is transmitted as part of error reporting. Do not intentionally crash the browser with enormous sensitive files.

For a memory-related test, use a generated pattern and increase dimensions gradually. Stop when the editor scales the image or the browser becomes slow. The purpose is to observe request behavior, not to exhaust the device.

What DevTools cannot prove alone

• Browser extensions and service workers can have separate execution contexts; inspect the relevant extension service worker when testing capture transport.
• Encrypted requests still expose destination and request metadata in DevTools, but payload interpretation may require the request view.
• A single test covers one version, browser, consent state, and workflow.
• Browser extensions installed from other publishers can observe pages according to their own permissions.
• Operating-system telemetry is outside the scope of a webpage Network panel.

For a higher-assurance review, inspect source code, build artifacts, extension permissions, Content Security Policy, and network behavior together.

Record the audit result

Create a small table containing date, website build, extension version, browser version, consent state, test-file hash, actions performed, observed destinations, document-payload result, and reviewer. Save a redacted HAR only if it contains no tokens, cookies, private URLs, or other sensitive headers.

If document pixels or file data appear in an unexpected remote request, stop and reproduce with the smallest synthetic example. Report the destination, request type, action that triggered it, and version to [email protected].

Local processing is strongest when the claim, implementation, consent behavior, and observable network evidence agree. Repeating this check after releases turns a marketing phrase into a maintainable engineering property.