What "client-side" means

Your browser is the client. A web app that works client-side downloads its program code to your browser, and that code does the work on your computer: it reads your file from disk, changes it in memory, and hands you a new file to save. The server's job is to deliver the program, not to process your documents.

The alternative is server-side processing: the page sends your file to the company's servers, the work happens there, and a result comes back. Many online converters and editors work this way. It isn't wrong, but it means a copy of your file exists somewhere you don't control, for however long the service keeps it.

Modern browsers make client-side document tools practical. JavaScript and WebAssembly are fast enough to render PDFs, recognise text in scans and encrypt files, and browser APIs let a page read a file you choose and save a new one without either passing through a server.

Why a claim is worth checking

"No upload" can be true in a narrow sense and still leave gaps. A tool might process your file locally but send analytics that include file names or page counts. It might load fonts or scripts from other companies, each of which learns your IP address and which page you're on. Or one feature might quietly use a server while the rest don't. None of these are exotic, and all of them can be seen from your own browser.

Check 1: watch the Network tab

Every browser has developer tools with a Network panel that records each request the page makes. In Chrome, Edge and Firefox, press F12 (Cmd+Option+I on a Mac). In Safari, turn on the Develop menu in Settings, then Advanced, first.

  1. Open the developer tools and select the Network panel before you load the app.
  2. Turn on "Preserve log" (Chrome) or "Persist Logs" (Firefox), so requests aren't cleared when the page changes.
  3. Load the app, then clear the list so you only see what happens next.
  4. Open a file and do the work: edit, convert, redact, encrypt, save.
  5. Look at every request that appears during those steps.

What to look for:

  • The domain of each request. Anything that isn't the site you're on deserves a second look.
  • Upload size. Enable the size columns. A request that sends roughly as many bytes as your file is a strong hint the file itself went out.
  • Request type. The Fetch/XHR and WS (WebSocket) filters show the requests scripts make. Click one and open its Payload tab to see what was sent.

Its limits: it only covers the time you had the panel open, and you have to be able to tell a harmless request (a font, a program file) from a harmful one. It also can't show anything sent later, which is why check 3 matters.

Check 2: read the Content-Security-Policy

A Content-Security-Policy (CSP) is a set of rules a site gives your browser, which the browser then enforces on the page. It arrives as an HTTP response header or a <meta> tag in the page. The rule that matters for uploads is connect-src, which controls where scripts may connect using fetch, XMLHttpRequest, WebSocket and EventSource.

To read it, click the page's own document request at the top of the Network panel and look under Response Headers for content-security-policy, or view the page source and search for it.

  • connect-src 'self' means scripts may only connect back to the same site. A connection to any other domain is refused by the browser before it's made, and shows up as an error in the console.
  • No CSP, or a connect-src listing many domains or a wildcard, means the page may talk to others.

Its limits: the policy is chosen by the site and can change with any update, so you're reading today's rules. 'self' still allows connections to the site's own server, so a CSP alone can't prove your file isn't sent there. That's what checks 1 and 3 are for.

Check 3: disconnect and keep working

The bluntest test is to take the network away. If a tool can open, edit and save your file with no connection at all, the processing can't be happening on a server.

  1. Load the app while you're online, and use each tool you plan to test once, so its code is downloaded.
  2. Disconnect: turn off Wi-Fi, or tick "Offline" in the Network panel's throttling menu, which cuts only that tab.
  3. Open a file and do the full job, through to saving the result.
  4. Reconnect with the Network panel open and see whether anything is sent once you're back online.

Its limits: an app could hold data and send it later, which is why step 4 matters. And an app can fail offline for innocent reasons, such as a tool whose code hasn't been downloaded yet.

What these checks show for Vault Studio Pro

Here's what you should find if you run them on our app, including the parts that aren't absolute.

The policy

Every page, including the app, carries a CSP whose key rules are:

connect-src 'self' data: blob:
img-src 'self' data: blob:
form-action 'none'

So scripts can only connect to vaultstudiopro.com (plus in-memory data: and blob:URLs, which never leave the browser), a document can't load a tracking image from elsewhere, and the pages can't submit forms. Fonts, the PDF engine's data files and the OCR engine with its English language data are served from our own domain, and there are no analytics, advertising or tracking scripts.

The requests you'll see

Apart from the app's own files, the app contacts our server in exactly two situations, both about licences, not documents: claiming a licence key after checkout, and refreshing a subscription key near the end of a billing period. The security page lists what each one sends. One feature is outside the page's control: Docs dictation uses your browser's speech recognition, which in Chrome sends audio to Google and in Safari to Apple. The app asks before it starts.

The Privacy Audit panel

The app includes a Privacy Audit panel that shows the browser's record of the page's requests, collected with the Resource Timing API, including those made before you opened it, and lists anything the CSP blocked. It also shows how many projects are stored in this browser.

Its limit, stated plainly: it lists the page's own requests, not those made by background workers, such as the PDF and OCR workers. Those workers run under their own restrictive policy, but for a complete picture use your browser's Network panel, which is the independent check anyway.

The offline test

The app keeps a copy of itself after your first visit, so it reopens without a connection. Tools you haven't used yet, and the OCR and PDF data, are only stored once you choose "Make available offline" in the Privacy Audit panel, which downloads about 20 MB into this browser. After that, disconnecting and using any tool is a fair test.

What isn't protected

Projects autosaved in the browser are not encrypted at rest. Anyone who can use your browser profile can open them. For files at rest, use an encrypted .vault; see our guide to encrypting a document.

What no check can prove

  • You trust the code each time it loads. Any web app can change with its next update. The checks above tell you what the app does today, which is why they're worth repeating now and then.
  • Your own computer. Browser extensions with access to all sites, and malware, can read what's on the page regardless of the site's policy.
  • What you do with the result. Saving a file into a synced folder, or emailing it, is outside any web app's control.

Client-side processing removes a whole category of risk: a copy of your file on someone else's server. The checks let you confirm that for yourself. Editing is free, and Pro plans are there if you need more.

Try it

Open the PDF editor with your browser's developer tools already open, load a file and watch the Network tab. Then open the Privacy Audit from the start screen or the command palette. The security page documents every request the app makes to our server, and the redaction and File Safe pages explain what happens to your files in each tool.

Open the app and run the checksSee plans and pricing

Sources

  1. Inspect network activity. Chrome DevTools documentation
  2. Content-Security-Policy (CSP) header. MDN Web Docs
  3. Content-Security-Policy: connect-src directive. MDN Web Docs
  4. Resource timing. MDN Web Docs