Compress to a quality or to a file size, with the size shown being the encoded file to the byte and the cost measured on the pixels: SSIM, PSNR, the worst channel and the share of pixels changed.
Initializing in your browser…
Optimize and minify SVG files over a real markup tokenizer, then verify the result by drawing both versions and comparing every pixel.
Render SVG to PNG, JPG or WebP at a chosen size, with the size worked out from the file by the rules that define it and checked against the browser's own rendering.
Resize with the filter named (Lanczos, Mitchell, Catmull-Rom, bilinear, box or nearest) and the option to average LIGHT rather than stored bytes, which is worth 1.24 stops on a detailed picture.
A 1200 by 800 photograph is 613.1 KB and the upload form stops at 250 KB.
Input
comp-photo.jpg 613.1 KB · JPEG · target size 250 KB
Output
Reached 249.9 KB against a target of 250.0 KB at quality 74, after 10 encodes SSIM 0.8889 · PSNR 28.38 dB · worst channel 131 levels · 94.2% of pixels changed
The bisection encodes the real file at each quality it tries and the page lists every step, so the 249.9 KB is the length of the blob you download rather than an estimate of it. The output is then decoded again and compared with the input, which is where the four cost figures come from. Ask the same of a PNG and the answer is different: encoding at quality 0.05 and at 1.0 gives the identical number of bytes, so the tool reports that the format ignores quality instead of searching a constant and calling it a success.
Compression is a trade, and this tool makes both sides of it visible. Every setting change encodes the real output, so the size on screen is the size of the file you download, to the byte. That output is then decoded again and compared with the input pixel by pixel, and the page reports four numbers: SSIM, PSNR, the largest single-channel difference anywhere in the picture, and the share of pixels that moved at all. A JPEG at quality 80 typically leaves almost none of the pixels untouched, which is worth knowing before you re-save an archive. Target-size mode bisects on the quality setting and shows its working: every encode it performed, the quality it tried, and the bytes that came back. It also states the outcome rather than implying one. If the target is not reachable at this pixel size in this format, the page says so with the smallest file the format can produce. If the format ignores quality altogether, which is what PNG does, the page says that too instead of running a search over a constant and reporting success.
Give the limit in kilobytes and let the bisection find the highest quality that fits, with the file it produced measured rather than predicted.
Re-encoding an archived photograph costs a generation of quality. The SSIM and worst-channel figures say how much, before you overwrite anything.
Compress hero images and thumbnails, and see whether WebP at the same visual cost is smaller than JPEG for this particular picture.
A photograph saved as PNG usually grows several times over. The page warns, explains why, and points at the two things that do reduce a lossless file.
Only three formats are offered, because only three can be written. A browser canvas encodes PNG, JPEG and WebP; asked for AVIF, BMP, GIF or TIFF it returns a PNG without raising anything, with the PNG signature in the first four bytes and image/png as the blob type. Measured in Chromium on 2026-09-04, all four fall back that way. A download named .avif that is really a PNG is worse than no AVIF option, so the picker greys out anything this browser cannot write and says why.
JPEG and WebP read the quality argument; PNG does not. That is not a matter of degree: encoding the same picture as PNG at quality 0.05 and at quality 1.0 produces exactly the same number of bytes. The tool measures this rather than assuming it, by encoding at both ends of the range before any search begins, so the quality slider is disabled for PNG rather than left there looking as though it does something. The two things that do make a lossless file smaller are fewer pixels and a different format, and the page names both.
Resizing happens before encoding, through a separable convolution with the filter named: Lanczos 3 and 2 from the windowed sinc of Duchon (1979), the Mitchell and Catmull-Rom cubics from Mitchell and Netravali (SIGGRAPH 1988), a triangle filter, a box filter and nearest neighbour. There is also a choice of the space the average is taken in. Byte 127 carries 0.212 of the light of byte 255 under IEC 61966-2-1, so averaging the stored bytes is not averaging the light, and on a one-pixel checkerboard the two answers are 1.24 stops apart. Averaging the bytes stays the default, because that is what every other tool does, and the alternative is offered with the number beside it.
Re-encoding cannot carry metadata across, because the picture goes through a canvas and comes back as bare pixels. The page reads the source container first and lists exactly what will be lost: the EXIF block and its size, the ICC profile, XMP, IPTC, and any comment. The output carries whatever sRGB profile the browser writes, not the profile the source had. When the point is to remove metadata rather than to compress, the metadata remover rewrites the container instead and leaves the compressed image data byte for byte intact.
Yes, to the byte. Every settings change encodes the actual output and reads its length; there is no extrapolation from a sample anywhere in the tool.
PNG is lossless and its encoder ignores the quality argument. The tool checks this by encoding the picture at quality 0.05 and at quality 1.0 and comparing the two sizes; when they are identical there is nothing for the slider to do, so it is disabled rather than left there looking useful.
PNG stores every pixel exactly, including all the noise a JPEG had already thrown away, and DEFLATE cannot exploit the spatial redundancy that a DCT handles. Several times the original size is normal. The page warns when this happens.
They are gone. Compressing here draws the picture on a canvas and encodes it again, and a canvas carries no metadata, so EXIF, GPS, XMP, IPTC and the source ICC profile are all lost and the output carries the browser sRGB profile instead. The page lists what it is about to drop before you download. If you want the metadata gone and the pixels untouched, use the metadata remover, which rewrites the container.
Because a browser canvas cannot write AVIF. Asked for it, canvas.toBlob returns a PNG with no error at all: the blob type is image/png and the first four bytes are the PNG signature. The same is true of BMP, GIF and TIFF. Offering AVIF here would mean handing over a PNG under an .avif name.
Read the cost panel rather than a rule of thumb. It differs by picture: a photograph and a screenshot at the same quality setting have very different SSIM. As a starting point, 75 to 85 is where most photographic content stops showing obvious artefacts.
Only by choosing PNG or by not re-encoding at all. Every JPEG and WebP encode here is lossy, and the page shows exactly what it cost: on a PNG round trip the worst channel difference is 0 and the panel says the encode was lossless.
Images are decoded, edited, and exported entirely inside this browser tab. No originals, exports, or metadata are uploaded.