Lossy recompression is irreversible: quality removed once cannot be restored. Recompress the original rather than an already compressed copy, and keep the originals separately.
/en/tool/image-compressor/ works the file stays in the browser
Select images or paste a screenshot from the clipboard—the browser will recompress them automatically and show how much space was saved. Files aren't uploaded anywhere: they're decoded and encoded on your device, in a separate thread. You can set a target file size, then open any image at full width and move the slider between the original and the copy.
You can select multiple files at once, drag them into the frame, or paste a screenshot from the clipboard. Originals remain unchanged—the tool creates copies.
Click the preview or “View” to open the image full screen: a divider between the original and copy, 1:1 zoom with dragging, a “Difference” mode, and a quality slider that recompresses only this image.
A row will appear here for each file: its original size, new size, the number of colors or quality setting used, and where to get the copy.
Select files with the button, drag them into the dashed box, or paste a screenshot from the clipboard with Ctrl+V. You can select several at once.
Leave the format set to “Automatic” if you are not sure what to choose: the tool examines the image itself—transparency sends it to WebP, diagrams and screenshots to palette-based PNG, and photos to AVIF or WebP. “Same as original” recompresses the file without changing its format.
If you need to meet a size limit, turn on “Meet the size limit” and enter a number or click a preset. The quality will be selected automatically, and the table will show the value at which the file fit.
Set the dimensions based on where the image is actually displayed. A 4,000 px-wide photo shown at 600 px on a product card is megabytes wasted. There are five options: by width, by height, by the long side, by percentage, and “fit within W×H.”
Open the image with the “Preview” button and move the slider. The quality slider there recompresses only that image, immediately; the “Apply to all” button applies the selected settings to the entire batch.
Get your results: “Download” in a table row saves one file, while “Download all” saves everything together as one ZIP. If only one file was recompressed, the button returns it without an archive.
Savings = (before − after) ÷ before × 100%
Lossy recompression is irreversible: quality removed once cannot be restored. Recompress the original rather than an already compressed copy, and keep the originals separately.
The input data is the same as the default field values: you can calculate it mentally and confirm that the tool is telling the truth.
Amount removed: 2,400 − 600 = 1,800 KB.
Share of the original size: 1,800 ÷ 2,400 = 0.75.
As a percentage: 0.75 × 100 = 75.
Savings: 75%. The file became exactly four times smaller: 2,400 ÷ 600 = 4.
True. The image is decoded right in the browser with createImageBitmap, drawn to a canvas, and encoded back there—in a separate Web Worker created from this same page. No network requests are made: open the “Network” tab in developer tools and check for yourself. That’s how this tool differs from TinyPNG and iLoveIMG, which upload files to someone else’s server.
Because PNG is no longer handed back to the browser. The canvas encodes PNG at 24 bits per pixel using its own settings, and the screenshot copy ended up larger than the original. Now the image goes through palette quantization (median cut; the number of colors is set with the slider) and is assembled by the tool’s own PNG encoder: indexed colors, a depth of 1, 2, 4, or 8 bits, and its own deflate. Screenshots and diagrams are usually three to five times smaller than the original this way. If you turn off the palette, the browser encodes the PNG again.
Yes, if your browser supports it: the page asks the browser on load and disables the button when the answer is no. Today, Chrome and Edge can encode AVIF; Firefox and Safari cannot. There is no AVIF encoder compiled to WebAssembly here: it weighs several megabytes and would have to be loaded as a separate file. AVIF input works anywhere the browser can display it.
It opens only in Safari: HEIC decoding is handled by the operating system itself, and the browser uses that support. Chrome and Firefox cannot open this type of file—the table will clearly say when it fails. On an iPhone, the workaround is “Settings → Camera → Formats → Most Compatible”; photos will then be saved as JPEG.
It is preserved in WebP, PNG, and AVIF, including palette-based PNG: semitransparent pixels use separate palette entries, so edges remain smooth. JPEG does not support transparency, so transparent areas are filled with white—this is immediately visible in the preview.
This is what you need when a platform requires “no more than 100 KB.” The tool finds the right quality with a binary search: it tries the midpoint of the range, checks the file size, and moves the boundary—six to eight passes in total. The value it finds, such as “63,” appears in the table. PNG uses the same process to find the number of colors. If the file still does not fit at the lowest quality, the image is reduced further. If that still does not help, the tool says plainly that the target size could not be met.
No, and this has been tested separately. The problem is that browsers behave differently: some rotate images according to EXIF automatically, while others return them as stored. Chrome today does not even honor a direct request to “do not rotate.” So the tool does not ask the browser—it runs a test instead: it creates a tiny 8×4 JPEG with an orientation tag and checks how the browser returns it. If the browser rotated it, we leave it alone; if it returned it as is, we rotate it ourselves. With “Keep EXIF” enabled, the orientation tag in the copy is reset to 1: the pixels have already been rotated, and a second rotation would turn the photo sideways.
By default, EXIF is not carried over: canvas returns only pixels, which is usually better for the web—the file is smaller, and the photo’s location data does not travel with it. “Keep EXIF” copies the EXIF segment from the original JPEG to the copy when both input and output are JPEG; the orientation tag is reset to 1. The color profile is not carried over, and that is intentional: after decoding the image, the browser has already converted it to sRGB, so the pixels have changed. Attaching an Adobe RGB profile to them would misrepresent the colors and make the copy look unnaturally vivid. The browser either writes a profile to the copy or does not; when there is none, sRGB is implied—which is what the pixels actually use. EXIF is never carried over for WebP, AVIF, or PNG.
Only the first frame remains—the browser’s canvas cannot rebuild an animation. The tool detects animation by counting the frames in the file and reports it in the result row instead of staying silent. The same applies to animated WebP and APNG.
To see exactly where compression damaged the image. The difference is calculated pixel by pixel between the original and the copy, then amplified six times: the lighter an area is, the greater the difference there. Edges glow in a photo; letters glow in a screenshot. If the letters glow, the quality is too low.
Because browsers block consecutive downloads: Chrome asks for permission to “download multiple files,” while Safari may stop the queue after the second or third file. The archive is built right in the tab using the store method—without compression inside: the files are already compressed, so another pass would save almost nothing but would take time. Names inside the archive are encoded in UTF-8, so Cyrillic text is readable.
Yes, right in the browser: format, quality, size, palette, and naming mode are restored the next time you visit. They are also stored in the page URL, so you can send a link with the desired settings to a colleague, and the same settings will open for them. The images themselves are not included in the URL, of course.
Calculates the contrast of a color pair and shows whether it passes AA and AAA.
Open