Re-encode a photograph at a quality you choose and get a much smaller file back. The image is read from your disk and processed in this tab, so nothing is uploaded and no daily quota applies.
Runs in your browser. Nothing is uploaded.
Your image is decoded to raw pixels, drawn onto a canvas, and encoded again as JPEG at the quality you set. JPEG discards information the eye is poor at noticing: it works in blocks, converts colour into brightness plus two colour channels, samples the colour channels more coarsely than brightness, and rounds away the fine frequency detail that contributes least to how the picture looks. The quality slider controls how aggressively that rounding happens. Nothing about this is reversible, which is exactly why it saves so much.
The size of the win depends almost entirely on what the file was before. A photograph already saved as JPEG has been through this once, so a second pass at quality 80 took 2,057,152 bytes to 1,199,262, a 41.7 percent saving. The same photograph stored as a lossless PNG went from 10,887,764 bytes to 1,201,043, an 89 percent saving, because PNG had been keeping every pixel exactly and a photograph has no flat regions for that to pay off on. Both results are about 1.2 MB, which is the honest summary: the output size is set by the image and the quality, not by what the input happened to be.
Choose an image
The same questions a security review would ask, answered plainly.
The slider is passed straight to the JPEG encoder, so moving it changes the output rather than a label. Around 80 is the usual sweet spot for photographs.
Compression reads your file and writes a new one to your downloads. Whatever is on disk stays exactly as it was, so a setting you dislike costs you one download.
There is no account, no queue and no free tier to exhaust, because there is no server metering anything. Compress two images or two hundred in a sitting.
A 3840x2160 photograph took 144 milliseconds from a JPEG and 179 from a PNG. The encoding is fast; on other tools the wait is the upload.
There is no upload step and no server to receive one. The page loads once, then all work on your images happens in local JavaScript.
No daily limits, no per-file ceilings imposed by a server tier, no watermarks, and no account. The practical limit is your own device's memory.
The same photograph in two formats, and why the savings differ so much.
The common case, and the more modest saving of the two.
Input
3840x2160 JPEG, 2,057,152 bytes
Output
1,199,262 bytes, 41.7% smaller, 144 ms
Settings: Quality 80
The file had already been through a lossy encoder once, so much of the easily removable detail was gone before this started. A 41.7 percent saving on an already-compressed photograph is a good result rather than a disappointing one.
Where the biggest wins on this site come from.
Input
3840x2160 PNG, 10,887,764 bytes
Output
1,201,043 bytes, 89.0% smaller, 179 ms
Settings: Quality 80
PNG stores photographic detail losslessly, which is the wrong trade for a photograph and the right one for a logo. Both runs landed near 1.2 MB, because the output size is decided by the picture and the quality rather than by the format it arrived in.
Real files, real numbers, and the machine they were run on.
| Scenario | Input | Output | Time | Notes |
|---|---|---|---|---|
| 3840x2160 photograph, JPEG in, quality 80 | 2,057,152 bytes | 1,199,262 bytes | 144 ms | 41.7% smaller |
| 3840x2160 photograph, PNG in, quality 80 | 10,887,764 bytes | 1,201,043 bytes | 179 ms | 89.0% smaller |
How this was measured: Measured by driving this page in headless Chrome 152 on an Apple M4 Pro running macOS 15.5, on 2026-09-17. The fixture is handed to the page's own file input, the page's own button is pressed, and the figure recorded is the size of the file the page produces. Timings come from a warm page on a fast machine with no network involved, so treat them as a floor rather than a typical result.
Compress at quality 80 first and check the result; a typical phone photograph drops by half or more. If it is still too large, reduce the dimensions as well, since halving both sides removes three quarters of the pixels.
Compress them, then serve them at the size they are actually displayed. A 4000 pixel wide photograph in a 800 pixel column is wasting most of its bytes regardless of how well it is compressed.
Start at 80. At that setting the difference is very hard to see at normal viewing distance on a photograph, while the file is typically less than half the size. Drop to 60 for thumbnails, and stay above 90 only when the image will be edited again.
You cannot, with this tool: JPEG is lossy by definition and every pass discards something. What you can do is choose a quality where the loss is invisible in practice, which for most photographs is well below the point where the file stops shrinking.
Attachment limits are usually 20 or 25 MB, and a handful of modern phone photographs clears that easily. Halving each one locally solves it without involving a file transfer service.
Page weight is dominated by images on most sites. Compressing before upload is the single cheapest performance improvement available, and doing it locally keeps unreleased assets off third-party servers.
Photographs of documents, identification and property are exactly the images that should not pass through an anonymous web service. This one cannot receive them even in principle.
Upload forms frequently cap each image at a few megabytes. Compressing to fit is quicker than rescanning or rephotographing, and nothing visible is lost at sensible settings.
A folder of PNG screenshots or exports can shrink by an order of magnitude. The saving on photographic content is far larger than most people expect before they try it.
The page keeps compressing with the network off once it has loaded, which is useful on a flight and is also the simplest demonstration that the photograph is not being sent anywhere.
Four things worth knowing before you replace an original.
Whatever you put in, you get a JPEG back. That is the right choice for photographs and the wrong one for logos, screenshots of text and anything with transparency, because JPEG has no alpha channel and blurs hard edges.
Detail thrown away is gone, and compressing an already-compressed file again removes more. Work from your original rather than re-compressing an output, and keep that original if the image matters.
A 4000 pixel wide photograph stays 4000 pixels wide. When an image is far larger than it will ever be displayed, reducing its size saves much more than re-encoding it does.
Redrawing through a canvas drops EXIF, so camera settings, timestamps and any embedded GPS location do not survive. Convenient for privacy, inconvenient if you were relying on capture dates.
No. The file is read by the page, drawn to a canvas and encoded again entirely in this tab. A photograph is a good case for checking that yourself: a genuine upload of a 10 MB image would show sustained network activity for several seconds, and there is none. Disconnecting before you compress settles it completely.
It depends far more on the source than on anything you choose. A photograph already stored as JPEG dropped 41.7 percent at quality 80, while the same photograph stored as PNG dropped 89 percent. Screenshots and graphics with large flat areas behave differently again, and often do better as PNG.
Eighty is a good default for photographs and is what both measurements above used. Above 90 the file grows quickly for detail almost nobody can see. Below about 50 the eight by eight block structure JPEG works in becomes visible, especially in skies and skin tones.
No. The pixel dimensions are identical afterwards; only how those pixels are stored changes. If the image is much larger than it needs to be, resizing it will save considerably more than compression alone.
Not here, because the output is always JPEG. For a photograph that is usually what you want, as the PNG measurement above shows. For a logo, a screenshot or anything needing transparency, converting to JPEG is the wrong move.
It does not survive. Transparency needs an alpha channel and the JPEG specification simply has nowhere to record one, so anything see-through is composited onto a solid backdrop during encoding. A logo cut out against nothing comes back sitting on a rectangle, which is usually discovered only after it has been placed on a coloured page.
No. Drawing the image to a canvas keeps only the pixels, so camera model, exposure settings, capture time and any location tag are all dropped. That is a useful side effect before publishing a photograph, and a loss if you were relying on those dates.
One at a time. The page takes a single image, which suits the common case of getting one photograph under a limit and is tedious for a folder of two hundred. A desktop batch tool is the better answer for that.
Because JPEG is built for photographs, not for text and sharp lines. It smears the high-contrast edges around letters and produces visible fringing. Screenshots of interfaces or documents should stay as PNG.
No, and it will cost you quality for very little. The second pass removes detail the first pass already removed, so the saving is small while the degradation accumulates. Always start from the original.
No fixed limit, since no server is applying one. The constraint is memory: the image is decoded to raw pixels, so a 3840x2160 photograph occupies about 33 MB uncompressed while it is being worked on. Very large images are more comfortable on a laptop than a phone.
Yes, once the page has loaded. Encoding is done by the browser itself, so nothing further is needed from the network. Only a fresh reload while disconnected depends on the page still being cached.
There is no limit imposed by us, because there is no server tier to enforce one. The real constraint is your device's available memory, since the whole file is held in RAM while it is processed. Very large files are slower on phones than on a laptop.
No. There is no sign-up, no email, and no usage tracking tied to an identity. The tool works the first time you open it.