Change the pixels to match the actual display area
Resizing changes the number of pixels in the width and height. It does more than rename a file or reduce its storage size. If a website or message only needs a small illustration, retaining a very large source may add unnecessary processing and download weight. This workspace provides exact pixel fields, percentage presets and a proportions lock. Decide on the intended display area before changing quality.
With proportions locked, changing one dimension updates the other from the source ratio. Turning off the lock permits stretching; it does not crop the picture. Percentage presets are calculated from the original image rather than accumulating repeated reductions. Enlarging an image cannot create details missing from the source. Inspect text, edges and faces at the intended viewing size after producing the result.
Worked example
A 160 by 100 pixel PNG resized to a width of 80 pixels becomes 80 by 50 when proportions remain locked. This is the real resize case verified for this integration. Changing either field afterwards invalidates the previous result; generate the image again before downloading. Choosing WebP changes the output format in addition to its dimensions.
Local processing and limits
One supported static image is processed at a time. The general input limit is 10 MiB and twelve million pixels; AVIF processing is limited to four million pixels. Unsupported animation, image sequences, HDR and unverified container features are refused. Large images need more memory even when their compressed file is small. A failed operation does not switch to a server-upload fallback.
The browser downloads its own application and codec resources from the same host. Your selected image, result, filename and metadata are not sent to an upload service. Images are not written to localStorage, IndexedDB or a service-worker recovery cache. Reloading the page leaves the image workspace empty. Downloaded files remain under your control; inspect them before sharing.