How to Compress PNG/JPG Images Locally inside Browser Memory
Images are the heaviest thing on most websites and the most common reason an email bounces back as too large. They are also personal: product shots before launch, photographs of your family, screenshots containing account details. Compressing them through an upload service means handing all of that to a third party for the sake of saving a few hundred kilobytes.
Your browser already contains everything needed to do the job locally: a decoder for every common format, a canvas to draw into, and encoders for JPG, PNG and WebP. This guide explains how to get professional results from that pipeline.
How local compression works under the hood
When you choose a file, the browser reads it into memory and decodes it into raw pixels. Those pixels are drawn into a canvas element, optionally at a smaller size. The canvas is then re-encoded with a chosen format and quality factor, producing a new binary blob. That blob becomes a download via a temporary object URL that points at memory on your own machine.
Two separate levers control the final size. Resizing reduces the number of pixels, which is by far the most powerful saving. Quality reduction keeps the pixel count but stores each block with less precision. Used together they routinely cut a photo by 80–95% with no visible difference at normal viewing sizes.
Choosing the right format
Format choice matters more than any slider. Picking correctly often halves the file before you touch quality at all.
- JPG — photographs and any image with smooth gradients. Lossy, no transparency, excellent for camera output.
- PNG — screenshots, logos, line art, anything with flat colour areas or transparency. Lossless, so photographs stay large.
- WebP — the modern default. Typically 25–35% smaller than JPG at equal quality, supports transparency, and is supported by every current browser.
- GIF — legacy. Convert static GIFs to PNG and animated ones to video or WebP where possible.
Picking a quality level that nobody notices
Quality is expressed from 0 to 100, but the curve is not linear. Between 100 and about 85 you lose almost nothing visually while the file shrinks dramatically. Between 85 and 70 you lose a little detail in fine texture, which is invisible on most screens. Below about 60 you start to see blocking around edges and banding in skies.
For web pages, 75–82 is the sweet spot. For email attachments, 70 is usually fine. For print or archival, stay at 92 or above, or keep an untouched original. The critical habit is to compare at 100% zoom, not in a thumbnail — a shrunken preview hides every artefact you are trying to evaluate.
One rule saves a lot of pain: never compress an already-compressed image repeatedly. Each pass bakes the previous pass's artefacts into the new file. Always go back to the original and do a single compression to the target you need.
Resize first, compress second
A phone photo is often 4000 pixels wide. A full-width hero image on a website is rarely displayed above 1920 pixels, a blog body image above 1200, and a thumbnail above 400. Serving four times the pixels the layout uses is the single most common performance mistake on the web.
Resizing to the real display width first, then compressing, produces files that are frequently a twentieth of the original with no perceptible loss. For product photography, exporting a 1600 pixel version for the detail view and a 600 pixel version for the grid is a better strategy than one compromise file.
A practical batch workflow
Work from a copy of your originals in a separate folder so the untouched files always remain. Decide the target width and format once for the whole set, then process each image with the same settings so the collection looks consistent. Spot-check two or three at full zoom rather than every file.
For transparency work — a logo over a coloured background, a product cut out from its scene — remove the background first and export PNG or WebP, because converting to JPG at any point will flatten transparency onto white and cannot be undone.
Why doing this locally matters
Photographs carry metadata. EXIF fields routinely include the exact GPS coordinates where the picture was taken, the device serial, and a timestamp. Uploading a holiday photo to a compression site hands over the location of your home if that is where it was shot. Re-encoding through a canvas strips that metadata as a side effect, and doing it locally means the original never travelled anywhere with the metadata attached.
Screenshots are worse in a different way: they frequently contain email addresses, invoice totals, customer names and internal dashboards. Local compression keeps all of it on your machine, with no retention policy to trust and no bucket to be misconfigured.