Sign X PDF · Guides
How browser-based PDF tools work
Browser PDF tools can edit files without posting your document to an application server. After the site’s scripts and assets load, the selected PDF is read with browser file APIs and processed with client-side libraries (and sometimes WebAssembly) inside your tab. Sign X PDF is built on that model for sign, merge, compress, reorder, and delete-page workflows.
Descriptions reflect Sign X PDF’s intended browser architecture. Features and network behaviour should be verified on the live site for your threat model.
Local processing vs “no network at all”
Local document processing means the PDF bytes you choose are not uploaded to Sign X PDF servers for conversion or storage as part of the tool workflow. It does not mean the browser never uses the network.
Like any website, HTML, JavaScript, fonts, images, and WASM binaries still download when you open the app. After a warm load, editing runs from those already-fetched assets plus your local file.
What happens when you open a PDF
You pick a file with the browser file picker or drag-and-drop. The page receives a File (or Blob) reference and reads it into memory (for example as an ArrayBuffer). Rendering and edits operate on that in-memory copy in the page or a worker—not on a server-side copy of your document.
- Input: browser File / Blob APIs
- Preview: PDF rendering in the client (pdf.js-style pipeline)
- Edits: client libraries rewrite or reassemble PDF structure
- Output: download a new file to your device
Libraries and roles in Sign X PDF
Sign X PDF splits heavy engines so crawlers and first paint do not need the full PDF runtime. Tool pages are prerendered HTML shells; the interactive editor loads as a client island when you use the tool.
- pdf.js — page rendering / preview in the browser
- pdf-lib — many assemble and export operations in JavaScript
- QPDF (WebAssembly) — selected password and structure-preserving operations via a worker
- Signature pad / image tools — create visible signature artwork before placement
Workers and WebAssembly
Some work runs in Web Workers so the UI thread stays responsive. QPDF is compiled to WebAssembly and loaded as an asset; it executes in the browser process after download, not as a remote PDF service.
Because WASM and worker scripts are ordinary static assets, they appear in Network panels as site resources. That is expected and different from uploading your confidential PDF to an API endpoint.
How you can check the privacy claim
Open browser developer tools, watch the Network panel while you open and export a uniquely named test PDF, and confirm the document is not posted to Sign X PDF application endpoints. Sign X PDF maintains automated privacy checks that fail closed on suspicious request patterns (including certain beacon, WebSocket, and service-worker traffic cases in test harnesses).
Third-party browser extensions, OS services, or future features could still change network behaviour outside this app’s control—always re-check if your threat model is strict.
Practical limits
Client-side processing is bounded by device memory and CPU. Very large scans, many simultaneous files, or low-memory phones may be slow or fail. Password-protected PDFs may need the open password before merge or edit. Compression quality depends on content (image-heavy PDFs behave differently from text PDFs).
How we verified this
Privacy network e2e (Playwright)
Result: No PDF document bytes observed on application upload endpoints during sign/merge export fixtures
Scope: Automated fixture PDFs in CI/local browser suite
Limits: Does not prove every browser extension or OS behaviour; does not cover third-party ad frames in isolation
Source: tests/e2e/privacy-no-upload.mjs
Architecture / client islands
Result: PDF engines load as client islands after SSR shells; homepage does not preload pdf.worker or QPDF WASM
Scope: Build-time inventory and code-splitting regression tests
Limits: Inventory measures build artefacts, not every runtime path
Source: tests/build/performance-phase2.test.ts
FAQ
Do browser PDF tools upload my file?
Some do. Sign X PDF is designed so selected PDFs are processed in the browser and not uploaded to Sign X PDF servers for tool processing. Always verify claims in Network tools for any site you use with confidential documents.
Why do I still see network requests?
Site assets (HTML, JS, fonts, WASM) load over the network. Local processing refers to your document bytes, not to zero network traffic for the website itself.
What is WebAssembly doing here?
QPDF is shipped as WebAssembly so advanced PDF operations can run on-device after the binary downloads. It is not a remote conversion server.
Is this the same as offline mode?
Not automatically. Offline use requires the browser to already have the app assets cached and a product path that has been verified after a warm load. Do not assume airplane mode works until you have tested it on your device.