WebAssembly PDF processing in your browser
Every tool on this site is a program that runs on your computer. The website only delivers it. Here is exactly what that means.
The architecture, end to end
The dashed line is the boundary your file never crosses.
YOUR DEVICE (browser tab) | NETWORK
|
[ your file ] --> ArrayBuffer in memory |
| |
v |
+---------------------------+ |
| WebAssembly + JS engine | | page assets
| (pdf-lib / PDF.js) | <--+-- downloaded once
+---------------------------+ |
| |
Web Worker thread |
| |
v |
[ result Blob ] --> download |
|
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Your file stops here. Nothing above is ever sent right.What happens when you press the button
1. The file is read, not sent
Choosing a file gives the page a File handle. Reading it produces an ArrayBuffer in the tab's memory. No network request is involved, and none is possible without explicit code to make one.
2. The engine runs in the tab
The PDF engine is ordinary compiled code delivered with the page — JavaScript plus WebAssembly modules for the heavy parsing and rasterising. WebAssembly executes at near-native speed inside the same sandbox.
3. Work moves off the main thread
Rendering and re-encoding run in a Web Worker so the interface stays responsive and progress can be reported honestly, page by page.
4. The result is handed back
The finished bytes become a Blob, and the browser saves it through a normal download. The original and the result are both discarded when you close the tab.
Why WebAssembly matters here
Parsing a PDF, decompressing its content streams and rasterising a page are computation-heavy jobs written years ago in low-level languages. WebAssembly is a portable binary instruction format that lets that kind of code run in a browser at close to native speed, inside the same sandbox as the rest of the page.
That is the change that made server-side processing unnecessary for this class of task. A decade ago a browser was too slow to rasterise a 300 DPI page; today the limiting factor is your device's memory, not its speed.
- pdf-lib
Reads and writes PDF structure: merging, splitting, rotating, removing pages, embedding images and applying AES-256 encryption.
- PDF.js
Mozilla's renderer, WebAssembly-accelerated, used for page thumbnails, PDF-to-image export and the re-render step in compression.
- Canvas & createImageBitmap
The browser's own image pipeline handles decoding, scaling, cropping and re-encoding to JPEG, PNG or WebP.
- Web Workers
Background threads that keep long jobs from freezing the page.
Client-side versus server-side processing
Client-side (this site)
- The file stays in your device's memory
- No upload time, even for large documents
- Works offline once the page has loaded
- Nothing to retain, log or breach
- Speed and size limited by your hardware
Server-side (typical converter)
- The file is copied to a machine you do not control
- Upload and download time on every job
- Requires a connection throughout
- Retention depends on a written policy
- Can use far more memory than a phone has
Server processing is not useless — it wins on very large jobs and on formats that need heavyweight software. It just should not be the default for splitting a ten-page contract.
Verify it yourself
Open your browser's developer tools, switch to the Network tab, and run any tool. You will see the page's own assets load, and no request carrying your file. For a stricter test, load a tool page, disconnect from the internet, and process a document anyway.