Security Policy

ZeroDataUpload

Last Updated: April 3, 2026
Effective Date: January 10, 2025

Why This Page Exists

I'm Milan Salvi, the founder of Leena Software Solutions and the person behind ZeroDataUpload. I built this platform because I was tired of uploading personal files to random websites and hoping for the best. So I made a simple decision early on: your files never leave your browser. That single choice shaped everything about how we handle security.

This page explains, in plain language, what that actually means and how we keep things safe. No marketing fluff — just the real technical picture.

Data Controller: Leena Software Solutions
Security Contact: Milan Salvi — leenasoftwaresolutions@gmail.com
Address: Satyam APT, B-104, Plot - 65, Sai Section, Hutatma Chowk Ambernath East, Maharashtra, India. PIN - 421501

How Client-Side Processing Actually Works

Every tool on ZeroDataUpload — the PDF converter, the image watermarker, the base64 encoder, all of them — runs entirely inside your web browser using client-side JavaScript and browser APIs like the File API, Canvas API, and Web Workers.

What does that mean in practice? When you drop a file into one of our tools, it gets read into your browser's memory using FileReader. The processing happens right there on your machine. The finished result is generated locally and offered as a download. At no point does the file travel to any server. We literally have nowhere to store it — ZeroDataUpload is a static site hosted on Cloudflare Pages with no backend, no database, and no server-side code.

Here is what we do not have:

No file upload endpoints. There is no API waiting to receive your data.
No temporary file storage or caching layer.
No server-side processing queue or worker pool.
No metadata logging from files you open in our tools.

When you close the browser tab, the data is gone. There is nothing to breach because we never had the data in the first place. That is the core idea behind "zero data upload" — it is not just a brand name, it describes the architecture.

HTTPS, TLS, and Encryption in Transit

All traffic to and from zerodataupload.com is encrypted with TLS 1.2 or higher. This is enforced at the Cloudflare edge, meaning even if someone tried to visit via plain HTTP, they would get redirected to HTTPS automatically.

We also use HSTS (HTTP Strict Transport Security) headers, which tell your browser to only connect to us over HTTPS going forward. Once your browser sees that header, it will refuse to load our site over an unencrypted connection. This protects against downgrade attacks and SSL stripping.

Our TLS certificates are issued and managed through Cloudflare, so they are always current and properly configured with strong cipher suites.

Our Cloudflare Infrastructure

Hosting and Network Protection

ZeroDataUpload is deployed on Cloudflare Pages — a static site hosting platform that serves files from Cloudflare's global edge network. Because we are a static site with no origin server to attack, the threat surface is inherently small. But we still layer on protections:

DDoS mitigation is always on. Cloudflare absorbs volumetric attacks before they reach our content.
Web Application Firewall (WAF) rules filter out malicious requests. We have custom WAF rules configured to block known attack patterns.
Bot management helps reduce automated abuse and scraping.
Rate limiting prevents individual IPs from flooding our pages with requests.

Third-Party Services We Use

We try to keep external dependencies minimal, but we do use two Google services:

Google Analytics 4 (GA4) helps us understand which tools people use and how they find us. It collects anonymized, aggregated usage data. We have data retention limits configured, and we do not tie analytics data to individual identities. GA4 runs under Google's data processing terms and their own security infrastructure.

Google AdSense serves ads on our pages to help keep the platform free. Google handles the ad delivery, targeting, and fraud detection on their end. We do not pass any user file data to AdSense — remember, we do not have any user file data to pass.

What We Actually Collect (and What We Do Not)

Let me be specific about the data picture. We do not collect file contents, file names, file metadata, or anything about what you process using our tools. That data stays in your browser.

What we do collect through GA4 is standard web analytics: page views, referral sources, approximate geographic region, device type, and browser version. Cookies on our site fall into two buckets: functional cookies (like your dark/light theme preference, stored in localStorage) and third-party cookies from Google Analytics and AdSense.

We use a cookie consent mechanism so you can choose what to allow. Sensitive cookies carry the Secure and SameSite attributes to prevent them from leaking across origins or being sent over unencrypted connections.

The short version: Your files never touch our servers. We have no file storage, no file caching, no file backup system, and no mechanism to inspect or log file contents. The processing happens in your browser's JavaScript runtime and stays there.

Frontend and JavaScript Security

Since our entire product is client-side code, keeping that code secure is critical. Here is what that looks like day to day:

