How browser-based image compression works
Every compression pass runs entirely in JavaScript. No codec library is downloaded and no server is involved. The browser's own Canvas API decodes the image, re-encodes it at a lower quality, and hands you a Blob the page can preview, download, or zip up. Because every step stays inside the tab's sandbox, the original files never touch the network.
- Read each uploaded file as a Blob and create an object URL so the browser can decode it locally, without copying bytes to a server or writing them to disk.
- Draw the decoded image onto an offscreen Canvas element at its original pixel dimensions, ready for re-encoding.
- Call
canvas.toBlob(callback, mimeType, quality)to re-encode the pixels. In quality mode the slider value maps straight to the encoder's quantization setting; in target-size mode the page bisects the quality value until the output blob fits under your byte budget. - Show a before/after readout with the original size, the compressed size, and the savings percentage, then offer a per-image download or a single ZIP for the whole batch. The ZIP is built in memory using fflate, an 8 KB library loaded on first use.
Why compress images?
- Smaller images load faster. Cutting a 4 MB hero image to 600 KB improves Largest Contentful Paint directly, which is one of the Core Web Vitals Google uses for ranking. On a page with several photos the saving compounds into a faster first paint.
- Then there are upload caps. Plenty of CMS platforms, ticketing tools, and email systems reject anything over 1 or 2 MB, and a quick compression pass gets a photo under the limit without you opening a full editor.
- Bandwidth and storage cost money at scale. Shipping WebP at quality 0.8 instead of full-size PNG can cut image payload by a third or more, which lowers CDN egress bills and mobile data use for your visitors.
- Some images shouldn't be uploaded at all. Because everything here runs in your browser, ID scans, medical images, and internal screenshots stay on your device. There's no third-party server like TinyPNG in the loop to worry about.
Common applications
Compression comes up whenever an image is bigger than the place it's going. Three patterns we see again and again.
- Preparing product photos for an online store. JPEG originals get compressed to quality 0.8 (or a 200 KB target) so the storefront stays fast and clears Core Web Vitals on mobile.
- Shrinking screenshots before attaching them to a bug tracker or wiki. A batch of PNG captures converted to JPEG at quality 0.85 often drops from tens of megabytes to a couple.
- Getting a photo under an upload cap — a job application portal that rejects files over 1 MB, an email system with a tight attachment limit, or a forum avatar that has to fit a byte budget.
A worked example: 4 MB JPEG to 400 KB
A 4 MB JPEG straight off a phone camera is a common payload that trips upload caps and slows pages. It's a fair benchmark for what compression saves.
Drop the JPEG into the upload zone, leave the format on JPEG, and either drag the quality slider down to 0.7 or switch to target-size mode and type 400 KB. In quality mode the Canvas pipeline re-encodes once and shows the result, typically around 500 to 700 KB depending on the photo. In target-size mode the page tries a few quality values, settles on the highest one that still fits under 400 KB, and reports the savings percentage. Click Download on the card to grab the single file, or click Download .zip if you compressed several images at once. The whole round-trip runs in well under a second for an image this size and consumes zero bandwidth after the page itself finishes loading.
What's the difference between quality mode and target-size mode?
Quality mode gives you one slider from 0.1 to 1.0 that maps to the JPEG or WebP encoder's quantization setting — lower numbers mean smaller files and more visible artifacts. Target-size mode flips the problem around: you name a size in kilobytes and the page bisects the quality value, encoding a few times until it finds the highest quality that still fits under your budget. Target-size is handy when a hard cap matters (a 1 MB upload limit, say); quality mode is faster and better when you just want a predictable visual result. PNG is lossless, so neither mode applies to it.
Does this happen on my device?
Yes, fully. The page uses the browser's native Canvas API and the Web File API to decode and re-encode each image in memory. No image data is sent to a server, there's no temporary upload, and no cloud round-trip. You can verify it yourself: open DevTools, switch to the Network panel, and run a compression. The only outbound requests you'll see are the initial page load and ad calls. Nothing image-shaped leaves the tab.
Why does compressing a PNG sometimes barely shrink it?
PNG is a lossless format, so the Canvas API can't throw away detail to make it smaller — it can only re-pack the same pixels. For photographs, a PNG is already large and the lossless re-encode saves little. The real win comes from switching the output format to JPEG or WebP, which use lossy compression suited to photos and routinely land 4 to 10 times smaller. Keep PNG only when you need lossless quality or transparency; otherwise pick JPEG for photos or WebP for the best size-to-quality balance.
Which format should I choose?
For photographs, WebP at quality 0.8 gives the best size-to-quality balance and is supported by every browser shipped since 2021; JPEG is the safe universal fallback when a destination is older or stricter. Choose PNG only when you need lossless quality or an alpha channel — line art, UI screenshots, logos with transparency. If you're optimizing for page speed and your audience uses modern browsers, WebP is almost always the right call; if you're feeding an old CMS or a print pipeline that rejects WebP, stick with JPEG.
Drop your images, pick a quality level or a target size, compress. Everything runs in your tab. No upload, no account, no waiting on a server queue.