How to Reduce Image File Size for the Web

The most reliable way to reduce an image for the web is to remove unnecessary pixels first, then choose an appropriate format and compression level. Moving a quality slider before checking dimensions often spends time optimizing data the browser never needed.

File size is shaped by several independent inputs: pixel dimensions, image content, format, encoder settings, transparency, animation, and metadata. Work through them in that order instead of chasing a single target percentage.

Start with a pixel budget

Suppose a product photo is 4000 × 3000 pixels. That is 12,000,000 pixels. The largest layout slot displays it at 800 CSS pixels wide, and you want a two-times-density source for sharper high-density screens. A 1600 × 1200 derivative contains 1,920,000 pixels.

Original pixels:  4000 × 3000 = 12,000,000
Useful derivative: 1600 × 1200 = 1,920,000
Reduction in pixel count: 1 - (1,920,000 / 12,000,000) = 84%

That is 84% fewer pixels for the encoder to describe. It does not guarantee an 84% reduction in file bytes: formats, image detail, noise, metadata, and settings affect the final result. It does show why resizing is often a higher-value first step than repeatedly recompressing the full camera export.

Do not resize to the CSS width alone when the design needs a higher-density candidate. Conversely, do not send the largest high-density asset to every screen. Create a small set of useful widths and let responsive markup select among them.

Use this order of operations

1. Preserve the original

Keep the camera file, design export, or other master unchanged. Produce web derivatives from that source so you can revise dimensions and settings without recompressing an already compressed copy.

2. Resize to realistic dimensions

Find the largest CSS width the asset can occupy and decide which device densities you support. A content image capped at 720 CSS pixels might need candidates around 480, 720, and 1440 pixels, rather than an arbitrary 4000-pixel original.

TinyImage's image resize tool can create a smaller-dimension PNG in the browser. If the source is a photograph, treat that PNG as an intermediate and follow it with an appropriate JPEG, WebP, or AVIF conversion and compression step.

3. Match the format to the content

The MDN image format guide recommends choosing by image characteristics rather than using one raster format for everything.

The file extension is not a guarantee of size. A photo stored as PNG may shrink substantially when converted to JPEG or WebP. A flat illustration with sharp edges may be smaller and cleaner as PNG or SVG. Compare representative output rather than relying on a format ranking.

4. Adjust quality in small steps

Quality values are encoder controls, not percentages of original quality. The web.dev JPEG guide notes that different tools do not interpret a value such as 75 identically, and the visible result depends on the image itself.

Start from a moderate setting, inspect the image at its intended display size, and change the setting in small increments. Pay particular attention to:

• text and hard boundaries;
• skin, hair, leaves, and fabric;
• skies, shadows, and other smooth gradients;
• saturated colors beside neutral backgrounds;
• semi-transparent edges.

TinyImage starts its quality control at 75 and offers five-point steps. That makes 75 a practical test point within TinyImage, not a universal standard for other encoders. The guide to image compression settings explains a fuller comparison method.

5. Review metadata deliberately

Camera and editing files may include location data, capture settings, embedded thumbnails, color profiles, copyright fields, and orientation instructions. Removing nonessential metadata can save some bytes, but the effect varies and useful information can be lost.

Preserve the color profile when consistent appearance is important. Preserve rights information when a publishing workflow depends on it. If orientation metadata is removed, make sure the pixels have first been rotated into the correct display orientation.

6. Generate responsive variants

One compressed file is still wasteful if it is sized for the widest desktop and sent to a narrow phone. The web.dev responsive image guidance separates two jobs:

• srcset and sizes describe alternative dimensions so the browser can choose a candidate;
• <picture> gives explicit control over format or art-direction alternatives.

For one image with the same crop at three widths:

<img
  src="article-960.webp"
  srcset="article-480.webp 480w, article-960.webp 960w, article-1440.webp 1440w"
  sizes="(min-width: 960px) 960px, 100vw"
  width="1440"
  height="960"
  alt="Close-up of a printed photo beside its web export"
>

Replace the example sizes rule with the real rendered slot. An inaccurate value can lead the browser to select a larger candidate than necessary.

A practical TinyImage workflow

1. Use the website image analyzer to identify possible same-format compression savings on a public page.
2. Check the displayed and intrinsic dimensions in browser developer tools.
3. Resize a copy when the source is materially larger than its useful high-density width.
4. Choose a delivery format. For a photo-heavy PNG that does not need transparency, the PNG to JPEG converter is one option. For a modern website, compare WebP or AVIF as well.
5. Run the chosen derivative through the relevant image compressor.
6. Compare appearance, bytes, transparency, and dimensions before replacing the published asset.
7. Add responsive candidates and verify which source the browser selects at representative layouts.

The analyzer estimates compression opportunity; it does not determine the right dimensions, format, loading priority, or Core Web Vitals result. Those checks remain part of the publishing workflow.

Mistakes that leave files larger than necessary

• Changing only CSS dimensions. The browser still downloads the full source unless responsive image markup selects another file.
• Converting every image to PNG. Lossless PNG is often a poor delivery choice for detailed photographs.
• Assuming every conversion is smaller. An already efficient source can produce a larger output in another format.
• Recompressing the latest derivative. Return to the master to avoid compounding lossy artifacts.
• Removing transparency by accident. JPEG has no alpha channel; transparent pixels must be flattened against a background.
• Using quality 100 by habit. It can add bytes without a visible benefit at the final display size.
• Optimizing one image and ignoring selection. A good 1440-pixel file is still the wrong response for a 320-pixel slot if no smaller candidate exists.

Common questions

Does changing DPI reduce image file size for a website?

Changing only a DPI metadata value usually does not remove pixels. Browsers size raster images using pixel dimensions and CSS layout. Reduce the actual width and height when the source contains unnecessary pixels.

Can I reduce file size without changing dimensions?

Yes. Re-encoding, adjusting lossy quality, optimizing a lossless representation, reducing a palette, or removing metadata may help. The available savings depend on the source.

Why did conversion make my image larger?

The original may already be efficiently encoded, or the new format and settings may be a poor match for its content. Compare the bytes and keep the original when conversion offers no useful benefit.

Should website images be below a specific number of kilobytes?

There is no single useful limit for every placement. A full-width editorial hero and a small icon have different visual and layout requirements. Set budgets by component and total page weight, then measure real loading behavior.

Should I compress first or resize first?

Resize a copy to its required dimensions first, then encode and compress the derivative. This prevents spending work on pixels that will be discarded and avoids an additional lossy generation.