Image Resizing: The Complete Guide to Dimensions, Resolution and Aspect Ratio

Resizing an image sounds simple: choose a smaller width, save the file, and move on. On the web, that is only one part of the decision. The image also has an intrinsic pixel size, a rendered size in CSS pixels, an aspect ratio, an encoded file size, and a relationship to the physical pixel density of the screen that displays it.

Those concepts are often collapsed into one vague word—resolution—which is why image-sizing advice becomes confusing. A 2400×1600-pixel photo can be displayed at 800 CSS pixels wide, downloaded at different source widths through srcset, cropped into a 16:9 hero, or compressed without changing its dimensions at all. Each operation changes something different.

Short version: choose dimensions from the destination backward. Know the largest rendered slot, preserve or deliberately change the aspect ratio, create source widths appropriate to the layout and likely display density, then compress the resulting delivery images. Do not start from a magic “web resolution” number.

Image resizing means changing pixel dimensions

For a raster image, resizing changes the number of pixels in the image. A 4000×3000 source resized to 1600×1200 still has the same 4:3 aspect ratio, but it contains far fewer pixels. If it is resized proportionally, the visual composition remains the same. If width and height are changed independently, the image can be stretched or squashed.

That makes resizing different from image compression. Compression changes how image information is encoded into bytes. Resizing changes the pixel grid itself. You can resize without aggressive compression, compress without resizing, or do both in one workflow.

The five measurements people accidentally mix together

1. Intrinsic pixel dimensions

The intrinsic dimensions are the image resource’s own width and height. A JPEG may be 2400×1600 pixels even if CSS displays it at 600×400. MDN describes intrinsic size as the image’s natural size before layout constraints change the rendered dimensions.

2. Rendered size

The rendered size is the space the image occupies in the page layout. It is commonly expressed in CSS pixels. A responsive image may render at 360 CSS pixels wide on a phone, 720 pixels inside a tablet layout, and 960 pixels inside a desktop article column.

3. Device pixels and device pixel ratio

A CSS pixel is not necessarily one physical screen pixel. On a 2× display, the browser may use roughly two device pixels in each dimension to render one CSS-pixel unit sharply. MDN’s devicePixelRatio documentation defines the value as the relationship between physical device pixels and CSS pixels.

This is why an image displayed at 600 CSS pixels wide may benefit from a source around 1200 pixels wide on a 2× display. Responsive-image markup lets the browser choose the most appropriate candidate rather than forcing every visitor to download the largest file.

4. Aspect ratio

Aspect ratio is the relationship between width and height. A 1200×800 image is 3:2. A 1600×900 image is 16:9. A square is 1:1. If you change one dimension while preserving the ratio, the other dimension follows automatically. If you force the image into a different ratio without cropping or containing it, distortion occurs.

5. Encoded file size

File size—KB or MB—is not the same as dimensions. Two 1600×900 images can have radically different file sizes depending on format, encoder settings, image complexity, metadata, and compression. Dimensions influence the amount of visual data available, but they do not uniquely determine bytes.

Downscaling, upscaling, cropping, and containing are different operations

Downscaling reduces pixel dimensions. It is one of the highest-leverage operations when the source is much larger than the layout needs.

Upscaling creates more pixels than the source originally contained. Traditional resampling estimates new pixels; it does not recover lost optical detail. Modern ML upscalers can produce plausible detail, but that still differs from having captured the detail in the original image.

Cropping removes pixels from the edges or another selected region to change composition or aspect ratio. Cropping can reduce dimensions, but its defining purpose is framing, not merely making the file smaller. See Crop vs Resize for the full distinction.

Contain/cover behavior can happen at layout time without rewriting the source image. CSS object-fit: contain keeps the entire image visible, potentially leaving empty space. object-fit: cover fills the box while preserving aspect ratio, clipping parts that do not fit. MDN documents both behaviors for replaced elements such as <img>.

How to calculate proportional dimensions

If you know the original width and height and want to preserve its aspect ratio, calculate the scale factor from one dimension.

For example, a 6000×4000 image is 3:2. To make it 1500 pixels wide:

1500 / 6000 = 0.25

Apply that factor to height:

4000 × 0.25 = 1000

The proportional output is 1500×1000.

You can also work directly from the ratio. For a 16:9 image at 1440 pixels wide:

1440 × 9 / 16 = 810

So the matching height is 810 pixels.

How large should a web image actually be?

There is no universal width that fits every site. The right dimensions come from the layout. A useful process is:

Measure the largest real display slot. A blog content image may never exceed 900 CSS pixels. A full-bleed hero may approach the viewport width.
Consider high-density displays. A 900 CSS-pixel slot may justify a source candidate around 1800 pixels for a 2× scenario.
Create a small set of responsive candidates. Do not ship one giant source to every viewport.
Let the browser choose. Use srcset and sizes when the image appears at different widths across layouts.
Compress each delivery candidate. The final byte budget still matters.

Web.dev and MDN both emphasize responsive-image selection rather than one oversized image for every screen. With width descriptors, the browser can use the expected slot size and display density to choose a suitable source.

