Compress images online
Shrink JPG, PNG and WebP files in seconds — with a quality slider, before/after compare, and nothing ever uploaded.
Your images
Settings
Generated images
- Nothing uploaded
- Free, no sign-up
- Strips EXIF
- Batch files
The photo came off the phone at a few megabytes and the destination wants less: the email bounces, the form refuses it, the page takes too long to show it. LivreImage's compressor hands the image to your own browser's encoder and re-encodes it at the quality you pick. How much a file shrinks depends on what is in the picture, which is why every result card prints the size before, the size after and the percentage.
Tip: for photos, JPG or WebP compress far better than PNG; keep PNG for screenshots and images with transparency. Use the Compare button on each file to check before & after with the sliding lens. The reasons behind each choice, with sources, are in how to reduce image file size.
How it works
Two controls do the work on this page: the quality slider and the format bar. Everything else is checking the result before you commit.
Drop the files in
Choose or drag as many as you like, or hit Ctrl+V to paste one straight from the clipboard. Output format opens on Auto, so a JPG comes back a JPG and a PNG comes back a PNG.
Set the quality, or change the format
The slider opens at 82 and runs from 30 to 100. If a photo is still too heavy at a lower setting, check the format bar: JPG and WebP take the quality number, PNG does not.
Generate, compare, download
Click Generate images. Each result card shows the old size next to the new one, the percentage, the output dimensions and an EXIF stripped tag. Compare opens a full-screen before/after slider. Take the files one at a time, or the whole batch as a .zip.
What the quality slider is actually changing
The number goes straight to your browser's JPEG or WebP encoder, which uses it to decide how much detail to discard block by block. Nothing is resized unless you fill in Max width (px): the same pixels are simply described with fewer bits.
The top of the range is where bytes are wasted. The documentation of libjpeg, a reference implementation of the JPEG standard, warns that above about 95 the file grows dramatically for a gain that is rarely visible, and that even 100 still loses information. For photographs it suggests staying between 50 and 95. Lettering and hard edges show the damage first, so that is where to look.
The scale is not portable either. Quality 82 here may not produce the same file another program produces at 82: as web.dev puts it, not every tool interprets the number the same way. Judge the result with Compare on the card, not with the number.
The slider and PNG: what actually happens
On Auto, every file keeps its own type, and PNG is lossless. Feed the page a PNG and the slider still moves, but the number is thrown away: the browser's PNG encoder takes no quality argument. Nothing warns you, because on Auto that same slider is still doing real work on the JPGs sitting next to it in the queue.
Click PNG on the format bar and the page stops being quiet about it. The slider grays out, the value reads lossless, and a line appears underneath saying PNG is lossless and photos may get larger.
It can be worse than doing nothing. A PNG re-encoded through the browser can come out bigger than it went in: the image is decoded and written again, and this site has no PNG optimizer. The card shows that case with a plus sign in front of the percentage.
Two ways out. Click JPG or WebP to leave PNG behind, or take pixels off the image instead — that is what Resize image is for.
When compression is the wrong lever
Quality is the second thing to reach for, not the first. web.dev's guidance is to start with the dimensions and serve an image at the size it is displayed; compression comes after that.
- A 4000 px photo that appears in a 900 px column: type 900 in Max width (px) first. That leaves about a twentieth of the pixels to store, before any quality is given up.
- A screenshot full of text: keep it PNG. JPEG puts a halo around every letter.
- A JPG somebody already squeezed once: every new pass adds loss to the one before. Start from the original if you can.
- A file you are still editing: compress once, at the end, from the best original you have.
Three things the page decides for you
The queue takes JPG, PNG, WebP, HEIC, GIF, BMP and SVG. A few of those get handled in ways worth knowing before you drop a whole folder in.
- An animated GIF is read as a single frame and saved as a still PNG, and the card labels it GIF to single frame. Nothing on this site produces animated output.
- An SVG is rasterized at whatever pixel size it reports. No control on this page enlarges anything — everything here shrinks or leaves alone — so if the result comes out small, that has to be fixed in the SVG.
- The encoder is your browser's own. There is no switch for progressive versus baseline JPEG and no chroma subsampling control. Anything over 10,000 px on the long side is scaled down to fit.
Frequently asked questions
Which quality setting should I pick?
Start at 82, where the slider opens, generate, and read the before and after sizes on the card. For photographs the libjpeg documentation suggests staying between 50 and 95; above 95 the file grows dramatically and the gain is rarely visible. Compare is what settles it.
Why does my PNG barely shrink?
PNG is lossless — it discards nothing. For photographs, converting to JPG or WebP saves far more. Keep PNG for screenshots, graphics and transparency.
Does recompressing an already compressed image hurt?
Yes. Every JPG recompression discards more information and the damage accumulates. Start from the original whenever you can.
I need an exact size in KB.
Use the target pages — 20, 50, 100, 200, 300 and 500 KB, and 1 MB. They search for the highest quality that still fits the limit.
My upload limit is 5 MB or 10 MB. Which setting gets me there?
Generate at the default quality and read the size on the card. If the file is still above the limit, cap the width first and lower the quality only if that is not enough. If the file simply has to pass, Compress to 1 MB finds the setting by itself, and a 1 MB file clears both limits.
Does reducing width help more than reducing quality?
They do different things. Halving the width and the height leaves a quarter of the pixels to store, without touching the quality of the ones that remain, and web.dev's guidance is to start there. How many bytes that saves depends on the photo: type a Max width, generate, and read the card.
Two photos, same quality setting, completely different savings. Why?
Because the encoder is compressing content, not file size. Fine detail everywhere — foliage, fabric, grain, crowds — costs bits no matter what you set. Large smooth areas like a studio backdrop or a clear sky cost almost nothing. A number that halves one photo can barely dent another.
Can I compress a file that has already been compressed?
You can, but each pass adds loss: the libjpeg documentation warns that it accumulates with every cycle of compression and decompression. If the file genuinely has to get smaller, take pixels off it with Max width (px) instead of pushing the slider lower.
Can I aim for an exact file size, like under 200 KB?
This page is manual. Move the slider, click Generate again and read the new size on the card; repeat until it is under your limit, watching Compare as you go. If the number has to be met without the guessing, the target pages run that search for you.
Do I have to generate again after changing a setting?
Yes. Settings apply when you generate, so the queue is not re-encoded on every nudge of the slider. The button counts the files waiting and switches to Generate again once there are results to replace.