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:
fetchXMLHttpRequestsendBeacon
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.
Top comments (0)