Why width and height attributes still matter in responsive layouts

Setting HTML width and height does not mean the image must render at those exact fixed dimensions. CSS can still make the image fluid. The attributes provide the browser with the intrinsic aspect ratio early enough to reserve layout space before the image finishes downloading.

That helps reduce layout movement. MDN and web.dev both recommend supplying the image dimensions—or an equivalent aspect-ratio strategy—so the browser does not discover the space requirement only after the image arrives. This is also why our separate guide on image dimensions and CLS matters.

What “resolution” should mean for web work

For web delivery, the useful questions are usually pixel dimensions and display density—not a Photoshop-style 72, 96, or 300 PPI metadata value. A browser layout works in CSS pixels, and the same 1200×800 raster can still contain 1200×800 pixels whether metadata says 72 PPI or 300 PPI.

CSS does define an abstract relationship in which one CSS inch equals 96 CSS pixels, but that is a layout-unit definition, not a rule saying every exported web image must be tagged “96 DPI.” The more practical question is whether the resource has enough intrinsic pixels for the rendered slot and likely device pixel ratio. See Does DPI Matter for Web Images?.

When resizing improves performance the most

Resizing has the biggest payoff when the source dimensions greatly exceed what the layout can ever use. A 6000-pixel camera photo embedded in an 800-pixel content column can waste both transfer bytes and decode work even if its JPEG quality setting is reasonable.

Serving correctly sized images is a standard web-performance recommendation. Web.dev’s guidance on correct image dimensions explicitly connects right-sizing with avoiding unnecessary bytes. Combine that with the existing responsive images guide when one page needs several candidate widths.

When not to resize destructively

Keep an original master. Delivery images should usually be derivatives, not your only copy. A small web derivative cannot later recreate detail that was discarded when the original was downscaled.

Also avoid repeatedly resizing and recompressing the same derivative. Each generation can compound quality loss. Start from the best available source whenever you create a new output size.

Worked example: from camera original to responsive article image

Suppose the source is 6000×4000 and the article column tops out at 960 CSS pixels. The site also serves high-density screens.

A practical source set might be 480w, 960w, and 1920w. The browser does not need the 1920-pixel candidate for every visitor. A small screen can use the 480- or 960-pixel candidate, while a 960 CSS-pixel slot on a high-density display can choose the larger one when appropriate.

Each candidate should be encoded from the master, then compressed with a format and quality appropriate to the photograph. The HTML can still include intrinsic width and height so the browser knows the aspect ratio before load.

A practical resizing workflow

Keep the master untouched. Treat web images as delivery derivatives.
Measure the slot. Use the actual maximum rendered width, not the monitor width or camera resolution.
Choose the composition. Decide whether the original ratio works or whether the use case requires a crop.
Create only useful candidate widths. Avoid dozens of near-identical sizes.
Preserve aspect ratio unless distortion is intentional.
Encode from the master. Resize and compress in one controlled generation.
Use responsive markup when the layout varies.
Verify in the page. Inspect the network request and the rendered sharpness on representative screens.

Try resizing an image

Open the browser-based compressor, add an image, expand Advanced options, and enter a target width or height. The tool lets you resize and encode the new delivery file in the same local browser workflow.

Continue reading

Frequently asked questions

Does resizing an image reduce file size?

Usually, yes when you downscale a raster image, because fewer pixels need to be encoded. The exact byte reduction depends on format, compression settings, image complexity, and metadata. Resizing is not the same operation as compression even though both can reduce the final file size.

What happens if I resize only the width?

If the software preserves aspect ratio, the height is recalculated proportionally. In HTML/CSS, setting one dimension to a concrete size and leaving the other automatic generally allows the intrinsic ratio to be preserved.

Should web images be twice the displayed width?

Not as a universal rule. A 2× candidate is useful for many high-density displays, but responsive-image selection is better than forcing every user to download a 2× asset. Provide sensible candidate widths and let the browser choose according to slot size and display density.

Is 72 DPI required for web images?

No. For normal web rendering, pixel dimensions and the relationship between CSS pixels and device pixels are the useful variables. A PPI/DPI metadata value does not replace having the right pixel dimensions.

Sources and further reading

Editorial note

Browser image selection, CMS image generation, and device-density behavior evolve. This guide focuses on durable sizing principles and links to current browser documentation for implementation details that may change over time.

Continue the series8 parts

Image Resizing & Dimensions

A practical series on choosing, resizing, cropping, and delivering the right image dimensions for the web.

Image Resizing: The Complete Guide to Dimensions, Resolution and Aspect Ratio
How to Resize an Image Without Losing Visible Quality
Crop vs Resize: What’s the Difference?
Aspect Ratio Explained: How to Resize Images Without Stretching Them
Best Image Size for a Website: Hero, Banner, Blog and Content Images
Best Hero Image Size for Desktop and Mobile
Pixels vs Resolution vs File Size: What Actually Matters on the Web?
Does DPI Matter for Web Images? The 72 DPI Myth Explained