Building a static website (part 3: Screen sizes, logical and physical pixels, resolution and scaling factor)

18-AUG-2025

In the previous post, I looked at the very basic decisions around embedding images into a website and what file formats make sense for which kinds of use cases. In this blog post, I'm going to take a look into a subject that can be mightily confusing, but can be useful to understand when designing webpages, particularly if we are considering the display of images. I wanted to make sure that I did understand how this all works before moving on to the subject of responsive images (hopefully).

The different meanings of size and resolution

I think it is worth trying to understand a bit more about the different meanings of "size", "resolution" and even "pixel", as applied to images, screens and webpages, because it does affect the way we approach things. This includes things like the intrinsic size of an image, its resolution; monitor or screen resolution and CSS (logical) pixels versus physical pixels. These terms are often stated in a confusing way and it is important to understand them when considering the design of webpages.

Normal users (viewers of webpages) shouldn't, generally speaking, need to worry about this kind of thing, as long as the combination of hardware manufacturers, operating system developers, browser vendors and web designers have done a good enough job!

To try and understand this to some extent, I'm going to talk about:

• Physical screens (i.e. the monitor, mobile phone or other device you view webpages on).
• Scaling factor (something set by the operating system/user that affects the way things are displayed).
• The meaning of "pixel" (physical versus logical).
• Bitmap images.
• Vector-based images.

Physical screens

First of all, there is the physical monitor or screen that a person use webpage on, which might be a desktop monitor or increasingly, a device such as mobile phone or tablet. All of these of course have a physical size, which for historical reasons, is measured diagonally and in inches, with typical sizes being around 14 - 16 inches for a laptop screen or 24 inches and above for desktop monitors (yes, they can be significantly smaller or larger).

The next important measurement of size for a screen is the number of pixels that it can display. This will usually be defined by the number of pixels horizontally and vertically, although some rather confusing terminology is used. For example, a typical desktop monitor with a landscape orientation might have pixel dimensions of 1920x1080 (sometimes referred to as "full HD" or even 1080p). Increasingly, there is also monitors that can display 3840x2160 (usually referred to as 4K), which is double the vertical and horizontal figures for the full HD monitor. There are also several other common values, but for simplicity, I will disregard those for now.

In documentation, the pixel count as explained above is sometimes referred to as the "resolution", but that isn't really the case, because resolution is defined as PPI (pixels per inch) or DPI (dots per inch).

The diagram below illustrates some of the points. If we imagine a typical 24 inch desktop monitor with a 16:9 aspect ratio, for an HD monitor, the screen will physically have 1920 pixels (i.e. individual light emitting points) horizontally and 1080 pixels vertically, while the corresponding 4K screen with the same diagonal size has 3840 pixels horizontally and 2160 pixels vertically.

As a side note, I find that it is very difficult to buy a 4K monitor that is 24 inches in size, which is a pity, but that's a discussion for another time.

This means that the physical screen has a physical size of 24 inches diagonally, or more usefully, approximately 530 mm x 300 mm. This means that the "resolution" of that screen is approximately 90 PPI for the HD screen and 180 PPI for the 4K screen. Hence, in this case, the 4K screen can be said to have double the resolution of the HD screen, because it is the same physical size, but can display twice the number of pixels in a vertical and horizontal direction (hence four times the number of pixels in total). Another way of describing this is to say that it has twice the pixel density.

It is worth bearing in mind what resolution really means in this context, because it is particularly relevant to how we display images. Mind you, it doesn't help that with screen sizes, we often end up talking about both inches, centimetres and millimetres.

Scaling factor

When I was looking into all of this, there were several things that ended up being somewhat confusing (for me at least), when considering how graphics (in general) are displayed on a desktop or laptop monitor, or other screen. This is something I will refer to as scaling factor. First of all, a bit of background.

Putting aside the old CRT (Cathode ray tube) screens that used to dominate TVs and desktop monitors back in the day, as most people will probably understand and I outlined in the previous section, monitors and screens are made up of a matrix of extremely small, individually addressable light emitting points (pixels). As we will explore later, these are physical device pixels, as opposed to logical pixels.

When LCD screens first became common on people's desktops, they had pixel sizes that were relatively low in comparison with today, with figures such as 1024 x 768 being quite common. Amusingly, the resolution of a CRT continued to be better at the time — for example, I owned a CRT monitor that had pixel dimensions of 1600 x 1200 – but it was a colossus. I digress…

