Sending a photo from a phone usually fails for one boring reason: size. Most webmail providers and content management systems cap uploads somewhere around 20 to 25 MB, while a modern 12-megapixel phone photo encoded at full quality lands in the 3 to 5 MB range, and a HEIC shot can be larger still. The usual fix is a re-encode at a lower quality setting, which is exactly what this page does with the browser's own image encoder. It matters that the re-encode happens in your tab. The images people compress are often screenshots of unreleased product work, scans of identity documents, or photos of their children, and a tool that uploads them to somebody else's server turns a convenience into a data protection problem. Nothing is transmitted here: the page has no upload endpoint, so the decode, the resize and the re-encode are done on your machine with the canvas and Blob APIs, and the result is available while you keep the tab open.
What actually happens when the browser re-encodes an image
Three steps, all local. First the file is decoded into a bitmap, which means it is fully expanded into memory - a 12-megapixel JPEG needs roughly 36 MB of pixel data before anything else happens. Second the bitmap is drawn onto a canvas at the size you asked for. Third the canvas is encoded back to a file with toBlob, and the quality argument only matters for the lossy formats: browsers ignore it for PNG, which is lossless by definition, and default to about 0.92 for JPEG. Two consequences follow. Your original file keeps all of its EXIF data - camera model, capture time, GPS coordinates - while the newly encoded copy has none of it, because EXIF lives in the JPEG container and not in the pixel data the browser gives you. That is convenient for privacy and a genuine loss for anyone who relies on orientation metadata, which is the second real trap: a photo shot in portrait can come out sideways if the EXIF orientation flag is not applied while drawing to the canvas.
Picking a quality number instead of guessing
There is no universal best value, but there are defensible defaults. For photographs destined for a website, 0.7 to 0.8 is the range most people end up on: file size usually falls by more than half and the difference is hard to see at normal viewing size on a modern screen. Around 0.9 you are usually getting something close to visually lossless, and below 0.5 the encoder starts to flatten fine texture - grass, hair, fabric - and you should stop and reconsider. Two things behave differently. Screenshots and flat-colour graphics should stay PNG, because re-encoding them as lossy introduces ringing around text edges where there was none. And an already-compressed JPEG is the worst possible input: every save creates a new generation, so compressing the same file five times in a row costs you five generations of artefacts. Always compress the original, not the output of the last run.
When a resize beats a quality cut
File size is driven mostly by pixel count, not by quality. A 6000 by 4000 photo at quality 0.9 is still a 3 MB file, and halving each dimension removes three quarters of the pixels and roughly three quarters of the bytes. So the order that costs the least quality is: crop to what you actually need, resize to where the image will be displayed - a hero banner rarely needs more than 2000 pixels of width on a desktop page - and only then lower the quality. If a service rejects images above a pixel dimension as well as a file size, a resize is the only thing that will get you past it. What no browser-side tool can do is invent detail that was never captured, so upscaling a small image to make it look large in print will always look soft.
Frequently asked questions
Are my images uploaded to a server?
No. This page has no upload endpoint; the image is decoded, redrawn and re-encoded inside your browser tab, and it disappears when you close the tab. Be aware that the site is supported by advertising, so ad providers can see page-level information such as your IP address and which pages you visit. Your image files are not part of that.
How much smaller will my file get?
It depends entirely on the input. A detailed photograph re-encoded at quality 0.75 often ends up 50 to 70 percent smaller. A screenshot that was already saved as an efficient PNG can come out bigger, because re-encoding a lossless image losslessly is pure waste. There is no honest tool that can promise a fixed percentage before it sees your file, so compress one sample and look at the result before doing a batch.
Will compressing a JPEG make it look blurry?
At the settings most people use, no - but compression is a re-encode, and a re-encode is a real generation of loss. The artefacts are not blur: they show up as blocky patches in skies first, then as smearing around fine detail. Keep your original file. If you need a version that is as close to identical as possible, stay at 0.9 or higher and accept a smaller saving.
Does it work without an internet connection?
Once the page has loaded, yes. The compression is local JavaScript, so a dropped connection does not interrupt it. You still need a connection the first time to load the page itself; after that you can keep working in the same tab, or re-open the saved page offline in a browser that supports it.