What an Image Costs

1. Big bytes, big value

Images are the heaviest thing most pages send. The HTTP Archive crawls millions of sites every month and publishes what it finds in its annual Web Almanac. In the July 2025 crawl, the median home page weighed about 2.9 MB on desktop and 2.6 MB on mobile, and the median home page loaded 1,058 KB of images on desktop and 911 KB on mobile, from around 19 image files.

Medians hide the tail. A median means half of all home pages send more than this, and the heaviest pages send many megabytes of images, often a single photograph straight from a camera. A phone on a slow or metered connection pays for every one of those bytes in time, battery and money.

The reason images are so heavy is also the reason they are worth it. Images carry information that text carries badly: what a product looks like, where a place is, how a chart trends, who is speaking. They set a mood before a word is read. A page without them is often harder to use, not easier.

So images are both a large cost and a large value, and the evidence cuts both ways. A 2016 study of real-user data by SOASTA and Google found that the number of images on a page was the second-best predictor of whether a mobile visit ended in a sale: visits that converted had loaded 38 percent fewer images than visits that did not. The point is not that images hurt. It is that unnecessary images hurt, because they slow the page down and dilute the ones that matter.

2. The first question: do you need the image?

The techniques for using images efficiently have not changed much in twenty-five years, because the problem has not changed: a picture is a lot of data, and the network is the slowest part of the system. The techniques come in a fixed order, from the most effective to the least:

The order matters because the savings multiply. An image you remove costs nothing, however well it would have been compressed. An image you keep but send at the right size and format may be a twentieth of the original. An image that is small and lazy-loaded may never be downloaded at all by a reader who never scrolls to it.

Elimination is the step people skip, because it is a design decision rather than an engineering one. It asks what the image is for. A photograph of the actual product is the content. A stock photograph of smiling people at a laptop, placed above a sign-up form, usually is not: it costs a reader on a slow phone several seconds and tells them nothing. The course's attitude is the same one it takes to every resource: the reader's time and data are not ours to spend carelessly.

3. Raster and vector

A computer can store a picture in two fundamentally different ways.

A raster image (also called a bitmap) is a grid of dots, each with its own color. The file records every dot, or a compressed description of them. JPEG, PNG, GIF, WebP and AVIF are raster formats. A raster image is good at anything photographic, where every dot really is different from its neighbors.

A vector image is a list of drawing instructions: a circle of this radius here, a path through these points, filled with this color. The file records shapes, not dots. On the web, the vector format is SVG (Scalable Vector Graphics), an XML language that browsers draw natively. A vector image is good at logos, icons, diagrams, charts and illustrations: anything made of shapes.

The difference shows when the image changes size. Scale a raster image up and the browser has to invent pixels that were never stored, so it blurs or turns blocky. Scale a vector up and the browser simply draws the shapes bigger: the edge stays sharp at any zoom and on any screen. That is why vector images are called resolution independent.

The difference also shows in the file size. The Trail Notes logo used across this section is a few circles, paths and two words of text:

Vector is not always the answer. A photograph has no shapes to describe, only millions of slightly different dots, and an attempt to trace one into paths produces a file far larger than a JPEG and still looks wrong. A complex illustration with thousands of paths can also outweigh a raster version. And every vector is turned into pixels in the end: the screen is a grid, so the browser rasterizes the SVG every time it draws it, at whatever size the layout asks for. The vector's advantage is that the rasterizing happens at the last moment, on the reader's screen, at the exact size needed.

The rule of thumb for the rest of the section: SVG for anything drawn, raster for anything photographed. SVG and vector images (page 03 of this section) covers SVG in depth.

4. Pixels, bit depth and pixel math

A pixel ("picture element") is one dot of a raster image. Each pixel stores a color, and the number of bits used to store that color is the image's bit depth:

From there, the cost of an uncompressed image is simple arithmetic: width × height × bytes per pixel. The deck's classic example is a 640 by 480 screen at 8 bits: 640 × 480 × 1 = 307,200 bytes, about 300 KB, for a picture smaller than a postage stamp on a modern laptop. The daisy photograph this section uses, at 800 by 533 pixels in 24-bit color, is 800 × 533 × 3 = 1,279,200 bytes before compression.