However, in comparison with, say a modern HD monitor as talked about above, they tended to be physically smaller in size, and hence had a similar resolution, as I attempted to define earlier. Most people were using desktop machines and there were no commonly available screens that had significantly higher resolutions (from the point of view of PPI). Certainly there was nothing equivalent to the modern 4K (and above) screens that we can buy today. As a side note, they will also often have an aspect ratio of 4:3, rather than the much more common 16:9 and 16:10 that is common today.

If the operating system on your computer needed to render a shape that was 400 pixels wide for example, it would activate 400 physical pixels on the screen and that was that. Operating systems did not include any ability to scale the entire user interface and generally speaking, that wasn't necessary because everything was drawn at a reasonable size for most people.

Eventually, monitors characterised as HiDPI were introduced, popularised by the so-called Retina display – which were particularly important for the iPhone and later for Apple laptops. These types of screens and the 4K screen I talked about previously tend to have double the resolution of standard screens.

If an operating system without awareness of the drastically increased DPI of such a monitor rendered its user interface and so on in the same way as before, the result would be unreasonably small text and graphics (at least for most people!) Hence, operating systems needed to introduce the idea of interface scaling.

This tends to be expressed as a percentage, so keeping things simple, if you have a monitor with double the resolution, then setting the scaling factor to 200%, it means that that if the OS is drawing the same 400 pixel wide shape, it would now be activating 800 physical pixels on the screen, which means that it would render the shape of the same physical size as before. This scaling factor is then generally used when rendering the entire user interface on the screen — including the menus, widgets and applications, such as the browser (where our interests particularly lies).

Effectively, the scaling factor is something that the operating system uses to decide how to render UI components and graphics to the screen, but it also passes that scaling factor to applications, leaving them to decide how to deal with what is being displayed within their own application windows.

In my experience, this can lead to a certain level of inconsistency (and hence one of the reasons I have found this confusing). For example, if you view a JPEG image that is 400 x 400 pixels on a 4K monitor with 200% scaling and choose a view option similar to "Zoom to Actual Size", depending on the application you use to view the image, it may actually show an image rendered on the screen as 800 x 800 physical pixels on the screen, while some applications might displayed rendered as 400 x 400 physical pixels on the screen (which might well be considered technically correct). I would say that most of the applications I tried on my Linux machine had the former behaviour, including Gimp, while Gwenview shows the latter. This does demonstrate that different applications can deal with scaling factors in different ways. Naturally, when it comes to displaying text and images in a browser window, things can be further complicated.

It might also be worth noting that most modern desktop operating systems support a user selectable scaling factor and non-integer factors are now widely available. However, it's worth bearing in mind that if you choose such a non-integer value (such as 225%), the operating system has a significantly more difficult task to render graphics accurately.

On the other hand, mobile operating systems don't allow the user to select a scaling factor (at least as far as I know), but I assume something similar to that is set in the background by the operating system. Certainly, the iOS Resolution website shows that iPhones and iPads have 2x or 3x scaling factor.

Now, having considered the concept of an overall scaling factor, we can return to thinking about browser and website focused image rendering and how it affects website design.

The meaning of a pixel

It's worth talking about the definition of a pixel, because this is both important in web design and potentially somewhat confusing. This is because there is a distinct difference between a physical pixel and a CSS (or logical) pixel. As is typical for these things, the details are rather complicated, but I'm trying to find the most straightforward way I can to explain the difference.

As far as I can understand it, if we take the example I presented earlier of a 24 inch monitor with a pixel size of 1920x1080, the practical size of a CSS pixel is exactly the same as the physical (or device) pixel. This will mean that if we used the following HTML and CSS to draw a blue box of size 400 x 100 pixels, we would expect the typical HD screen to use 400 horizontal physical pixels and 200 vertical pixels to draw the box.

Note that, in the case of this HD screen example, I'm also assuming a 100% scaling factor, a concept I covered in the previous section.

.blue_box
{
   width: 400px;
   height: 100px;
   background-color: powderblue;
}

<div class="blue_box">
<p>A 400x100 blue box.</p>
</div>

Of course, it is very difficult to see that this is actually the case, but perhaps we can illustrated more clearly by imagining that we zoom in to that same screen, such that we are looking at a 16 x 9 pixel area, in which we draw a blue 10 x 5 pixel box. In the diagram, the grey boxes represent the physical pixels of the monitor, while the blue boxes show what physical screen pixels are used to draw it. In this case, we see that the same number of physical and CSS pixels are used.

