Why I built PixelFix Pro

It started with a passport photo. I needed to resize an image to the dimensions required for a visa application. Shouldn't take more than a minute.

The first tool I tried asked me to create an account before downloading my resized photo. The second uploaded my file to a server and showed me ads for 30 seconds while it "processed." The third gave me the correctly-sized photo but put a giant watermark across it and asked me to pay to remove it.

This is a passport photo. My face. Being uploaded to servers I know nothing about, by companies I've never heard of, for a task that requires zero server-side processing.

For resizing, cropping, and format conversion, browser APIs can handle the work locally. I wanted a tool that made those operations available without an account or an upload to a processing server.

So I built it myself

PixelFix Pro processes selected images and PDFs in your browser. Canvas, Web Workers, and locally bundled JavaScript libraries do the work on your device. The site has no image-processing API, so your selected files are not sent to PixelFix Pro for editing.

You can inspect the browser's network panel while editing to verify that the selected file is not uploaded. Pages and tools that have already been cached can also keep working offline, although a first visit still needs the site assets and some browsers may clear cached data.

What's different about how this is built

The site uses Astro — a framework that outputs pure static HTML/CSS/JS with no server runtime. It's deployed to Cloudflare's edge network. There's no backend, no database, no user accounts, and no image-processing pipeline — because there doesn't need to be one.

The main editor moves pixel-heavy work into a Web Worker when the browser supports it, while the Batch Editor uses OffscreenCanvas. PDF tools use pdf-lib, jsPDF, and PDF.js; HEIC conversion uses heic2any. These libraries are bundled with the site and execute client-side. Performance still depends on the browser, image dimensions, and available memory, which is why the tools enforce practical limits rather than pretending every file will work everywhere.

Honest about the trade-offs

The tools are free to use. I plan to support their running costs with advertising and optional contributions. AdSense approval is required before Google ads can earn revenue. The privacy policy explains analytics and advertising separately from file processing.

What I don't do: require an account, put a PixelFix watermark on downloads, or send selected files to an editing server. Advertising and consented analytics can make separate network requests, but they do not receive the files you open in the tools.

A static site removes a lot of server-side failure points, but it still needs maintenance. Browser APIs change, file formats have edge cases, and large documents can expose memory limits. I would rather state those constraints clearly than promise that every file works on every device.

How I test it

Before a release, I run automated browser workflows through the main editor, Batch Editor, PDF tools, EXIF remover, favicon generator, passport-photo workflow, and file-size compressors. Those checks load real files, exercise the controls, and inspect the downloaded output rather than stopping at “the page opened.”

HEIC conversion is tested with a real HEIF sample, and batch runs are opened from the generated ZIP. I also check narrow mobile layouts, keyboard interaction, corrupt-file errors, and browser memory safeguards. If you find a file that fails, the most useful report includes the browser, device, file type, approximate size, and the action you were taking.