Image Compressor Guide
Reference for image compression decisions: supported input, target bytes, dimension limits, transparency, encoder support, failed exports, and a reproducible result checklist.
Start with the receiving system
Image Compressor re-encodes a browser-readable JPG, PNG or WebP using canvas. It is useful when an image already contains the right subject but its dimensions, format, or file size do not suit the next destination. Keep the original. Before changing controls, check what the receiving app actually accepts: format, maximum bytes, required dimensions, and whether transparency matters.
A photograph for a product listing and a screenshot containing small text need different review criteria. A smaller output is not automatically the correct output. If an export becomes blurry, loses required transparency, or is larger than the source, keep the source and change one setting at a time.
Supported input and configured limits
The compressor accepts files identified as image/jpeg, image/png, or image/webp. Its file limit is 15 × 1,024 × 1,024 bytes, displayed as 15 MB in the interface. This is not the broader input policy of the separate format converter: the compressor does not promise HEIC, SVG, GIF, TIFF, or AVIF input. Renaming a file extension does not convert its contents or make a rejected file valid.
The interface accepts up to 20 images for a batch. Start with one representative file before selecting a batch. Successful results remain available if another item fails; inspect each item's status rather than assuming a completed batch means every image succeeded.
Output is limited to 36,000,000 pixels. Dimension controls cap a side at 8,000 pixels. These are application limits, not measurements proving that every supported browser or phone can handle an image of that size. Decoding the source also consumes memory before a smaller output can be produced.
Format and quality controls
| Output | Decision to make | Important boundary |
|---|---|---|
| JPEG | Use for photographs when the destination accepts JPG. | Transparent areas are filled with white. |
| PNG | Keep lossless graphics or transparency when appropriate. | The lossy quality setting does not make PNG smaller. |
| WebP | Try it when the destination accepts WebP. | Review text, edges, transparency, and actual output size. |
| AVIF | Use only when the current browser can encode it and the destination accepts it. | Display support alone does not establish export support. |
Unsupported exports are rejected rather than relabeled as the requested format. An AVIF preset is not evidence that AVIF encoding is available in your browser. Switch to WebP, JPEG, or PNG when an encoder is unavailable. No cross-browser speed or quality ranking is claimed by this table.
Dimension limits preserve the frame
Limit dimensions fits the image inside both the maximum width and height while preserving aspect ratio and avoiding upscaling. A 4,000 × 3,000 photograph inside a 1,600 × 1,600 box becomes 1,600 × 1,200. An 800 × 800 square inside an 800 × 450 box becomes 450 × 450. The width limit alone does not determine the result.
A 600 × 400 source stays 600 × 400 inside a 1,600 × 1,600 box. These are calculations from the sizing rule, not measured compression results. Check both output dimensions before proceeding. Use Image Cropper first when you need a different frame, or Image Resizer when dimensions are the main task.
Target bytes are a search, not a guarantee
Target-size mode tries different encoding quality values at the selected dimensions. The implementation makes eight attempts by default and selects the highest-quality attempted result that fits the target, or the smallest attempted output when none fits. It does not guarantee a globally optimal result or automatically reduce dimensions to make an impossible target fit. PNG is not supported by the target-size search.
The minimum target input is 10 KB. The tool uses 1,024 bytes per displayed KB, so entering 200 means 204,800 bytes. A destination requiring at most 200,000 bytes is a different constraint: entering 195 gives a 199,680-byte target, but the output must still actually reach it. Read the result and inspect the downloaded file's bytes rather than relying on a rounded size label.
If the target is missed, reduce dimensions, choose another supported format, or reconsider the destination's requirement. Restart from the original for the next comparison; repeatedly recompressing an already degraded export can hide which change caused the damage.
Why a successful export can be worse
Our existing measured image case reports a 156,833-byte PNG re-exported as a 190,496-byte PNG. WebP at quality 82 was smaller for that sample, but its 10 KiB target was missed. Those observations belong to that published sample, not to a new benchmark or a guarantee for other inputs.
Compare small lettering, edges, gradients, and transparent corners at the intended display size. Also reopen the downloaded file in its destination app. Canvas export can change metadata and color handling; compression is not a certified metadata-removal procedure or a color-managed archival workflow. Retain a controlled original when those properties must be preserved.
Diagnose failure before retrying
| Symptom | What to check | Recovery |
|---|---|---|
| File is rejected | Compare the MIME type with accepted types and the source bytes with the file limit. | Export a real JPG, PNG, or WebP from the source application. |
| Decoding fails | The file may be damaged or unsupported by this browser. | Open it locally first and re-export a readable copy. |
| Output is too large | The width multiplied by height exceeds the output pixel limit. | Enable dimension limits and retry with a smaller box. |
| Format fallback is rejected | The canvas encoder did not return the requested MIME type. | Choose an available format instead of changing the filename. |
| Target is missed | The chosen dimensions and format remain too expensive. | Reduce dimensions or relax the byte target; verify the next result. |
For a constrained phone, begin with a small image and close unrelated heavy tabs. A small compressed source can still decode to many pixels. A desktop tool is a reasonable fallback when the browser cannot hold the source or the job needs animation preservation, strict color management, or very large batches. Repeating the same failed operation does not establish compatibility.
Record a result another person can check
Keep a simple comparison record: source format, source bytes and dimensions, output format, quality or target setting, dimension cap, actual output bytes and dimensions, and whether the target was reached. Add the browser version and device when reporting a problem. Record elapsed time only if you measured it; do not copy someone else's timing into your result.
Use the tool's locally generated sample or a non-sensitive fixture to reproduce a failure. A useful bug report explains the expected result, actual result, and smallest reproducible input. It does not need your customer photograph, private screenshot, or original filename. Separate visual judgment from arithmetic: dimensions can be correct while text is unreadable.
Local processing and the next step
The image operation runs on your device, but loading a website is not a zero-network activity. Application resources, delivery and security services, and measurement under the site's stated settings are separate from image encoding. Review Data handling and the local-file privacy check before processing sensitive material.
Keep the original until the downloaded output passes the receiving system's format, byte, dimension, and visual checks. The useful endpoint is a file that works for its intended purpose, not the smallest number the compressor can display.