Proof that splitting a PDF never uploads it

Measured: what the browser sent while splitting

The test file is a 20-page PDF (9,637 bytes) generated by the script, with unique content. Requests from both the page and the service worker were recorded. Among the recorded requests we counted methods with a body (POST/PUT) and searched every body for the file's raw bytes (the script first ran a positive control on a simulated upload body to confirm the matcher detects it). This covers HTTP requests only, not other channels such as WebSocket.

The only requests during splitting were GETs that download the program itself: the pdf.js worker used to read the page count (/pdf.worker.min.mjs) and one site script chunk (/_next/static/…). Each request is logged once for the page and once for the service worker, so counts come in pairs. Offline, the service worker's network attempt failed and it answered from its on-device cache; every page-side request succeeded. Environment: headless Chromium 151.0.7922.34, macOS 26.6.2 (Apple M4). Raw data and script: docs/evidence/split-no-upload-20261021/ in the repo.

It splits with the network off

After the split page loaded, we switched the browser offline and split the same file again: "Extract pages 1-3" produced a 1,326-byte PDF and "One page per file" produced a ZIP with 20 PDFs. With no network, the file cannot have gone anywhere — the split happened on the device. The page and its assets need to have loaded online once first (the site's service worker caches them locally).

How the code splits

Splitting uses the open-source pdf-lib library: it reads your PDF into browser memory, copies the selected pages into a new document and saves it; "one page per file" builds each page and writes it into a ZIP one at a time. The page count is read with the open-source pdf.js. There is no code path in the split flow that sends the file to a server; the result is handed to you through a locally created download link.

What we deliberately don't claim

We don't claim "zero network requests": opening the page loads scripts, and the site uses Vercel Analytics for page-view stats, so in a real browser you may see such requests in DevTools — they don't carry your file. We also don't cite a Content-Security-Policy header as evidence: as of the verification date the site doesn't enforce one (only a non-blocking Report-Only policy was added later), and you could disprove that on the spot. We only state what can be checked.

Verify it yourself in two minutes

1. Open the splitter. Open MoGuan's Split PDF page in a desktop browser (Chrome, Edge or Firefox) and let it finish loading.
2. Open the Network panel. Press F12 (⌥⌘I on Mac), switch to Network, clear the log and tick Preserve log.
3. Split once as usual. Pick a PDF, choose Extract pages or One page per file, split and download.
4. Inspect the requests. Check the Method column: there is no POST/PUT carrying the file. Open any request's Payload tab — your file's contents aren't there.
5. Split again offline. Switch the throttling dropdown from No throttling to Offline (or turn off Wi-Fi) and split another PDF — it still works.

Scope and limits

• This evidence covers the split tool (and the same mechanism used by the other classic client-side tools). MoGuan's AI tools (smart split suggestions, summary, translation, Q&A, to Markdown, etc.) send locally extracted text to an AI endpoint and are outside this page's claim.
• Single-file limit: 50MB, or 100MB on desktop Chrome/Edge with File System Access (streams to disk). These come from the limits in the code, not from this test.
• Measured only in headless Chromium; Safari, Firefox and mobile browsers were not tested, nor were large files or split speed — so this page states no speed numbers.
• Offline use requires the page to have loaded online once.

FAQ