Sign X PDF · Guides
How to check whether a PDF website uploads your file
Use a harmless PDF with a unique filename and marker, then watch the browser Network panel while opening, editing, and exporting it. Inspect fetch/XHR requests, request bodies, Beacon calls, WebSockets, and service-worker traffic. A clean check supports a scoped conclusion about the tested workflow; it does not prove what a compromised device or browser extension might do.
This is a practical testing method, not a security certification or legal opinion. Use a non-confidential fixture and define the threat model before relying on a result.
Verification scope: the owner-managed repository source and open-source components were reviewed on 2026-08-08. The linked GitHub repository currently requires access for anonymous visitors; it is a source reference, not a public-audit guarantee. The test files used for browser checks stayed on the test device and were not uploaded to Sign X PDF application servers. This is scoped evidence, not a guarantee about a compromised device, browser extensions, OS services, or future code changes.
1. Create a traceable test document
Do not begin with a confidential document. Make a small test PDF containing a unique marker such as PDF-UPLOAD-CHECK-20260808-ALPHA, and give it a unique filename such as private-check-20260808-alpha.pdf. The marker makes it easier to spot document bytes if a request body is visible.
Use a file that is safe to expose during testing. The goal is to observe the request path, not to prove safety by risking a real customer document.
- Use a unique filename and a unique text marker.
- Keep the fixture small enough to inspect and repeat.
- Record the browser, URL, operation, and test time.
2. Watch the Network panel before opening the file
Open DevTools, select Network, enable Preserve log, and clear existing requests. Filter by Fetch/XHR first, then repeat with All, WS, and other relevant filters. Load the page and let ordinary HTML, JavaScript, fonts, images, and WebAssembly assets finish downloading before selecting the test PDF.
Asset requests are expected on a normal website. The question is whether the selected PDF bytes are sent to an application upload or conversion endpoint.
- Look for POST or PUT requests that begin after file selection.
- Inspect request payload, form-data, and multipart fields where DevTools exposes them.
- Check request URLs, not only response status codes.
- Repeat the check while exporting, because upload behaviour can be delayed until export.
3. Check more than fetch and XHR
A narrow Fetch/XHR filter can miss other browser delivery paths. Check Beacon requests, WebSocket frames, and service-worker activity where the product uses them. A service worker can mediate a request even when the page code does not make a direct fetch call.
The absence of a visible request is evidence for the observed browser session and workflow. It is not a proof that no other software on the device can read the file.
- Beacon: inspect calls made during save, navigation, or page exit.
- WebSockets: inspect frames for document markers or file names.
- Service workers: inspect registrations and worker-mediated network activity.
- Search visible request details for the unique filename and marker.
4. Repeat the operation and compare the trace
Run the same fixture through each relevant operation, such as sign, merge, compress, reorder, and delete. Repeat once with a second unique marker. Consistent traces are more useful than a single clean page load, especially when an application loads code lazily.
This is the same principle used by Sign X PDF’s automated privacy test: install deep request hooks, exercise the operation, and fail on suspicious document-upload patterns. The public test code shows the exact scope rather than asking you to trust a slogan.
- Test both opening and exporting.
- Test every operation whose privacy model matters to you.
- Save a redacted HAR or screenshots only if they do not contain confidential content.
What this check cannot prove
Browser Network inspection does not audit a compromised operating system, malware, a malicious extension, another application with file access, or a future deployment. It also cannot establish legal compliance or a provider’s retention policy when the provider’s server-side behaviour is outside the browser trace.
Treat the result as a scoped, repeatable observation. For a high-risk workflow, review the provider’s source, privacy policy, retention terms, and threat model as well.
How we verified this
Public privacy e2e test
Result: The test installs request, Beacon, WebSocket, and service-worker hooks before exercising five PDF workflows.
Scope: Repository Playwright fixtures and the configured application routes
Limits: It does not prove behaviour of other applications, malicious extensions, malware, or future deployments.
Source: tests/e2e/privacy-no-upload.mjs
Browser Network inspection method
Result: Unique filenames and markers provide repeatable signals for checking request URLs and bodies.
Scope: Manual investigation method described in this guide
Limits: DevTools visibility depends on browser and service-worker behaviour; absence of a request is not a universal guarantee.
Source: https://developer.chrome.com/docs/devtools/network/
FAQ
Does a green Network panel prove a PDF website is private?
No. It supports a conclusion about the tested browser session and workflow. It does not cover malware, browser extensions, the operating system, server retention, or future changes.
Why use a unique filename and marker?
A unique filename and text marker make it easier to identify document bytes in request URLs, payloads, multipart data, or WebSocket frames without using a confidential document.
Does Sign X PDF use this kind of check?
Yes. Its public Playwright privacy test exercises sign, merge, compress, reorder, and delete workflows and watches request, Beacon, WebSocket, and service-worker paths within the stated test scope.