Compress to KB

Quick Answer

Compress to KB hits a target file size in KB for one PNG, JPG or WebP image. It first sweeps the encoder quality in the source format, keeps the original dimensions whenever it can, and only changes format or scales dimensions when the budget cannot be met at the source settings. The result panel reports the measured original size, output size, quality and any format or scale change as honest notes — there is no promised reduction and no exact-KB guarantee. The same Pillow encoders (JPEG, PNG and WebP) used by the Image Compressor power the sweep.

Compressing for the web

Image compression only matters in the context of a real page delivery budget. Chrome for Developers publishes the Lighthouse audits PageSpeed Insights actually run, and the two audits that touch images are stated independently:

• Efficiently encode images asks whether the file could have been smaller at the same rendered dimensions by using a more efficient format or encoder. Per the Chrome for Developers audit docs, the threshold is approximately 4 KiB of potential savings per image.
• Properly size images asks whether the rendered display size on the page is meaningfully smaller than the source's intrinsic pixel dimensions. The Lighthouse audit flags an image when the displayed pixel size is far smaller than the file's actual pixel size, regardless of compression level.

Compress to KB is for the case where a destination enforces a specific byte cap — an email attachment, a CMS upload form, a mobile push payload. It is not the same as targeting the Efficiently encode images audit, which judges the file against the format at the same rendered dimensions; a file that passes this tool's KB budget can still fail that audit if the dimensions are wrong for the layout, and a file that passes the audit can still fail this tool's budget if the budget is smaller than the encoder can hit. The two checks are independent and the page must address both to clear the image-delivery section of a Lighthouse run.

Common mistakes with target-size compression

Five issues that come up most often when compressing to a byte budget. Each one is rooted in the encoder behaviour rather than in this specific tool.

• Treating the target as a guaranteed hit. The encoder sweeps quality in the source format first; if the quality floor still exceeds the budget, the tool may change format or scale dimensions. If even that cannot fit the budget, the result panel shows the smallest best-effort file and a "Could not reach N KB under the current constraints" note — that is honest reporting, not a bug. If the file you upload is already smaller than the target, the panel shows the source bytes (or a same-format re-encode if it shrinks further) and reports met-target without changing anything.
• Confusing "scaled to fit budget" with a deliberate resize. Compress to KB never upscales. It only steps dimensions down — by 10%, 20%, 30%, 40%, 50% — when the encoder cannot hit the budget at the source size. The result panel calls the change out explicitly so the user can decide whether to keep the smaller file or relax the budget. A user who wants a specific canvas size should use a resizer first (Social Media Image Resizer, Amazon / Shopify / Etsy Product Image Resizers), not rely on this tool's last-resort downscale.
• Letting a PNG with transparency become a JPEG on white. When "Keep original format" is on and the budget cannot be met in PNG, the tool falls back to WebP lossy with alpha kept, or further to JPEG when even WebP does not fit. JPEG cannot carry transparency, so the result panel lists a "transparent pixels were flattened onto white" note when this happens. If transparency must survive, raise the budget, raise the dimensions, or uncheck "Keep original format" to allow WebP-with-alpha to be picked earlier in the sweep.
• Running it on a source whose bytes are already below the target. A source at 60 KB with a 100 KB target does not need compression at all. The tool reports "Source already under target" and either keeps the source bytes or returns a same-format re-encode if it shrinks further. The result panel is honest about this; do not treat the unchanged output as a tool bug.
• Reading "Could not reach X KB" as a failure. Some sources cannot be compressed to a tight budget without either making the image visibly worse than the source or scaling dimensions past a useful size. When that happens the panel shows the smallest file the encoders can produce and a note that the target was not met. Treat it as a signal to relax the budget, pick a different source, or accept the best-effort file as-is.

Check the output

Compress to KB can change format and dimensions to hit a budget. The result panel reports the measured original size, output size, format and dimensions; the four-point checklist below is the validation pass a responsible shipper runs once per output before uploading it anywhere.

