Images & photos · Social Image Resizer
How Browser Image Resizing Works: Canvas, drawImage and Resampling
· How it works
image-resizing canvas browser-processing
A browser can decode a photo, draw it into a canvas at a new size and encode the result, all without a server. This post follows that pipeline, explains where quality is won or lost, and shows why the only size limit is your device's memory.
No upload, no server, still resized — the concrete question of where the work happens when a page shrinks a 20-megapixel photo
A photograph can become a 1080 by 1350 portrait without visiting an image-processing server. Social Image Resizer receives a File from the browser picker, validates its MIME type and size, and calls createImageBitmap. That decoded bitmap remains the source for every selected output, so one local object can feed several differently shaped canvases.
The visible preview is not the final export hidden behind a network request. It is a smaller canvas rendering of the same framing state: target ratio, zoom, offset, fit mode and background. Export later repeats that render at the preset dimensions, encodes a Blob and hands the Blob to the download controls in the page.
Decoding is local, but this tool also enforces a 40 MB input limit
The plan says device memory is the only practical boundary, but the shipped input path has an explicit 40 MB file limit as well. JPEG, PNG and WebP are accepted; other types are rejected before decoding. After that gate, createImageBitmap asks the browser to turn compressed file bytes into width, height and decoded pixels usable by canvas.
Decoded pixels can occupy much more memory than the compressed file, and each output canvas requires its own allocation. The renderer therefore calls the shared pixel-budget guard before creating a canvas. That is a second, device-oriented constraint, not permission to promise that every file below 40 MB will fit every requested output on every machine.
drawImage scales a positioned full bitmap while the output canvas clips overflow
ToolAcre does not calculate a source crop rectangle and pass eight source-and-destination arguments to drawImage. It computes a scale from source and target dimensions, positions the entire scaled bitmap, and draws it onto a canvas whose edges clip any overflow. In cover mode that clipping is the crop; in contain mode the whole bitmap remains visible.
The distinction matters because crop and resize are not synonyms. Resizing changes the dimensions at which the bitmap is sampled. Cropping removes whatever lies outside the finite output frame. One drawImage call can participate in both effects here, but the crop is produced by frame geometry and clipping rather than by rewriting the source file first.
Resampling under the hood — smoothing settings, what a 'high quality' hint asks the browser to do, and why results differ slightly between browsers
Before drawing, the renderer enables imageSmoothingEnabled and sets imageSmoothingQuality to high. Those are browser canvas controls, not a request for a named Lanczos, bicubic or other kernel. The implementation cannot promise identical samples across engines because the API exposes a quality hint rather than the browser’s exact coefficient table.
A useful comparison keeps the source, output dimensions and browser fixed, then inspects diagonal edges, fine lines and repeated textures. If another browser differs slightly, that does not mean the target ratio changed. It means the same geometric request passed through a different canvas implementation, which is exactly why the article avoids invented performance or quality percentages.
Encoding the output — turning the canvas back into an encoded image file and offering it for download
The export canvas becomes a Blob through OffscreenCanvas.convertToBlob when that method exists, or HTMLCanvasElement.toBlob otherwise. The user chooses JPEG, PNG or WebP. A quality value is supplied to the encoder, although PNG does not use a lossy-quality control in the way JPEG and WebP do. The resulting byte count is measured, not estimated.
For several selected targets, the tool builds each Blob in sequence, displays its real dimensions and measured size, and can package the already encoded files into a ZIP. ZIP storage does not improve image compression here; the content notes that those formats are already compressed. Individual downloads and the archive both originate from locally created bytes.
This implementation performs export work on the main thread, not in a Web Worker
The workbook says heavy work usually runs in a Web Worker, but this app imports crop and rendering functions directly into main.js and loops through targets there. No Worker is created in the inspected path. The page can still remain usable for ordinary jobs, but responsiveness must be observed rather than attributed to an architecture that is not present.
Network isolation is supported by two kinds of evidence. Core tests install a network guard and frame every preset without an attempt, while the product record marks processing local. A runtime Network-panel check can add deployment evidence. It should distinguish image upload from ordinary page assets or disclosed analytics instead of claiming the whole page makes no requests.
What this does not cover — GPU-accelerated resizing libraries and server-side image pipelines
This route is intentionally built on browser primitives rather than a GPU library or remote media pipeline. It does not expose a selectable resampling kernel, benchmark alternative algorithms or promise accelerated batch processing. One source image produces several crops; many unrelated source files belong to a different workflow.
Those exclusions keep the promise testable. The code proves file validation, bitmap decoding, arithmetic framing, canvas drawing, Blob encoding and download assembly. It does not prove how a server farm would resize the same pixels or which GPU path a browser may choose internally. Claims stop at the observable Web APIs used.
Takeaway: your browser already has a resizer built in — the Social Image Resizer drives it for you, cropping and scaling to the platform's aspect ratio without uploading the file
The browser already supplies the essential operations, but useful results depend on correct geometry around them. Social Image Resizer chooses max-scale for cover, min-scale for contain, clamps movement, previews safe-area guidance separately and exports at exact target dimensions. That orchestration turns a low-level drawing API into a repeatable social-asset workflow.
Test the pipeline with an original image rather than a previously shrunken copy. Choose a current tool preset or custom ratio, move the subject, export once and inspect the downloaded dimensions. The evidence is the local file you receive and the code path that made it, not a claim that every browser uses an identical hidden resampler.