Practical guide · Image Compressor
Image too large to upload? Check size, format and pixels
An upload can fail because of its file size, pixel dimensions, format or aspect ratio. These are different constraints. Check the receiving form and keep the original image so that you can compare legibility after compression.
Open toolStep by step
- Open the upload-requirements mode and select an image or use the synthetic example.
- Enter the permitted format and maximum bytes. Pasted requirements are only suggestions until you review and apply them.
- Choose maximum pixel bounds or exact width and height according to the form. Keep full-image padding by default, or explicitly select and preview a crop. Choose the background; JPEG needs white or black.
- Run the conversion and compare the original with the exported pixels. Check small lettering, fine lines and any added canvas space.
- Download only a result marked as meeting the supported requirements, then try it in the receiving form.
Check the training image against its requirements
Before
Synthetic PNG · 960 × 640 px
After
Expected: JPEG · ≤ 200,000 bytes · ≤ 800 × 600 px · 4:3
Select maximum-bound mode, 200 KB and full-image placement with white padding. Allow smaller dimensions; leave cropping off for this exercise. These are the training package's requirements; the actual byte size must be checked after your run.
Try the actual example in the toolKB is not always KiB
200 KB means 200,000 bytes here. 200 KiB means 204,800 bytes. The workspace displays the exact byte limit, so you do not have to infer acceptance from a rounded size label. A receiving site may apply an additional rule that this tool does not know.
Pixel width and height are separate from compressed bytes. A highly detailed small image may weigh more than a much larger plain image. Changing a filename extension does not change the encoded format.
Preserve the content, review the compromise
The default placement scales the full image proportionally and adds padding where necessary. Crop-to-fill is a separate explicit choice: its position controls which edges are removed, so inspect the crop preview before export. White and black backgrounds flatten transparency; transparent PNG/WebP output preserves supported alpha. JPEG requires an opaque background.
The search tries at most 24 encoder settings. Maximum-bound mode may reduce pixels only when you allow it. Exact width and height stay fixed even if no quality setting fits the byte limit. The workflow never upscales: padding can accommodate a small original, while a crop requiring enlargement is rejected. A passing file can still be too soft for its intended use; inspect legibility as well as bytes.
An impossible limit is a useful result
A one-byte target cannot hold a usable JPEG. A bounded search can stop without producing a file that meets the chosen constraints. Increase an impossible limit or review the permitted dimensions, then try again. The quality-only compression mode remains available.
Different browser encoders can produce different byte sizes. Use the numbers shown by your own run and inspect the actual downloaded image; a previous example's size is not a promise for your file.
Repeat the exercise without a private photo
Use upload-example.png, the synthetic 960 × 640 image in the workflow training ZIP linked below. Set JPEG, 200 KB, maximum 800 × 600 pixels and ratio 4:3. Allow smaller dimensions. The image is fitted without cropping, with white padding where needed.
A passing download must decode as JPEG, contain at most 200,000 bytes, keep a 4:3 aspect ratio and fit within 800 × 600 pixels. Inspect the lettering and added canvas as well. Exact output bytes are deliberately unspecified because encoders differ. An unsuccessful search must show its reason and must not offer a passing download.
What is checked
The generated bytes are decoded again and checked against the supported format, dimensions, ratio and byte requirements. This checks the produced image, not the receiving service's undisclosed policies. Inputs are bounded to 10 MiB, 20 megapixels and 8,192 pixels per side. The requirements workflow accepts JPEG, PNG, WebP and supported HEIC/AVIF still variants; output PNG/JPEG/WebP encoders are probed. Animation and unsupported multi-image variants are rejected. Orientation is applied during decoding; source metadata is not copied. New 8-bit sRGB exports do not promise exact HDR, ICC or wide-gamut colour preservation.
Processing takes place in the private workspace. Opening it from this guide loads a separate document without advertising scripts. The separate PDF byte-limit mode rebuilds all pages as JPEG images after confirmation. In its two-page synthetic test, 3,242,478 source bytes became 170,394 bytes under a 200 KB target. Both 600 × 450 point pages remained. Searchable text and vector detail were deliberately lost; do not use this mode when those features are required.