What left the browser during a production PDF merge?

"Runs in your browser" describes where document processing occurs. It does not mean a production web page makes no network requests. A page still needs its HTML, styles, scripts, fonts, and optional processing runtimes. This site also uses consent-aware Google Analytics to measure pages, performance, coarse tool outcomes, and acquisition channels.

A useful network review therefore needs two separate questions:

1. Which application and analytics requests were visible?
2. Did a captured request contain or upload the selected PDF?

This study asked both questions during one bounded production PDF merge. It did not try to certify every tool or promise that all browsers and environments behave identically.

Methodology and sample

The review ran on 16 August 2026 against the production static build served through Wrangler at http://127.0.0.1:8793. Analytics was enabled with the production GA4 measurement ID and regional consent mode. Fresh Headless Chromium pages opened:

• the local-processing explainer
• the Merge PDF workspace

The merge used two generated one-page PDFs. Neither fixture contained customer data or a real person's information. Their byte sizes and SHA-256 hashes are recorded in the dated evidence artifact.

The recorder retained request methods, origins, paths, resource types, query parameter names, request-body parameter names, and body byte counts. It removed parameter values before publication so analytics identifiers were not committed as evidence. Every recorded URL and request body was also checked for both fixture filenames.

The merge page selected both files, waited for validation, produced the combined result, and activated its blob-backed download link. Page and console errors were recorded for both routes.

The File API specification describes the browser primitives behind selected files and blob URLs. Google's Consent Mode documentation describes why analytics requests can still be part of the production page's network boundary.

Limits of this review

This evidence covers one Chromium build, one local Wrangler production artifact, two routes, two native-text fixtures, and one completed merge. It does not cover OCR data, AI models, peer-to-peer transfer, every PDF feature, browser extensions, operating-system telemetry, or traffic below the browser automation layer.

The committed raw log includes parameter names rather than parameter values. That is enough to review the kinds of metadata sent, but a reviewer who needs to inspect live values must repeat the procedure in their own environment.

No result below should be read as a certification that a document is safe to release or that every product workflow has the same network behavior.

Findings

The production pages made analytics requests

The local-processing page recorded 25 requests. The completed merge page recorded 29. Both contacted:

• www.googletagmanager.com to load the GA tag script
• www.google-analytics.com to collect analytics events

The analytics request keys covered page and consent context, browser/device capabilities, performance metrics, engagement, tool identity, coarse file-count/size categories, output format, duration, and download kind. The sanitized evidence does not publish the values.

This corrects an important misconception: a browser-local product can send measurement metadata while keeping the selected document out of those requests. "No document upload" is narrower and more accurate than "no external network request."

The merge fetched one same-origin runtime after selection

After the fixtures were selected, the browser requested the pinned PDFium WebAssembly runtime from the application origin:

/runtime/v1.0.0/packages/pdfium/2.15.0/pdfium.wasm

That request delivered application code used to inspect and merge the files. It was not a request carrying a source PDF to another host.

No captured request contained a fixture filename

The recorder searched every captured request URL and body for both generated fixture filenames. Neither name appeared. No page error was recorded.

The merge completed and exposed a blob-backed download. The captured traffic showed analytics metadata and the same-origin runtime, but no browser-visible external document-upload request and no external request created by the blob download.

That supports a narrow conclusion for this session: the production page made real external analytics requests, while the selected PDF bytes were not observed leaving through a browser request during the recorded merge.

How to reproduce or challenge the result

Start with:

• artifacts/seo/2026-08-16-browser-local-network-review.md
• artifacts/seo/2026-08-16-production-network-requests.json
• the two generated fixtures under artifacts/seo/fixtures/

Build the production artifact, serve it through Wrangler, use a fresh browser profile, retain all resource and Fetch/XHR requests, and keep initial load separate from the post-selection operation. Search URLs and request bodies for fixture names and unique canary values.

If a repeat capture shows a filename, canary value, document-sized external request body, new origin, or different analytics dimension, record the exact route, build, consent state, and action. Evidence earns trust when a narrower new result replaces an older broad claim.