How I verified that an image resizer processes files locally

Roshan — Mon, 31 Aug 2026 23:43:20 +0000

Many online image tools begin with the same instruction: upload your file.

That is convenient, but it also means trusting an unfamiliar server with profile photos, identity documents, application images, or private screenshots. When I built Shard Tools, I wanted the image-processing step to happen inside the browser instead.

I also wanted that claim to be inspectable rather than another privacy slogan.

What the resizer does

The 200×200 image resizer creates an image that is exactly 200 pixels wide and 200 pixels high.

A rectangular image cannot become square without making a choice. The tool provides two:

Crop to fill preserves the aspect ratio and removes the overflow around a centered square.
Fit with background preserves the complete image and fills the remaining space with a selected background color.

It does not stretch the width and height independently. That would technically produce a 200×200 file, but faces, logos, circles, and text would be distorted.

The width and height remain editable for forms that require a different exact size.

What happens inside the browser

After you choose a file, the browser decodes it locally and reads its visible orientation. This prevents phone photos from being processed sideways.

Crop-to-fill enlarges the image until it covers the square, then removes the overflow. Fit-with-background scales the complete image into the square and fills the remaining space. Both approaches preserve the original aspect ratio.

The browser draws the result onto a new 200×200 canvas and creates a temporary download link inside the current tab. The selected image does not need to be sent to Shard Tools for processing.

What I tested

During the latest release check, I processed a PNG and verified that the generated result reported an actual width and height of 200×200 pixels.

The interface displays dimensions read from the generated output rather than assuming that the requested size was produced. It also reports the output file size before download.

This test verifies the pixel dimensions. It does not claim that a 200×200 image meets passport or biometric-photo requirements, and it does not guarantee a particular file size in KB.

Making the privacy claim testable

I built a separate live privacy-proof page that performs a real 200×200 resize while measuring data-capable browser requests immediately before and after processing.

The measurement watches requests initiated through:

fetch
XMLHttpRequest
sendBeacon

When the difference is zero, the image-processing action added no request through those mechanisms that could carry the selected image away.

You can check this independently:

Open your browser’s developer tools.
Select the Network panel and clear its request list.
Run the built-in sample or choose an image.
Inspect any requests added during processing.
Confirm that the output uses a local blob: URL rather than an upload response.

An important limitation

The proof does not claim that the entire webpage makes zero network requests.

The page still downloads its HTML, JavaScript, CSS, fonts, advertisements, and external directory badges. Those third-party hosts are disclosed in the live page report.

The narrower claim is the useful one: selecting and processing an image should not add an upload request.

The request counter is an observable browser measurement, not a formal security proof. That is why the page explains what it measures and encourages visitors to verify the result in the Network panel.

Why this distinction matters

“Runs locally” should describe an observable boundary, not just marketing copy.

For this tool, selecting, decoding, resizing, previewing, encoding, and creating the download all happen through browser APIs. The server provides the application, but it does not need the selected image to produce the result.

Try the 200×200 image resizer, or inspect the process using the privacy-proof page.

I would especially appreciate feedback about the measurement, its limitations, and anything the disclosure should explain more clearly.

I asked 50+ developers what they do when their AI session dies mid-task. Here's what I found.

Roshan — Thu, 02 Jul 2026 22:15:58 +0000

Not a product pitch just research notes from talking to a lot of people.
I've been building in the AI coding tools space and wanted to understand one specific moment: your session hits a limit, gets deleted, or just goes stale. What do you actually do?

I posted in a bunch of developer communities and talked to people directly. A few things surprised me.

The power users aren't your best signal
Developers with sophisticated workflows custom handoff skills, AGENTS.md discipline, tmux harnesses — described the pain clearly but had already built their own fix. They're not looking for a tool. They're looking for a better version of what they made.

The people who described the pain most vividly were non-technical: a tax lawyer doing no-code projects, a school admin. No workaround, no jargon — just "I have to explain everything from scratch and it's exhausting."

Nobody trusts the transcript

Almost everyone said the same thing unprompted: the chat history isn't reliable. It carries old failed attempts, wrong assumptions, things the AI said confidently that turned out to be wrong. The people with the best workflows kept the working state outside the chat — git diff, changed files, a short note about what actually worked.

The moment that resonates

"What do you do when your AI session dies mid-task and you have to explain everything to a new tool from scratch?"

That question got strong reactions every time. Not "context management" or "handoff tooling" those got polite nods. The specific painful moment got people telling stories.

DEV Community: Roshan