Security & File Privacy Architecture

How client-side sandboxing and in-browser execution protect your documents from remote server exposure.

The Fundamental Vulnerability of Cloud PDF Tools

Most online PDF services follow a client-server architecture: you upload your document across the internet, their remote backend server saves your file to disk, runs an automated script (such as Ghostscript or poppler), generates the result, and gives you a download URL. This architecture introduces numerous privacy and security vulnerabilities:

  • Data Interception: Documents travel across multiple network routing hops.
  • Server Storage Risks: Even when services claim to "delete files after 1 hour," files reside on shared disks, backup snapshots, or temporary server directories.
  • Cloud Breach Exposure: Centralized databases of user documents present an attractive target for automated scraping or unauthorized administrative access.

The ANU PDFLAB Architecture: Pure Local Execution

ANU PDFLAB, published by Anu Tool, was architected from the ground up to eliminate these risks entirely. Instead of uploading your documents to a server, our platform delivers the processing code directly to your browser:

Workflow Stage Traditional Cloud Tool ANU PDFLAB (Client-Side)
File Selection POST request transmits entire binary file across the internet. JavaScript FileReader reads file strictly into local browser RAM.
Document Processing Executed on cloud servers in remote data centers. Executed on your device CPU via WebAssembly and JavaScript.
Result Delivery Downloaded from remote cloud storage URL. Created locally as a browser blob: URL and saved to disk.
Data Retention Stored on remote disks until server deletion cron fires. Zero Server Presence. Memory cleared immediately upon tab closure.

Browser Sandboxing & Memory Management

Modern web browsers (such as Chrome, Firefox, Safari, and Edge) isolate each tab within a secure operating-system level sandbox. JavaScript executing inside a tab cannot access other applications, scan your file system, or persist data without explicit user interaction.

In ANU PDFLAB:

  • Explicit Memory Allocation: Documents exist as transient ArrayBuffer objects in JavaScript heap memory.
  • Immediate Resource Cleanup: When you click "Reset" or process a new document, previous binary allocations are explicitly set to null and temporary object URLs (URL.revokeObjectURL) are revoked, triggering immediate garbage collection.
  • No Content Logging: Neither file names, byte contents, nor page counts are transmitted to external analytics or server loggers.

Verifying Local Processing Yourself

You do not need to take our word for it—modern browser tools make it easy to independently verify our zero-server architecture:

  1. Open your browser Developer Tools (press F12 or Ctrl+Shift+I / Cmd+Option+I).
  2. Navigate to the Network tab.
  3. Select and merge, split, or compress a PDF document on ANU PDFLAB.
  4. Observe the Network activity: you will see that zero outbound HTTP POST requests containing your file data are made during document processing.
  5. You can even disconnect your internet connection (or turn on Airplane mode) after loading the tool page, and all five tools will continue to process your files flawlessly!

Conclusion

By moving the computational burden from centralized servers into user web browsers, ANU PDFLAB provides document convenience without compromising digital sovereignty. For more details on our technical practices, consult our Browser Privacy Guide or email contact@pdflab.in.