How to reduce image file size while keeping the details you need

Keep the upload requirements visible while you work

To reduce an image below a size limit, first check the minimum pixel dimensions and accepted file formats. Then compare smaller dimensions, when allowed, and different encoding settings. A file that meets the byte limit but loses required text or uses a rejected format is not a usable result.

For illustration, suppose a form accepts JPEG or WebP, requires a width of at least 1,200 pixels, and limits each file to 200,000 bytes. These are invented conditions. Use the real form’s requirements in your own comparison.

Starting situation	First change to consider	What must stay true
Image already meets every condition	No change	It remains legible and accepted
Dimensions greatly exceed the requirement	Reduce dimensions proportionally	Minimum width and height are still met
Dimensions are required, but bytes are too high	Compare allowed formats and quality settings	Required details remain readable
PNG screenshot contains tiny text	Inspect text before accepting lossy output	Character shapes and thin lines remain usable
Even the lowest acceptable quality is too large	Review the permitted format or submission route	Do not silently sacrifice a mandatory condition

Keep an untouched original so every comparison starts from the same information.

Remove unnecessary pixels before aggressive quality changes

A 2,400 × 1,600 image contains 3,840,000 pixels. Reducing both dimensions by half gives 1,200 × 800, or 960,000 pixels: one quarter of the original count. The encoded file will not necessarily become one quarter as large. File size also depends on the image content, format, and encoder.

This is a calculation of pixel counts, not a compression benchmark. Adobe explains that downsampling removes image information. Only reduce dimensions when the remaining pixels meet the actual task.

Use the ratio lock in the image resizer. Changing width and height independently can distort the image. If a different aspect ratio is required, decide on the crop in an editor rather than treating stretching as a crop.

The resizer saves PNG. If the upload requires JPEG, convert that resized result to JPEG before judging its final file size. A smaller PNG is not automatically the smallest acceptable representation of a photograph.

Understand the quality control

In Tooliv’s compressor, quality controls the encoder while the image’s pixel dimensions stay unchanged. The browser’s Canvas API accepts a quality setting for formats that support lossy compression, such as JPEG and WebP; MDN documents that behavior.

A setting of 80 does not mean “80% of the original quality” or “20% fewer bytes.” The same number can produce different visible changes for different images. A photograph of foliage and a screenshot of small text place different demands on the encoder.

Leave Target size per image (KB, optional) empty to use the selected quality directly. Enter a target to let Tooliv try lower settings, with your selected quality as the upper limit. 1 KB means 1,000 bytes here: entering 200 checks the final file against 200,000 bytes. An original already within that budget is kept. A target is not a guarantee; inspect each file’s “Target met” or “Target not reached” status.

Compare each result with the original, not only with the previous compressed copy. Repeatedly using a degraded copy as the new source makes it harder to see which details have disappeared. If the target is not met, the resize link offers a next step, but reduce pixels only when the upload requirements allow it.

Check whether the format changed

Tooliv attempts WebP output when compressing a PNG. WebP supports both lossy and lossless compression, but that format capability does not mean every WebP export uses a lossless mode. Raising a quality slider to 100 is not proof of a lossless result.

If the receiver only accepts PNG, a smaller WebP does not solve the submission problem. Keep the format requirement visible and use the format selection guide when deciding which alternatives are allowed.

The compressor also keeps the original if the encoded candidate is at least as large. An “Original kept” result means that attempt did not provide a smaller file. It is a useful signal to reconsider excess pixels or permitted formats rather than assuming a download must have reduced the size.

Compare details at a useful viewing size

Download the candidate and check it at its intended display size. Also inspect a 100% view for defects that a small preview can hide. Select a few areas relevant to the task:

• A name, date, identifier, or other text that must be read accurately.
• Hair, fabric, or foliage when fine texture matters.
• High-contrast edges and thin diagonal lines.
• Smooth backgrounds where visible bands or blocks would be distracting.

For print, calculate the effective PPI at the intended size using the print-resolution walkthrough. A screen preview and a large print are different uses of the same pixels.

You can keep a comparison record with the candidate’s format, pixel dimensions, bytes, quality setting, and the details that passed or failed. Enter your own observations; there is no measured percentage reduction implied by this procedure.

Check the final bytes and know when to stop

Use the downloaded file’s actual size when the result is close to the limit. A rounded KB display can hide a small excess, and another upload system may define its units differently. Check whether the limit applies to one file or all attachments. Download ready images as ZIP packages usable results, including results marked “Target not reached”; review every status before submitting them.

If a required detail becomes unreadable before you reach the limit, restore a better candidate. A larger source, an allowed alternative format, a different upload route, or clarification from the receiver may be needed. Follow the complete image submission workflow before sending the final version.