Now consider the case that we are zooming into an area of a 4K monitor. It is important to understand that we are illustrating an area of the same physical size, as the previous diagram, but because the 4K screen displays double the number of pixels in the same area, we can now understand where a physical device pixel is not the same as a CSS pixel, because each pixel that we used to draw the blue box now takes up two physical pixels in both the horizontal and vertical direction. This is also referred to as the Device pixel ratio (DPR). The result of this is that if you happen to view the actual blue box shown earlier on the 4K monitor of the same physical size, it will appear to be exactly the same size as it does on the HD monitor. This is basically how we can use CSS units, without having to worry about differences in screen resolution.

Note that, in this case, I'm assuming that the user or operating system has set a scaling factor of 200%, which would be a typical value. If they didn't, everything would look half the physical size, which is why it's important to understand the concept of scaling factor.

Naturally, the situation is somewhat more complicated than that in reality, because there are all sorts of screen sizes and associated resolutions, but this is approximately how things work. Also note that the same type of logic applies to size units such as centimetres and inches, but because of the way the CSS pixel is defined, very few if any screens will display something specified in CSS inches (or similar) units as that actual size on a monitor screen (as measured with a ruler). However, this need not detain us further at this point at least.

Bitmap images

Having looked at the situation with monitors and detouring into the meaning of a physical and logical (CSS) pixel, we now have to think about images and how size and resolution apply to them.

Bitmap images have an intrinsic size, which is defined by the number of horizontal and vertical pixels that make it up. From the point of view of displaying such an image on the screen, that's the only thing that's important. In that sense, it makes it quite similar to the blue box earlier on, in which the appropriate CSS width was used to define it as 400 x 100 pixels, thereby giving the box an intrinsic size.

Note that a bitmap image doesn't have a physical size, which it shouldn't come as any surprise, as it's not a physical object. Admittedly, an image might be associated with Exif data, which in theory can specify a physical size for an image, but is meaningless in many circumstances, although my scanner software sets the value and you can also specify an image as being a particular size in graphics software such as Gimp. It can be disregarded for this discussion.

That also means that an image doesn't have a resolution per se, because unless the Exif data is set, you don't know what the DPI value is and even if it is set, there's no way of knowing whether it's correct (as its just metadata) and as far as I know, browsers will ignore that anyway.

Note that the discussion below assumes that we are talking about the display of bitmap images in a browser window. This is important both because that's what we are really interested in and as I noted earlier, certain applications such as image viewers may act differently. My expectation is that all browsers of importance will act as I describe below.

We can now compare the bitmap image display with what we discussed earlier about the blue box. Once again, if we imagine zooming into a portion of a standard HD screen, such that we see a tiny area of 16 x 9 pixels. The following diagram illustrates roughly what you would see if we were displaying a commensurately small bitmap image, with a size of 10 x 9 pixels. Also, the operating system has set a scaling factor of 1x. Each pixel of the image is displayed by exactly one pixel of the screen.

Now imagine the situation where we display exactly the same image on a 4K screen, with double the resolution. Once again we are zooming in on an equivalent physically sized area of that screen, which means we are seeing 32 x 18 pixels. We are displaying exactly the same bitmap image as above – 10 x 9 pixels in size. In this case, the operating system has set the scaling factor to 2x.

In this case, we can see that the browser will display the bitmap image at the same physical size as it did on the HD screen and does so by scaling up the image such that it takes up twice the number of pixels horizontally and vertically as it did on the HD screen. I.e. the actual image is still the same as it was before, but the system has taken the necessary step to keep the display consistent with the lower pixel density screen.

Vector based images

Finally, I thought it was worthwhile at least talking about vector images. These are defined in a very different way from normal bitmap images. Such images are made up of basic shapes, such as circles, lines and curves and most importantly, these are defined mathematically, by providing information such as where a circle begins and what its diameter is, or a line can be drawn by specifying its starting and ending points, thickness, colour and so on. These types of images can be created by many applications, such as Inkscape. The SVG format images can be displayed by essentially every modern browser.

I won't reiterate what I discussed in the previous blog post, but it is worth noting that although they don't have an intrinsic size in the same sense that a bitmap image does, when you create a vector image, you still specify a size of some kind in the image editor, so as far as I understand, they still have some kind of notional size that the browser can use to display them, in a similar way to bitmap images. The difference is, that you can scale them up and down with no quality loss, at least as a very good approximation (I guess there might be problems if an image is scaled to very small sizes).

Summary and conclusion

I think we can summarise by saying that all of the things I've been describing in this blog post largely avoids the user having to worry about things like the resolution of the screen they are looking at, or how images they are viewing will be displayed. To a large extent, that is also true for website designers: when we specify the size of elements on the webpage by using CSS units, these are mostly logical units and so many of the vagaries of the hardware are taken care of.

Look out for the next entry in this series of blog posts, coming soon.