• Dimensions. Confirm the output width and height match the destination display slot. Compression does not change dimensions by default; if the panel shows "Scaled to fit budget", the dimensions stepped down and the file may be smaller than you want for the layout. The Resize vs Compress guide covers the relationship between pixel count and byte count, and the Optimize Images for the Web guide covers when resizing the canvas is the right first step. Chrome for Developers' Properly size images Lighthouse audit flags images whose intrinsic dimensions far exceed the rendered slot.
• File size. Confirm the output bytes are at or below the target. The result panel reports met-target (green) or best-effort (amber) and the measured size. If the panel says best-effort and the file is still over the destination's documented limit, relax the budget, raise the source dimensions, or pick a different source — the encoders cannot hit a budget that is smaller than the file's compressed representation at the current size and format.
• Format and transparency. This is the check unique to a budget-driven tool. The output may be in a different format than the source — a PNG can become WebP or JPEG, a JPEG can become WebP, a WebP can become JPEG. The result panel labels the output format and lists any format change as a note. If the source had transparency and the output is JPEG, alpha was flattened onto white; the panel notes that. If you need transparency to survive, the output must be PNG or WebP, so raise the budget or uncheck "Keep original format" to allow WebP-with-alpha earlier. A dedicated walkthrough of PNG / WebP / JPEG transparency behaviour lives on the Transparent image formats guide.
• Real destination. Upload the final file to the actual page, CMS, email or design tool where it will be used, and view it there. Browser preview, design-tool preview and the live page can render colour, transparency and layout differently; the live destination is the only check that catches all of them at once. The Optimize Images for the Web guide recommends the same final check on the live page, and it is the last step before the file is shipped.

What the tool actually changes

A target-size compressor that only re-encoded in the source format would fail on tight budgets. This tool runs a multi-strategy pass: it tries the source format first, then format fallbacks, then a stepwise downscale, and reports which strategy produced the output. The behaviour below is the real path the workflow runs, not marketing shorthand.

The strategy is anchored to Pillow's encoder behaviour and the LANCZOS downscale documented in Pillow's resize reference; the strategy order is the one this tool actually runs in compress_to_target.py, not a marketing summary.

Reading the result panel

The result panel reports three measured values: the original file size, the output file size and the target. There is no promised reduction and no exact-KB guarantee — the panel shows the same numbers a file-size tool would measure on the source and output bytes. The result also reports the format, the quality and any format or scale notes as a list, so the user can see exactly which strategy the tool picked.

Three outcomes are possible, and all three are shown honestly:

• Met target. The output is at or under the KB target. The panel shows the measured bytes and the format / quality / scale notes that describe which strategy produced the output. This is the common case for moderate budgets on already-optimised sources.
• Best effort, target not met. The encoders cannot reach the budget at the current size and format. The panel shows the smallest file the encoders can produce and a "Could not reach X KB" note. The fix is to relax the budget, raise the source dimensions, or pick a different source — the tool is not hiding a smaller file behind a higher number.
• Source already under target. The source bytes are already smaller than the target. The panel either keeps the source bytes unchanged or returns a same-format re-encode that is at least as small. Treat this as "no compression was needed".

The bytes shown on the panel are the source's own measurement, not an average for the format. Treat them as one data point: they tell you what happened on this specific file, not what will happen on the next file you compress.

Compress to KB vs Image Compressor

The two workflows answer different questions and they pair well rather than overlap. The Image Compressor uses one balanced default per format and never changes format or dimensions. The Compress to KB sweeps quality toward a user-set KB budget and may change format (PNG → WebP, PNG → JPEG) or scale dimensions when the budget cannot be met at the source settings. Use the Image Compressor when the destination already accepts the source format and there is no byte budget. Use this Compress to KB when a destination asks for "under X KB" or "max Y KB".

Both tools report measured sizes on the result panel, not promised reductions. Compress to KB is honest about the cases where the target cannot be hit — the panel shows the best-effort file and a "Could not reach X KB" note rather than padding the result. The right tool for a given file depends on whether the destination enforces a byte budget or just wants the smallest file in the same format; the two tools together cover both ends of that question.