Why We Built ZeroPNG Without a Backend Database

The State of Modern Web Apps

If you set out to build a SaaS or web utility today, the standard playbook is almost always the same: setup a Node.js or Python backend, attach a PostgreSQL database, configure an AWS S3 bucket for file uploads, and wrap it all in a heavy front-end framework.

This architecture is fantastic for social networks, e-commerce, and collaborative documents. We argue, however, that it is completely wrong for file utilities.

The Traditional Compressor Architecture (And Why It Fails)

When you use a standard image compressor website, the architecture demands you:

1. Upload your 5MB photo to their server (costing them inbound bandwidth and adding latency).
2. Wait in a queue for a server node to pick up the job.
3. Run an intensive Bash script (like ImageMagick or standard `libpng`) on an AWS EC2 instance (costing them compute).
4. Save the output to an S3 bucket (costing them storage).
5. Download the file back to your machine (costing them outbound bandwidth).

In this model, the company pays for every single megabyte you upload and download, and every CPU cycle used. To cover these immense costs, they are forced to do three things: plague you with ads, enforce draconian limits ("Maximum 5 uploads per day!"), or charge steep monthly subscriptions.

The ZeroPNG Paradigm Shift

We designed ZeroPNG to be different. The core rule for the project was simple: $0 server-side compute, $0 databases, 0 bytes uploaded.

1. Total Reliability & Zero Cost Scaling

ZeroPNG consists only of static files (HTML, CSS, JS, and WebAssembly bundles). It is hosted entirely on a global CDN. Because there is no backend API waiting to process images, we literally cannot go down during traffic spikes.

Whether 1 person compresses an image or 1,000,000 people compress an image simultaneously, our server compute cost remains exactly $0. We don't need load balancers, we don't need scaling policies, and we don't have server outages.

2. Unbeatable Speed

By moving the computation to the Edge (your device), we eliminated the two slowest parts of internet utilities: upload and download latency. On a slow 3G connection, uploading a 10MB file to a backend server might take a minute. With ZeroPNG, processing starts instantly the millisecond you drop the file because the browser reads it directly from your hard drive.

Modern devices, even standard smartphones, have incredibly powerful CPUs. A local browser running optimized JavaScript or WebAssembly can often compress an image much faster than an overburdened, shared cloud server.

3. Absolute Privacy by Default

We often tell our users that "your images never leave your device," but as engineers, we know it's deeper than that: we physically cannot access your images. We don't have an S3 bucket. We don't have an API endpoint to receive payloads. The architecture prevents data collection by design.

In an era of rampant data harvesting and AI scraping, architectural privacy is infinitely more trustworthy than a privacy policy promise.

The Beauty of the Modern Browser

ZeroPNG relies heavily on native Browser APIs that simply weren't capable of this 10 years ago:

• OffscreenCanvas & 2D Context: Allows us to draw massive images in memory without affecting the UI thread, performing high-quality resizing and format conversions right in the DOM.
• Web Workers: Offloads heavy quantization algorithms to background threads so the UI stays buttery smooth.
• WebAssembly (WASM): When native JavaScript isn't fast enough, we bring in pre-compiled libraries (like `heic2any`) that run C/C++ logic at near-native speeds in the browser.

Less is More

Building without a backend wasn't just a cost-saving measure; it was an exercise in pure engineering discipline. By stripping away databases, user auth, APIs, and cloud buckets, we were able to focus entirely on what matters: making a tool that is blazing fast, perfectly secure, and a joy to use.