How browser-based image tools work — and what they can't do
Many online image tools now run entirely in your browser. Here is what actually happens to your file, how to check it, and where in-browser processing reaches its limits.
By Ranjith R, Creator & Developer of TryImagerPublished Updated 6 min read
A traditional online converter uploads your file to a server, processes it there and sends the result back. A browser-based tool does the same work on your own device, using features built into modern browsers. The practical differences are speed, privacy and a few limits that are worth understanding.
The three steps every conversion goes through
- Decode: the browser reads the file bytes and turns them into a grid of pixels. JPG, PNG, WebP, GIF, BMP and SVG are decoded by the browser itself. Formats it cannot read, such as TIFF or HEIC, need a decoder written in JavaScript or compiled to WebAssembly.
- Draw: the pixels are placed on a canvas — an off-screen drawing surface. Resizing, cropping, rotating, flipping and grayscale all happen here.
- Encode: the canvas is written out as a new file. The browser's encoders handle JPG, PNG and usually WebP; a quality value between 0 and 1 controls how much detail lossy formats discard.
How to check that nothing is uploaded
Open your browser's developer tools (F12 on most desktop browsers), switch to the Network tab, and run a conversion. On TryImager's built-in tools you will see page assets and, if you accepted analytics, an analytics request — but no request containing your image. You can also load a tool, disconnect from the internet, and convert a file: it still works, because nothing needs the network.
Memory is the real limit
A decoded image uses about 4 bytes per pixel, regardless of how small the original file is. A 48-megapixel photo needs roughly 190 MB of memory just to hold its pixels, before any copies for resizing. Desktop browsers usually manage this; older phones may not. TryImager estimates the decoded size before processing and compares it with what your device can reasonably handle, then processes very large images in strips rather than all at once.
Why results differ between browsers
Each browser ships its own encoders. Chrome, Edge, Firefox and Safari produce slightly different JPG file sizes at the same quality setting, and older Safari versions could not encode WebP at all. TryImager tests WebP encoding with a real sample before offering it and falls back to a WebAssembly build of libwebp when needed. File sizes shown are always measured from the actual output, so they match the file you download.
What browser processing can't do well
- Animated GIF and WebP: browsers decode the first frame only for canvas work, so animation is lost.
- Colour profiles: images are converted to sRGB; print workflows that rely on CMYK or embedded ICC profiles need desktop software.
- PNG optimisation: the browser's PNG encoder is lossless but basic, so it rarely beats files already optimised by specialist tools.
- Batch processing of hundreds of large photos is limited by device memory and battery.
Tools for this
Keep reading
- Understanding image quality and compression settings'Quality 80' means something different in every tool and every format. Here is what the number actually controls, and how to use it with confidence.
- Common image format problems, and how to actually fix themWhite boxes where transparency should be, files that won't open, uploads that get rejected. Most of these have the same root cause.
- How to reduce image file size without wrecking the pictureMost oversized images are oversized for one boring reason: the dimensions are far larger than anywhere they're displayed. Fix that first, then compress.
- JPG vs WEBP: is it worth converting your images?WEBP typically saves 25–35% over an equivalent JPG. Here is where that saving is real, where it isn't, and what you give up.