BlogImage Compression

How to Compress an Image Under 100KB, 500KB, 1MB, or 2MB

A target-size workflow for image upload limits: confirm the byte rule, preserve dimensions where possible, choose a format, and lower quality only as far as the image can tolerate.

Updated: August 1, 2026

Quick answer: Check whether the destination means under a byte ceiling or exactly a size, keep the original, remove optional metadata, choose dimensions and format for the destination, then adjust quality gradually until the downloaded file is safely below the limit.

Target-size compression is different from ordinary optimization. The question is not “what quality should I use?” but “what is the smallest change that gets this particular file under the receiving system’s rule?” A 100KB photo, a 100KB screenshot, and a 100KB transparent logo have very different limits.

The safest sequence is:

  1. read the upload rule precisely;
  2. preserve the original;
  3. remove optional metadata;
  4. decide whether dimensions may change;
  5. select a compatible format;
  6. adjust quality in small steps;
  7. verify the actual downloaded bytes and the visual result.

Under a Limit vs Exactly a Limit

Most upload forms mean no more than a maximum. In that case, a 486KB file satisfies a 500KB limit; it does not need to be exactly 500KB. Trying to fill every last byte can make quality worse with no benefit.

An exact target may be required by a particular workflow, but exactness is usually an application constraint rather than an image-quality goal. File headers, metadata, and encoder behavior mean the target must be checked after export. Use the smallest reliable margin the destination allows.

Also confirm the unit. “1MB” may mean 1,000,000 bytes or 1,048,576 bytes depending on the system. If the form does not document the unit, target below the displayed number and test an actual upload.

Which Target Fits Which Job?

TargetWhat it can be suitable forMain warning
100KBsmall avatars, signatures, simple forms, thumbnailsdetailed photos and screenshots may need fewer pixels
500KBmoderate web images, email attachments, document uploadstexture and text still need a visual check
1MBlarger photos, product images, high-detail uploadsmay still be too heavy for a page’s first screen
2MBhigher-detail submissions, large attachments, zoom-friendly copiesan upload limit is not a page-speed recommendation

These are starting contexts, not universal standards. The destination’s requirements and the image’s content decide the result.

Step 1: Confirm the File and Pixel Constraints

Write down:

  • maximum bytes and whether the limit is strict;
  • accepted extensions and MIME types;
  • maximum width and height;
  • whether transparency or animation is required;
  • whether the system recompresses after upload;
  • whether the image needs to remain printable or zoomable.

A 100KB target with a 2000×1500 minimum dimension is fundamentally different from a 100KB target with no dimension requirement. If you reduce the pixels, record that change so you do not mistake a smaller canvas for a better encoder.

Step 2: Keep the Master

Make a copy for target-size work and keep the original unchanged. Start every candidate from the master; repeatedly saving the same JPEG can compound artifacts and make later quality comparisons misleading.

If the image contains GPS, camera, or editing metadata that the recipient does not need, remove it from the delivery copy. Keep copyright, color-profile, or catalog information when the workflow depends on it.

Step 3: Choose Dimensions Before Extreme Compression

If the destination will display the image at 600px, sending a 4000px source and forcing it below 100KB is usually a poor trade. Resize to the largest useful display size first, preserving the aspect ratio. For a document or screenshot, preserve enough pixels for the smallest text the recipient must read.

For a website, generate responsive variants rather than treating the upload limit as the correct size for every viewport. Google’s image guidance and web.dev’s responsive image guide explain why delivery dimensions should match the rendered context.

Step 4: Pick a Compatible Format

Image contentFirst candidatesAvoid
PhotoJPEG, WebP, AVIFPNG when photographic texture makes it unnecessarily large
Screenshot or line artPNG, WebPaggressive JPEG if small text matters
Transparent graphicPNG, WebPJPEG, which has no alpha channel
Vector logoSVG where acceptedrasterizing solely to chase a byte target
Animationanimated WebP or GIF, or a video where acceptedflattening without checking the requirement

The MDN format guide is a useful reference for capabilities and fallback behavior. A smaller format is not useful if the form rejects it or the recipient cannot decode it.

Step 5: Search for the Best Quality That Fits

For a target-size tool or script, the practical approach is to find the highest visual quality that stays under the ceiling. A quality slider can be searched in steps; a pipeline can use a binary search over quality and then verify the output. If dimensions are allowed to change, the algorithm can alternate between quality and scale, but it should not silently destroy readability.

Conceptually:

  1. export a candidate at a conservative quality;
  2. measure its actual bytes;
  3. if it is too large, lower quality slightly or reduce dimensions if permitted;
  4. if it is comfortably below the limit, test a higher-quality candidate;
  5. keep the best candidate that passes the visual and compatibility checks.

Do not repeatedly recompress the last output. Re-export from the master at each step.

What to Expect at Each Target

Around 100KB

Start with the destination’s display dimensions. A simple avatar or cropped portrait may fit comfortably, while a noisy landscape or long screenshot may not. If text is important, preserve enough pixels and consider cropping empty space before lowering quality.

At this size, a visually perfect full-resolution photo may be unrealistic. The honest options are a smaller canvas, a crop, a different format, or a larger permitted limit.

Around 500KB

This target leaves more room for detail, but it still depends heavily on dimensions and texture. It can work well for a moderate photo or document upload. Compare gradients, faces, product labels, and small text at 100%, then inspect the result in the receiving form.

Around 1MB

Use this allowance for detail that genuinely needs it: a larger product photo, a readable document, or an image that will be viewed close to full size. A 1MB upload can still be excessive for a mobile hero image, so separate upload quality from website delivery quality.

Around 2MB

Two megabytes may be reasonable for a high-detail submission or attachment, but it is not a reason to send a 2MB image to every page visitor. Keep the large copy for the workflow that needs it and generate smaller responsive versions for the web.

Verification: Measure the Final File

After export, verify the file that will actually be uploaded:

  • inspect exact byte count, not only a rounded KB/MB label;
  • confirm extension and Content-Type expectations;
  • confirm width, height, color, alpha, and animation;
  • open the file in the destination application;
  • view photos, text, edges, and gradients at 100%;
  • check the real display size;
  • leave a safety margin below a strict ceiling.

If a platform changes the file after upload, check the delivered copy too. An accepted original can still become blurry or oversized after a transformation.

Privacy and Browser Processing

For ID documents, private photos, or client material, check whether a service uploads files to a server and how long it retains them. A local or browser-only workflow can be preferable when privacy is part of the requirement. Do not claim a tool is private without checking its current processing policy.

Common Mistakes

  • targeting an exact rounded number instead of the actual byte ceiling;
  • lowering quality before removing unnecessary pixels or metadata;
  • changing dimensions without recording the new canvas;
  • converting transparent images to JPEG;
  • judging a screenshot from a thumbnail;
  • using a 1MB upload copy as a web image for every viewport;
  • compressing the already-compressed output repeatedly;
  • forgetting that the receiving system may recompress.

Related LessMB Guides

Sources