We validate and sanitize inputs before processing. When tools generate output — say, rendering HTML for a preview — we encode that output to prevent cross-site scripting (XSS). Our Content Security Policy headers restrict which scripts can execute and which domains can serve resources, so even if an attacker managed to inject something, the browser would refuse to run it.

For JavaScript specifically:

External scripts use Subresource Integrity (SRI) hashes so the browser can verify they have not been tampered with.
Variables are properly scoped to avoid leaking data between operations.
We clean up memory after processing — file data stored in ArrayBuffers and Blobs gets dereferenced so the garbage collector can reclaim it.
Error handlers are written to avoid exposing internal details. If something goes wrong, you see a user-friendly message, not a stack trace full of implementation specifics.
We periodically review our code for common vulnerability patterns: prototype pollution, DOM-based XSS, insecure postMessage usage, and similar issues.
We self-host Tailwind CSS (our main styling framework) rather than pulling it from a CDN, reducing external script dependencies.

If Something Goes Wrong

Incident Response

Even with a static site architecture, things can happen. A dependency could have a vulnerability. A Cloudflare configuration could be misconfigured. Someone could find a way to abuse one of our tools. We take those possibilities seriously.

If we detect a security issue — through monitoring, user reports, or third-party alerts — we act fast. Within the first 24 hours, the goal is to contain the problem, figure out the scope, and document what happened. If the issue affects users (which is unlikely given our no-data architecture, but not impossible), we notify affected parties within 72 hours and report to relevant authorities as required by GDPR, DPDPA, and other applicable laws.

After an incident is resolved, we do a post-mortem to understand what happened and what we can change so it does not happen again.

A Note About Breach Risk

Because we do not store user files or personal data beyond basic analytics, a traditional "data breach" in the sense of leaked user files is not really possible with our architecture. The most sensitive data we hold is aggregated analytics information managed by Google. That said, we still plan for worst-case scenarios because overconfidence is its own vulnerability.

Finding and Fixing Vulnerabilities

We regularly review the site for security issues. This includes checking our HTML, CSS, and JavaScript for known vulnerability patterns, keeping our few dependencies up to date, and testing browser compatibility to make sure security features work across Chrome, Firefox, Safari, and Edge.

When browser vendors release security updates that affect web APIs we use (like the File API or Canvas API), we test our tools to make sure they still work correctly and securely under the new behavior. We also watch for CVEs in any libraries we depend on and update or patch promptly.

Tips for Using ZeroDataUpload Safely

Our tools are designed to be safe out of the box, but here are a few things that will help on your end:

Keep your browser updated. We rely on modern browser security features, and outdated browsers may not enforce them properly.
Be cautious on shared or public computers. While we do not store files server-side, processed data does live in browser memory until the tab is closed. Close the tab when you are done.
Use a secure network. Our site is HTTPS-only, but processing sensitive documents on an open public Wi-Fi network is still worth thinking twice about.
Only process files you have the legal right to modify or convert.

If anything on the site looks off — unexpected behavior, a weird redirect, something that does not seem right — please let us know. You might catch something we missed.

Reporting a Security Issue

If you find a vulnerability or have a security concern, email us at leenasoftwaresolutions@gmail.com with "SECURITY" in the subject line.

A helpful report includes:

What you found and why you think it is a security issue
Steps to reproduce the problem, if possible
Your contact info so we can follow up
Screenshots or logs if you have them

We will acknowledge your report within 24 hours and keep you updated on our progress. After investigating, we will share what we found and what we did about it. We appreciate responsible disclosure and treat every report seriously, even if it turns out to be a false alarm.

Legal Compliance

We operate under the privacy laws that apply to our users, including the GDPR (for visitors from the European Union), CCPA/CPRA (for California residents), and India's DPDPA. In practice, our client-side-only architecture makes compliance simpler — most data protection headaches come from storing and processing personal data on servers, which we do not do.

That said, we still maintain proper documentation, conduct periodic self-assessments, and update this policy when regulations change or we modify our practices. Milan Salvi oversees security and compliance as both the founder and the person responsible for making sure we follow through on what we say here.

Keeping This Policy Current

Security is not a checkbox we tick once and forget about. We review this policy regularly and update it when our infrastructure changes, when we add new tools, or when we learn about new threats. If we make significant changes, the "Last Updated" date at the top of this page will reflect that.

Have questions about anything on this page? Want more detail about a specific practice? Send us an email at leenasoftwaresolutions@gmail.com and we will be happy to explain further.

Last Review Date: April 3, 2026
Next Review Date: October 3, 2026
Policy Version: 2.0