Nobody sends raw pixels. Every web format compresses them, either without losing anything (lossless) or by discarding detail the eye is unlikely to miss (lossy). Raster formats (page 02) explains how. For now, the scale of the difference is the lesson:

Two lessons hide in that chart. First, format choice is worth a factor of ten or more: a lossless PNG of a photograph is the right format for the wrong job. Second, once the format is right, the remaining differences between good formats are real but smaller, a factor of about two between JPEG and AVIF here.

Pixels cost memory too

Compression only helps on the wire. To draw an image, the browser decodes it back into raw pixels in memory, usually at four bytes per pixel. The daisy that arrives as 11,840 bytes takes 800 × 533 × 4 = 1,705,600 bytes of memory once decoded. A 4000 by 3000 photograph straight from a phone camera, scaled down by CSS to fill a 400-pixel column, still decodes all 12 million pixels: 48 MB of memory, and the time to decode them, for a picture the reader sees at a hundredth of that. Sending an image larger than it is displayed wastes the network, the processor and the memory, which is why Images in HTML (page 04) spends so long on sending the right size.

5. CSS pixels and device pixels

The word "pixel" means two different things on the web, and keeping them apart is essential.

A device pixel is one physical dot on the screen. A CSS pixel is a unit of length in CSS. It was defined so that one CSS pixel looks about the same size on any screen at a normal viewing distance (formally, 1/96 of an inch), which means it is not tied to the hardware at all. The Values page covers the CSS pixel as a unit.

On an older desktop monitor, one CSS pixel is one device pixel. On a phone or a modern laptop, the screen packs in two or three device pixels for every CSS pixel in each direction, so text and edges look smoother. The ratio is the device pixel ratio, or DPR, and the browser exposes it to JavaScript as window.devicePixelRatio.

For text and vectors, high DPR is free: the browser draws them at the device's full resolution. For raster images it is not. An image laid out 400 CSS pixels wide covers 400 device pixels at DPR 1, 800 at DPR 2 and 1,200 at DPR 3. To look sharp at DPR 2 the file needs to be 800 pixels wide, and that is four times the pixels, not two.

Doubling the width quadrupled the raw pixels and multiplied the compressed bytes by about three and a half: compression does a little better on larger images, because neighboring pixels are more alike. Either way, a "2x" image is far more than twice the cost, and a "3x" image is more again.

This is the tension that responsive images resolve. A reader with a high-density phone benefits from a sharper image; a reader on a desktop monitor gains nothing from it and pays the same bytes. The answer, which Images in HTML (page 04) teaches, is to offer several sizes and let the browser, which knows the screen, choose. The answer is not to send the largest image to everyone. Beyond about DPR 2, most people cannot see the extra detail in a photograph at normal viewing distance, so many sites deliberately cap the density they serve.

6. Content images and presentational images

Every image on a page does one of two jobs, and the job decides how it is written.

A content image is part of what the page says: a product photograph, a diagram that explains, a chart with data, a portrait of the person quoted. Remove it and the reader loses information. Content images belong in the HTML, as <img> (or <picture> or inline <svg>), with alternative text that conveys what the image conveys.

A presentational image is decoration: a background texture, a flourish beside a heading, a photograph used for mood behind a title. Remove it and the page looks plainer but says the same thing. Presentational images usually belong in the CSS, where they can change with the design, the screen and the color scheme without touching the content. When one has to be in the HTML, it gets an empty alt="", which tells assistive technology to skip it.

The same picture can do either job. A photograph of a mountain on a page about that mountain is content; the same photograph faded behind a newsletter sign-up form is decoration. Ask what it is doing on this page.

The split has consequences the later pages build on. Content images need alternative text that does its job, which Images for people (page 07) teaches. They need to be sized for the layout and the screen, which Images in HTML (page 04) and Fluid and responsive images (page 06) teach. Presentational images can lean on CSS, which Images in CSS (page 05) teaches, and they are the first candidates for the elimination step in section 2.

7. Summary