The right picture, delivered into the wrong rectangle

A useful image can still arrive badly

The screenshot contains the right detail, but the phone shows it inside a much larger application window. The labels are now too small to read. A higher-resolution file would make that same composition sharper; it would not make the status panel bigger. I would decide what this image needs to explain before choosing its pixel sizes, then reserve the space so its arrival does not move the paragraph the reader is following.

A label that is tiny but sharp needs a different repair from one that occupies enough space but is blurred. The first points towards composition or layout; the second may need a suitable resolution candidate or less damaging compression. Inspect the rendered detail before regenerating files. Otherwise an export can add pixels without giving the explanation more usable space, or crop away context while solving a problem that was really delivery quality.

Consider a fictional article explaining a job-status screen. It contains a screenshot with a highlighted status panel. The desktop content column is at most 720 CSS pixels wide. On a narrow screen the image slot is 360 CSS pixels. The original capture is 2,400 pixels wide. These dimensions are illustrative layout inputs, not measurements from this website.

Compression reduces transfer size. The explanation still needs a crop that keeps the status and result link visible, an appropriate resolution for its slot and reserved space at the selected ratio. Work those decisions out separately. A smaller download can be a useful improvement while leaving the reader unable to inspect the very detail the article included the screenshot to show.

Separate resolution from composition

Resolution selection supplies different pixel sizes of the same composition. A 360 CSS-pixel slot on a display with a device-pixel ratio of two corresponds to a 720-pixel-wide rendering target. The browser can choose from declared image candidates using the layout and display conditions. That calculation is a planning aid, not a promise that every browser will select one exact file in every circumstance.

Art direction changes the composition. For the job-status article, the narrow view might crop to the relevant status panel instead of shrinking the entire application window. MDN’s responsive-image guide distinguishes these problems and describes the HTML mechanisms for each. Choosing a higher-resolution version does not repair a composition whose decisive label is still tiny.

For the narrow crop, keep the relationship the paragraph discusses. Here the status and result link need to appear together. A large badge without the link removes part of the evidence; the whole application shrunk to fit may make both unreadable. Remove unrelated interface detail only after deciding what the reader must retain. That makes the crop a change to the explanation, not just another way to squeeze the original file into a smaller rectangle.

Keep the screenshot honest. A crop can remove context that changes interpretation, including a warning or the fact that a screen is a demonstration. Include a caption or adjacent explanation where needed. For a diagram or interface figure with essential text, consider a native structured presentation or a focused detail rather than requiring the reader to decode a screenshot at all.

Reserve the space before the pixels arrive

An image’s intrinsic width and height can give the browser an aspect ratio before it finishes loading. With a responsive width and automatic height, a 720 by 405 image has a 16:9 ratio. In a 360 CSS-pixel-wide slot, its reserved height is 202.5 CSS pixels. That geometry helps the page keep the following paragraph in place.

The web.dev guidance on cumulative layout shift identifies images without dimensions as a common source of instability. It also distinguishes basic load measurements from shifts that can occur later in a page’s life. The practical implication is to inspect the reading journey, including below-the-fold images, rather than assume that one clean initial load proves every image will arrive without disruption.

The crop may change the ratio too. If the phone uses a square image, the wide view’s 16:9 reservation will leave unused space or force another geometry change. Give the selected composition matching dimensions or layout rules at the responsive boundary. The reserved area protects the following paragraph only when it describes the image the browser is about to display, rather than the one used in the desktop design.

These dimensions explain how to reserve space. A numerical layout-shift score needs an actual page session: it depends on which visible content moves, how far and under what conditions. Inspect the following paragraph during loading to see whether the reservation protects the reading position it was intended to preserve.

Tell the browser the size the layout will use

With width-described candidates, sizes tells the browser how much layout space the image is expected to occupy. A full-viewport value overstates a screenshot sitting inside a narrower article column. Check it against the production gutters, sidebar and padding before judging the browser’s resource choice. The browser is using the information the page supplied; it cannot infer that a copied declaration belonged to a different layout.

For the fictional layout, the image could use the available width below a maximum 720 CSS-pixel column, with page gutters accounted for in the actual rule. Provide suitable candidate widths and a fallback source. Check the rendered slot in the real stylesheet rather than assuming the design file and production layout still agree after a sidebar or padding change.

Pixel count can explain why the candidates differ without becoming a bandwidth claim. A 720 by 405 image contains 291,600 pixels. A 1,440 by 810 version contains 1,166,400 pixels, four times as many. Encoded file size does not necessarily scale fourfold: format, content and compression matter. Measure the actual assets when deciding the transfer budget.

Compression and priority follow the image’s job

Compression needs inspection at the screenshot's intended display size. Text and thin interface lines may degrade differently from a photograph, so compare the actual assets rather than applying one setting indiscriminately. In this example, the status wording and result link are acceptance details: reducing bytes while making either unreadable would weaken the explanation the image was included to support.

Loading priority also follows placement. An important image near the start of the page has different needs from an optional figure far below it. Blanket lazy loading can delay the image the reader needs first; eagerly loading every image spends resources before the person reaches them. Choose the strategy for the actual role and verify the resulting requests.

Review the asset as part of the page

An asset brief can record the explanatory purpose, required visible details, wide and narrow compositions, intended slots, candidate dimensions, reserved ratios and loading treatment. This connects each generated file to a deliberate layout decision. It also makes a later change reviewable: the team can identify which candidate or crop needs updating instead of inferring purpose from a growing set of similar screenshots.

For the job-status example, the required detail is the status, last update and result link. The narrow crop keeps those together. The wide view can include enough surrounding interface to orient the reader. Both need an appropriate text alternative or adjacent description according to their role, but that semantic work does not remove the need for correct delivery geometry.

Test a narrow screen, a wider screen and a higher-density display. Inspect the selected resource and actual slot, then watch the page while the image arrives over a slower connection. Scroll to the below-the-fold figure too. If the image fails, the article should retain its explanation and an understandable layout rather than leave an unlabelled gap where its central argument used to be.

There is no universal candidate set that suits every site. Too many variants increase build and maintenance work; too few can waste transfer or blur detail. Start with the layouts the page actually uses and add a candidate when it serves a measurable or plainly visible need. The point is a sensible delivery choice, not an exhaustive catalogue of possible screen widths.

Watch the status screenshot arrive on the actual page, then inspect its labels and result link at narrow and wide sizes. The file choice, crop and reserved geometry each need to do their job. If loading preserves the paragraph but the important label is still tiny, return to composition. If the label is clear but the paragraph jumps, return to the reservation. That gives the next repair a specific target instead of another round of compression applied to the wrong problem.