Image File Sizes Explained: KB, MB, and Smart Compression

File size is one of the most consequential properties of a digital image, yet it is rarely understood deeply. It determines how fast a page loads, how much storage you pay for, how quickly images upload to social platforms, and whether email attachments get through. Understanding what drives image file size — and how to intelligently reduce it — is a foundational skill for anyone working with digital images professionally.

What a File Size Number Actually Represents

When a file is described as "2 MB," what does that mean concretely? One byte is 8 bits — the basic unit of digital data, representing one of 256 possible values. A kilobyte (KB) is 1,024 bytes. A megabyte (MB) is 1,024 kilobytes, or 1,048,576 bytes.

A standard colour digital image stores three colour channel values per pixel: red, green, and blue. At 8 bits per channel (the standard for most display-ready images), that is 3 bytes per pixel. So a 4000 × 3000 pixel photograph contains 12 million pixels × 3 bytes = 36 megabytes of raw pixel data.

In practice, we never store images at raw size because compression makes them dramatically smaller. A 36 MB raw photo saved as JPEG at 90% quality might be 6–8 MB. Saved as WebP at 85% quality, it might be 3–4 MB. The compression ratio — how much smaller the compressed file is compared to the raw data — is what image formats are designed to maximise while preserving visual quality.

The Three Factors That Determine File Size

Factor 1: Pixel dimensions. The number of pixels in an image directly determines the maximum possible file size. A 4000 × 3000 image has 4× as many pixels as a 2000 × 1500 image — and will always produce a larger file, all else being equal. This is why resizing before compressing is the most effective size reduction strategy: it removes pixels that do not need to be compressed in the first place.

Factor 2: Colour depth. Most images use 8 bits per channel (24-bit colour total, often called "true colour"). High dynamic range (HDR) images use 10 or 12 bits per channel. Higher bit depth stores finer colour gradations but increases the raw data size by 25–50%. For web delivery, 8-bit is almost always appropriate.

Factor 3: Compression algorithm. Different formats use different mathematical algorithms to represent pixel data more compactly. The effectiveness of the algorithm — and the aggressiveness of the compression level you choose — determines how small the final file is for a given quality target.

How Lossy Compression Works

JPEG compression uses Discrete Cosine Transform (DCT): it divides the image into 8×8 pixel blocks, converts each block from spatial representation (pixel colours) to frequency representation (how rapidly colours change within the block), and discards high-frequency components (fine detail) according to the quality setting.

Higher quality settings preserve more high-frequency detail, producing larger files but sharper images. Lower quality settings discard more detail, producing smaller files but visible artefacts (blockiness, ringing around edges, colour banding).

The key insight is that the human visual system is more sensitive to luminance (brightness) information than to chrominance (colour) information. JPEG exploits this by applying less aggressive compression to luminance and more aggressive compression to colour — a technique called chroma subsampling. This is why JPEG is well-suited to photographs (which have gradual colour transitions) but poor for text and graphics (which have abrupt, hard edges that become blocky under chroma subsampling).

WebP's compression algorithm (based on VP8 video encoding) is more sophisticated and produces smaller files at the same quality level, primarily because it uses larger block sizes (up to 16×16 in some modes) and more complex prediction modes that better exploit spatial correlations in photographic content.

Smart Compression: Finding the Minimum Quality Threshold

The goal of smart compression is not to set an arbitrary quality number (like "always use 85%") but to find the minimum quality level at which the compressed image is perceptually indistinguishable from the original at its intended display size.

This threshold varies significantly by image content:

• Images with fine, high-contrast detail (tree branches against sky, text, geometric patterns) require higher quality settings to avoid visible artefacts.
• Images with large areas of similar colour (blue sky, solid-coloured walls, product backgrounds) can be compressed much more aggressively with no visible difference.

A sophisticated compression approach tests multiple quality levels and measures the Structural Similarity Index (SSIM) or Perceptual Hash distance between the compressed and original image. The minimum quality level that keeps this distance below a perceptual threshold is selected automatically.

Practical Size Targets by Use Case

| Context | Target file size | Notes |

|---|---|---|

| LCP hero image | 50–150 KB | Critical — directly impacts Core Web Vitals |

| Blog body images | 80–200 KB | Balance between quality and page weight |

| E-commerce product | 100–300 KB | Needs zoom quality; use multiple sizes for srcset |

| Email newsletter | 50–100 KB | Many email clients have total size limits |

| Social media upload | 300–500 KB | Platforms re-compress anyway; don't over-optimise |

| PNG icon / logo | 5–30 KB | Or use SVG instead for infinite scalability |

The Resize-First Rule

The single most common mistake in image compression is compressing an image without first resizing it to the intended display dimensions. Here is why:

If your image will display at 800px wide on a web page, there is no reason to compress a 4000px-wide image — you are compressing four times more pixel data than necessary. The correct sequence:

1. Resize to target display dimensions (e.g., 800 × 533 for a 3:2 image displayed 800px wide)
2. Compress the resized image

This almost always produces a smaller file at higher visual quality than compressing the full-size image, because:

• The compressed file starts with fewer pixels
• The compression algorithm operates on less data, producing less artefact spread
• The output file is already the right size — no browser-side scaling needed

Understanding PNG Optimization

PNG is lossless — every pixel is preserved exactly. But PNG files often contain significant non-display data:

• Metadata chunks: ICC colour profiles, camera EXIF data, GPS coordinates, editing history
• Ancillary chunks: Text comments, creation dates, software information
• Suboptimal compression settings: The initial compression may not have used the optimal deflate compression parameters

PNG optimisation tools (like those inside the Imgira Compressor) strip non-display metadata and re-compress using optimal parameters — without touching a single display pixel. This purely lossless optimisation can reduce PNG file sizes by 10–40%.

Measuring Compression Success

After compressing, measure the result:

1. File size: Check absolute file size and percentage reduction from original.
2. Visual quality: Open the compressed file at 100% zoom (1 pixel = 1 screen pixel) and compare to the original. Look specifically at edges (text, hair, product edges) and smooth gradients (sky, skin tones) — these are where artefacts appear first.
3. Structural similarity: Tools like Squoosh (Google's open-source tool) show SSIM scores alongside visual comparison. An SSIM above 0.90 is generally considered perceptually lossless at normal viewing distances.

A good compression result achieves 40–70% file size reduction with no perceptible quality difference at the intended display size. If you can spot a difference at 100% zoom but not at 50% zoom, the compression is likely appropriate for web use where the image will not be displayed at 1:1 pixel ratio.