About — Who Built This & Why

How this started

I was getting the FASTag on my car replaced. The form wanted photographs at a particular size and file type — the sort of requirement that sounds trivial until you're actually staring at it. So I did what everyone does and searched for an online image resizer.

Two things bothered me about what I found.

The first was privacy. I'm genuinely uneasy about uploading personal pictures to a website I know nothing about. Part of it is the vague fear that things end up indexed and searchable somewhere. But the more concrete worry is what happens if personal documents reach the wrong people. Photos and ID scans are exactly the raw material for scams that work by earning your trust first — and the person who gets targeted has done nothing wrong. That asymmetry bugs me. Handing over a photo of my face to get it resized felt like a bad trade for a task my own browser could do.

The second was smaller and more subjective: I didn't much like using any of them. Interfaces buried the actual tool under things I hadn't asked for. No criticism of anyone's work intended — that's a matter of taste, and I'm still learning. I just wanted something simple.

So we built the simple version.

Who we are

Three of us, which is worth being upfront about because "we" on a website usually means one person or a company.

I'm Sakshi. I've worked as a software engineer for five years. I built the first version and I maintain the tools.

Aakash, a colleague of mine, partnered up on it early. I wanted a second engineer's judgment on the code and, more importantly, a second opinion from a user's perspective — it's very easy to think your own interface is obvious. He also wrote a good deal of the code. He is, I promise, a real person and not an AI.

Then we brought in Aishwarya, Aakash's sister, who doesn't work in tech at all. That turned out to be the most useful decision we made. Someone with no developer instincts will tell you immediately when a step doesn't make sense, where two engineers will both quietly assume it's fine. She handles feedback and is helping us get the site in front of people who need it.

The one architectural decision

Everything happens in your browser. When you drop in an image, the browser reads it locally and the file never travels anywhere. Resizing uses the HTML5 Canvas API. Compression runs a binary search over JPEG or WebP quality levels until it finds the highest quality that fits your target size. The result is generated in memory and saved straight to your device.

This was a deliberate choice, and not the easy one — server-side image processing is genuinely simpler to build, because mature libraries handle every format and edge case for you. Doing it in the browser meant more work and some real constraints. But it's the right architecture for a tool that handles passport photos and signatures, because it removes the question of trust entirely. There's no retention policy to believe, no breach that could expose your file, and no jurisdiction to think about. Nothing was sent.

You don't have to take our word for any of this. Open your browser's network tab, resize something, and watch for a large outbound request. There won't be one. We wrote up how to check this on any image tool, including ours.

A side effect: we have no server costs that grow with usage, so the tool can be free with no limits. No daily caps, no watermarks, no account. That's a consequence of the architecture, not generosity.

What running costs there are, advertising covers. We'd rather show you an ad than paywall the compressor or ask for your email, and we'd rather say so plainly here than let you discover it on the page. Ads sit in their own frames, below the tool — they have no access to your images, and the no-upload guarantee above is unaffected by them.

What we do differently

• Nothing is uploaded. Not "encrypted in transit" or "deleted after an hour" — not sent at all. Independently verifiable in your browser.
• No feature is paywalled. Compress-to-KB, format conversion, background removal, batch processing — all of it, no account.
• The interface stays out of the way. This was the other half of why we started. You should be able to see the tool.
• Exact file size targeting. Forms don't want "roughly 200 KB". The compressor iterates until it actually fits, and tells you honestly when a target can't be reached rather than handing back an oversized file.
• One pass, not three tools. Resize, convert and compress happen together. Each extra trip through a lossy encoder costs quality.

Honest limitations

Local processing has real costs, and we'd rather state them than have you discover them:

• Your device does the work. Large batches are slower on older phones, and very large files can run out of memory. The practical ceiling is around 50 MB per image, but it depends on your hardware.
• Background removal isn't instant the first time. It downloads roughly 40 MB of AI model on first use, then caches it. Calling that "offline" would be misleading, so we don't.
• PNG can't hit a file size target. It's lossless and ignores quality settings. Use JPEG or WebP when you need a specific KB size.
• Nothing syncs. No server means no starting on your phone and finishing on your laptop.
• We're still improving it. If something is confusing or broken, tell us — that feedback is genuinely how this gets better.

Supported formats

Built with

• Astro — static site generation, so content pages ship almost no JavaScript.
• Tailwind CSS — utility-first styling for a consistent design system.
• Canvas API — browser-native resizing, cropping and format conversion with no server involved.
• WebAssembly — runs the background-removal model on your own hardware at near-native speed.
• Binary search compression — re-encodes at successively refined quality levels to find the best one that fits your size limit, rather than guessing once.

The whole site is static files on a CDN. No backend, no database, nowhere your images could be stored even by accident.