Image Compressor
Compress images to JPEG or WebP with optional target KB size, quality and dimension controls.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
Compress an image entirely on your device with JPEG or WebP output. Optionally enter a target file size in KB, where 1 KB means 1024 bytes. The search tries lower quality first and then smaller dimensions, with a bounded number of encodes. A download appears only when the actual encoded bytes fit; an unattainable target produces an error. Without a target, the selected quality and dimension cap apply. The preview and results show actual bytes, dimensions and quality. Small files can grow after re-encoding, and lower quality or dimensions can lose detail. JPEG flattens transparent pixels onto white.
When to use it
Questions
How do I compress an image to 100 KB?
Enter 100 in Target file size before selecting the image, or change it and press Compress again. The maximum is 102400 bytes because this tool uses 1024 bytes per KB. It tries lower quality and then smaller dimensions, and verifies the encoded byte count. It does not pad a smaller file to exactly 100 KB. If the bounded search cannot meet the target, no oversized download is offered. For an exact byte limit, divide that limit by 1024 and enter the result in KB.
Why did my small PNG get bigger?
PNG is a lossless format optimized for flat graphics; re-encoding photographic or noisy PNGs to JPEG at lower quality can end up larger than the original. For screenshots with flat colors, try WebP at 80–90% quality — or leave truly tiny PNGs alone, since there is nothing to save.
Why only JPEG and WebP output?
The point of this tool is lossy shrinking. PNG output would be lossless re-encoding, which rarely saves space; if you need PNG, the original already is one. JPEG is the universal default, WebP usually saves more at the same visual quality.
Is my image uploaded anywhere?
No. The file is decoded and re-encoded entirely in your browser using the canvas API — nothing is sent to any server. As a side effect, EXIF metadata (camera data, GPS coordinates, timestamps) is not carried into the compressed copy.
Why did my small PNG end up bigger?
Because PNG is a lossless format that flat graphics already compress extremely well, and re-encoding a screenshot to lossy JPEG at moderate quality cannot beat it. Check the before/after readout honestly: when the compressed copy is larger, decline it. WebP at 80–90% quality handles flat-color images better than JPEG does — and a few-kilobyte PNG needs no compression at all.
How do the dimension cap and the quality setting interact?
They are separate levers on the same output: the cap (original, 1920, 1280 or 800 px on the longest side, aspect preserved, never upscaled) discards pixels, while quality (50–90%, default 80%) decides how faithfully the remaining pixels are approximated. Resizing discards pixels and low quality discards image detail; inspect the preview before downloading. With a target KB size, quality and dimensions may fall below your selected settings to meet the budget. Start at 80% quality with a dimension cap, inspect, then trade further down only if the size target demands it.
Does it upscale a small image?
No — the cap is a ceiling, not a target. An image already smaller than the chosen maximum passes through at its original dimensions, because inventing pixels grows the file without adding information. The 'never upscale' rule also protects screenshots from the subtle softening that interpolation produces.
What happens to EXIF and GPS data?
It is gone — not scrubbed as a feature, but structurally: the output is rebuilt from raw pixels through the canvas, and metadata does not survive the rebuild. So the compressed photo is automatically location-free; the flip side is that anything you wanted preserved in metadata (rotation hints, color profiles) is gone too, and a viewer may show orientation differently.
JPEG or WebP output?
WebP for anything destined for the web: smaller at equal visual quality, universally supported by modern browsers. JPEG when the file must pass through older software — legacy upload forms, print pipelines, familiar photo viewers — that still rejects WebP. Trying WebP first costs nothing; fall back to JPEG only when a specific consumer of the file objects.
Is the image uploaded?
No — decoding, resizing and re-encoding all happen on your device through the canvas API, with no network round-trip. That makes the compressor usable on photos you would not send to any third-party service, and makes it fast: the only cost is a moment of local compute, which is why the tool works offline once the page has loaded.