What Happens to Your Files When You Use Online Tools? The Truth

The Two Fundamentally Different Architectures

When you use an online file tool, one of two things is happening with your file, and understanding the difference is critical for making informed decisions about your data:

Architecture 1: Server-Side Processing (File Upload)

The majority of online file tools work this way:

1. You select a file on your device.
2. Your browser packages the file and sends it over the internet to the tool provider's web server.
3. Software running on the server (Python scripts, PHP functions, compiled C++ libraries) processes your file.
4. The processed file is written to the server's storage system.
5. The server generates a download URL for you.
6. You download the processed file.
7. The provider's systems (eventually) delete your file — according to their stated policy.

Between steps 2 and 7, your file exists on hardware you don't control, in a data center you've never visited, under the governance of laws in whatever country that server is physically located in.

Architecture 2: Client-Side Processing (Browser-Based)

Modern browser technology — specifically WebAssembly, the Canvas API, the Web Crypto API, and JavaScript libraries like pdf-lib, JSZip, and Sharp — enables the same file processing tasks to run entirely within your web browser:

1. You select a file on your device.
2. Your browser reads the file into local memory (JavaScript ArrayBuffer).
3. A JavaScript library running in your browser tab processes the file.
4. The result is generated in browser memory and offered as a download.
5. Your file never leaves your device.

This is not a marketing claim — it is a verifiable technical reality. You can confirm it by disconnecting from the internet after the page loads and attempting to use the tool. If it still works, the processing is happening locally.

What "We Delete Your Files After 1 Hour" Actually Means

Virtually every server-based online tool claims to delete your files within a short window (1 hour, 24 hours, "immediately after processing"). It's important to understand what this actually guarantees — and what it doesn't:

• ✅ The tool provider is claiming to run an automated deletion job on their primary storage.
• ❌ It does not mean your file was never written to backup systems, which may have longer retention schedules.
• ❌ It does not mean server access logs (which record filename, file size, IP address, and timestamp) are also deleted.
• ❌ It does not mean your file wasn't indexed by the provider's internal search or analytics systems before deletion.
• ❌ It does not mean the deletion has been audited, verified, or is enforceable if disputed.

The Network Request Test

Anyone can verify whether a file tool uploads your files using their browser's built-in developer tools:

1. Open the tool page in your browser.
2. Press F12 to open Developer Tools.
3. Click the "Network" tab.
4. Clear the network log.
5. Upload a small test file and start processing.
6. Watch the Network tab — if you see a large POST or PUT request being made while processing, your file is being uploaded to a server. If you see no outgoing data requests, it's client-side.

Flixfer's Architecture

At Flixfer, we built client-side first. The overwhelming majority of our tools — including all PDF tools, image processing tools, and developer utilities — run 100% in your browser using open-source JavaScript libraries. You can verify this with the network request test above.

For tools where server-side processing is technically unavoidable (certain file format conversions requiring native binaries), we are explicit about this in the tool description, use HTTPS for all transfers, process immediately, and delete files within minutes. We do not use file contents for any secondary purpose.

Our commitment is not just a privacy policy — it's a technical architecture decision that makes data exposure structurally impossible for most of our tools.