This tool re-encodes a JPEG or PNG so the same picture occupies fewer bytes, leaving its width and height exactly as they were. The encoding is done by browser-image-compression 2.0.2 running inside a Web Worker in your browser, which is why the page stays responsive while it works, and why the picture never leaves the tab it was opened in.
How to use it
- Drop an image on the dashed panel, or click it to open the file picker. The picker lists JPEG and PNG only, but a drag-and-drop takes a different path and accepts anything whose MIME type starts with
image/— WebP, GIF and SVG included. - Once a file is loaded, a "Quality: 80%" slider appears below it (range 1–100, default 80). Nothing in that section is rendered before a file exists.
- Set the slider and press Compress. The button reads "Compressing…" and is disabled while the encoder runs.
- Two cards appear side by side — "Original size" and "Compressed size" — with a "Reduced by N%" line under the second.
- Press Download next to the preview to save the result as
compressed_plus your original filename. To try another setting, move the slider and press Compress again; the source file is still loaded.
When it comes in handy
Getting a phone photo under an upload limit
Registration forms, KYC uploads and assignment portals routinely cap attachments at 2 MB, while a casual phone shot is 4–6 MB. The dimensions are usually fine and only the byte count is a problem, so a pass at quality 60–70 tends to clear the bar with no visible difference. Check the number on the second card against the limit before you submit rather than trusting your eye.
Shrinking exported design assets for a deck
A 2x PNG out of Figma is easily several megabytes, and twenty of them turn one presentation into a file that takes a visible pause to open. Screenshots of interfaces — large flat areas of one colour — often lose more than half their weight to colour quantisation while button edges and type stay crisp. Gradients and photographic PNGs deserve a closer look, since smooth transitions such as sky or shadow are where banding shows up first.
Emailing photos to someone on a small mailbox
Attachments are Base64-encoded in transit, which adds roughly a third: a 5 MB photo occupies over 6.6 MB of a message that a corporate mail server may cap at 10 or 20 MB. Bring each one under 1 MB and ten of them still fit comfortably in a single message, with the bonus that the recipient is not waiting on a download while reading it on a phone.
Speeding up a page without touching its layout
When width and height are already set on the <img> and the CSS is built around those numbers, swapping the file is the least invasive optimisation available: the pixel grid is identical, nothing reflows, the browser simply downloads a few hundred kilobytes less. Changing the dimensions instead means editing markup, which is a different job and belongs to the resizer.
Limits and behavior
- The output format always matches the input. The original MIME type is handed straight to the encoder, so a PNG comes back a PNG. There is no way to leave here with a different container — that is what the format converter is for.
- One slider, two entirely different meanings. For JPEG it is the encoder quality parameter, where lower values discard more detail. For PNG the library first quantises the palette to roughly 4096 × quality colours — about 3,300 at the default 80 — and then encodes losslessly, so lowering the value costs you colours rather than sharpness.
- If the first pass produces something larger than the original, the library does not give up: it multiplies the quality by 0.95 and encodes again, up to ten times. When ten rounds still fail to beat the original it hands back the last attempt, which is why the reduction line can read as a negative percentage. Treat a negative number as a verdict — keep the file you already had.
- Pixel dimensions are effectively untouched. The library only starts scaling the canvas down when its output still exceeds 10 MB, and since the input is already capped at 10 MB you are unlikely ever to reach that branch.
- Failures are silent. The exception goes to the browser console and nothing on the page says so; the button simply returns from "Compressing…" to "Compress" with no result underneath. If pressing it appears to do nothing, open the console — usually the browser could not encode that particular format.
- GIF and SVG survive the drop check but rarely give you what you want: only the first frame of an animation is kept, vector artwork is rasterised, and since browsers cannot encode GIF the bytes you download are PNG wearing a
.gifextension. - Re-encoding discards EXIF, so capture time, GPS coordinates and camera model are absent from the result. Orientation is the one exception: the library reads it first and applies the rotation itself on browsers that do not auto-orient, so portrait photos do not come back lying on their side.
- One image per run, ten megabytes per file; anything heavier is refused with a red message under the drop panel. The result does not become the new source either — compressing twice means downloading and dropping the file in again, and a second pass mostly just costs you more detail.
Frequently asked questions
Is my image uploaded anywhere?
No. The file is opened locally through URL.createObjectURL and encoded on your own CPU; no request carries pixel data anywhere. The only network involvement is the Web Worker loading the encoder library, and that file is served by this site at /browser-image-compression.js rather than fetched from a third-party CDN. (The page itself still loads third-party resources such as advertising; those requests have nothing to do with your image.)
Does it work offline?
Yes, as long as the page is already open. When the worker cannot load the library, the code falls back to running the identical compression on the main thread. The output is the same; the page just feels less responsive during encoding, because nothing else is carrying the work.
What quality setting should I use?
For photographic JPEG, 70–80 is the usual sweet spot, and below that you start to notice blockiness in smooth regions such as sky or skin. Screenshots, charts and anything type-heavy are better kept above 85, since hard edges suffer first. No single number is right for every image, and the two byte counts are on screen, so comparing a couple of attempts is faster than theorising.
Why is the reduction shown as a negative number?
Because the result genuinely came out larger, and the percentage is computed straight from the two byte counts without being clamped at zero. The usual cause is a source file that a stronger encoder already optimised, which a second pass cannot beat; the other is a slider pushed near 100, which asks the encoder to throw away almost nothing.
Will compressing change the width and height?
No, and there are no dimension fields on screen to change them with. If what actually bothers you is a 4000 px photo being far bigger than its slot on the page, resizing helps far more than compressing, because byte count follows pixel count much more closely than it follows quality.
Can I drop in a whole folder?
No — the file input is single-select, and dragging ten images in picks up only the first. For batches, reach for a desktop tool such as ImageOptim or squoosh-cli, or a short sharp script, all of which also slot into a build pipeline more comfortably.