Sometimes in apps I look into the Resources and find files for, for example, a 256x256 version, a 128x128 version, a 64x64 version, AND a 32x32 version, of the same icon. When I see simple geometric icons like circles I already wonder why they do not just use SVG, but on top of that, what is the purpose of storing an original icon in addition to progressively lower quality versions of the same icon? Storing the smaller icons does not even save space because the full size icons are being stored anyway.

For example in Roblox Studio the @2x and @3x images are just higher resolution versions of basically the same icon:


Why do that?

  • 6
    Is this an iOS app? If so, the simple answer here is because Apple require it. Oct 26, 2021 at 17:18
  • 2
    @PhilipKendall I have seen this or similar on apps of all platforms
    – CPlus
    Oct 26, 2021 at 17:21
  • 1
    @user16217248 which answers the question. App developers ever more don't create different code bases for different platforms but use systems that allow a unified code base to be compiled for all the platforms they're targeting.
    – jwenting
    Oct 27, 2021 at 8:32
  • 1
    the keyword is "mipmapping" Oct 27, 2021 at 9:19
  • 3
    @PhilipKendall But that just changes the question to "why do they require it?"
    – Barmar
    Oct 27, 2021 at 14:13

4 Answers 4


Image scaling isn't necessarily free

Modern processors are fast, but they're not magic, and everything that needs calculating on the fly uses up resources that could be better spent elsewhere. Similarly, if you load a large image into RAM (not to be confused with storage), or transmit it over a network, and then rescale it to one which only needs 1MB, you've wasted that 4MB of memory or bandwidth.

In the case of icons, this is generally negligible, but it could add up for a large number of images.

More importantly, image scaling is not always easy

Scaling a bitmap down means throwing away part of the image data, but trying to keep the "look" of the image. For some images, that's trivial - throw away every other pixel in a large block of colour, and you have an identical block of colour, but smaller. For some, it requires a smarter algorithm - a curved line will look jagged if you just drop pixels, but blurred if you over-use anti-aliasing.

For some images, it is better to simply redraw from scratch. To produce an icon at a very low resolution, an artist might take the original design and drop irrelevant details, straighten up curves and slanted lines, and so on. Notably, even storing a vector image such as an SVG would not give as good a result in these cases.

For a nice example of this, here are the 8 sizes of icons embedded in the LibreOffice Writer executable on Windows, which have clearly been hand-drawn at each size (form left to right, 16x16, 22x22, 24x24, 32x32, 48x48, 64x64, 128x128, and 256x256):

LibreOffice icons at actual size

Here is what each would look like if simply scaled down to the smallest size (16x16):

LibreOffice icons scaled to 16x16

And here they are all scaled to 64x64 (the actual size of the sixth one along):

LibreOffice icons scaled to 64x64

Special cases require effort

As you pointed out, some applications have very simple icons which could be made to look fine with automatic scaling. However, if some icons are stored at multiple resolutions, it's much easier to code the application or framework assuming that all icons will be stored at those resolutions. It's also easier to tell designers to always give you a series of icon files at the appropriate sizes, and name them in a standard way, leaving it up to them how much time to spend optimising each one.

  • 4
    The other thing to remember, that's specific to file/program icons: In Windows you can zoom in and out in explorer to make the icons really gigantic or really tiny. You would not want a tiny 16x16 image scaled up to 512x512, it would be very pixelated, and you also would not want a 512x512 image downsized to 16x16, as the post demonstrates (the high resolution image is less distinguishable).
    – jrh
    Oct 27, 2021 at 1:38
  • 2
    @RoelSchroeven: GUI scaling, at least for the latter. With high DPI settings, Windows can scale its UI by 150%. This means Windows will check for a 24x24 icon icon instead of a 16x16. Why not add an 48x48? Presumably LibreOffice thought that the 32x32 icon scaled well enough. 22x22 is weird, I'd expect a 20x20 for 125%.
    – MSalters
    Oct 27, 2021 at 8:03
  • 1
    Great answer. Feels like the 3rd point should come first though, it's the most important, IMO. Oct 27, 2021 at 9:55
  • 3
    @RoelSchroeven it's typical to have these sizes in freedesktop.org-based environments. You can see other common sizes in e.g. Ubuntu using a command like basename -a /usr/share/icons/*/[0-9]*/ | sort -uh
    – Ruslan
    Oct 27, 2021 at 11:04
  • 3
    The latter part of the answer is good, but the implied order of relevance of the reasons given in this answer is off: image processing time is essentially completely irrelevant: if it is considered at all (and, I claim, it usually isn’t), it’s much less important than the issue of accurate scaling. Similarly, I don’t think memory requirements are often considered for icons. Oct 27, 2021 at 16:24

It's often so that you can display differently sized versions of an icon without having to go through the process of scaling down to smaller sizes.

The smaller versions may have been tweaked to make them easily recognisable, while an automatically scaled one could be fuzzy or pixelated.

  • Are there some systems where you cannot decide how to render images, and just renders them based on how many pixels in size the images are?
    – CPlus
    Oct 26, 2021 at 17:35
  • @user16217248 I expect there is a really dumb system somewhere that does that. But anything that someone has taken some care over will handle differing size icons properly.
    – Simon B
    Oct 26, 2021 at 22:50
  • 1
    MacOS and iOS will scale whatever image needs the least amount of scaling. Plus you can have different point sizes with different resolutions. For example 32x32x3 (designed for 32x32 size with 3 pixels per point) vs 48x48x2 (designed for 48x48 points with 2 pixels per point).
    – gnasher729
    Oct 30, 2021 at 13:23

For images over many magnitudes of scale, programs will store multiple resolutions in an efficient format https://en.wikipedia.org/wiki/Pyramid_(image_processing)

One use case: for high resolution maps, it would require not only lots of computation but an impossible amount of bandwidth to transmit the full resolution of a map, so when zoomed out lower detail tiles are presented, then when zooming in these are replaced with higher definition tiles.

Another use case is for reducing aliasing artifacts and speeding up computation is using mipmaps. The basic idea is that lower resolution textures are used for further away graphics.


Credit: User BillyBob CornCob on Wikimedia

The original description of mipmaps by Lance Williams in 1983 used a neat trick to store images with 3 channels, usually RGB such as in JPEG images, into one square using a recursive pattern. Here is the beautiful hand-drawn diagram from the paper:

recursive rgb

There are advantages and disadvantages to using a single image file for multiple resolutions: a single file is better for filesystems and can image compression algorithms can potentially compress better when all data is one file, but there is a little computation needed to extract the relevant resolution.

This would not extend so nicely for image formats that have 4 channels, such as an additional alpha (transparency channel) to get 4 channel RGBA in PNG images (conveniently, four 8-bit values pack perfectly into a 32-bit word).

The PNG format can optionally use interlacing, which uses a similar idea of storing multiple "resolutions" of an image, in this case so that over a slow internet connection, the user sees a degraded version of the image instead of say the first couple raster lines. I was quite inspired when I saw this GIF 14 years ago on Wikipedia:


Credit: CountingPine on Wikipedia.

  • 1
    I've seen this geometric layout before, but I can't find any info on it after tons of googling. I'm curious if somebody has a reference
    – Alexander
    Oct 27, 2021 at 13:32
  • is that black-gray-white-recursing square just a way of mapping the channels of all the different size images into a square grid? As in that the largest actual image is 1/4 of the full square, with the black, gray and white quarters the three channels, and then repeating the same for the lower quarter and the next smaller size? I wonder if that's any more useful than just storing the different images as regular images back to back.
    – ilkkachu
    Oct 27, 2021 at 17:05
  • I've never seen the recursive square used in practice, but maybe there are some advantages to using a single image for all scaled images instead of multiple files.
    – qwr
    Oct 27, 2021 at 19:49
  • @qwr Sure. When you're storing on disk, space is allocated in clusters/chunks so you can have wasted space up to almost the cluster size - per file. Like carrying 2.1 gallons of liquid when your only container is 1 gallon jugs. When you have 10 small files you can lose up to 10*cluster size, vs only 1*cluster size for one larger file. You lose some space with the larger file because you have overhead of the grey and white areas, but compressing image formats such as PNG are very good at large areas of solid color, instead of saving "pixel 1, grey, pixel 2, grey, etc."... Oct 28, 2021 at 11:24
  • ...it will just save "pixels 1 through (1234), grey". (Or similar to that, the exact algorithm varies by image format but you get the idea.) For network transfer there is a similar per connection overhead. To transfer a file your computer first takes some time to contact the remote server, make sure that it is listening, and then explain what file is wanted. That's usually about the same amount of time per file, so 10 files has 10x as much transfer overhead as 1 file. Etc. (Same concepts apply to file reads, in memory storage, etc.) Oct 28, 2021 at 11:24

One big reason is even in the current version of Windows, program icons are bitmap files. Vector images - like SVG - aren't supported by the OS yet. The official design guide says:

Because app icon assets are bitmaps and bitmaps don't scale well, we recommend providing a version each icon asset for each scale factor: 100%, 125%, 150%, 200%, and 400%. That's a lot of icons! Fortunately, Visual Studio provides a tool that makes it easy to generate and update these icons.

Instead of adding support for vector graphics, they opted to simply automate the process of generating the myriad of image files at different sizes. The guide lists 14 different "target sizes" for icons.

That applies not just to program icons, but to certain controls/widgets in the OS's native GUI toolkit.

  • 2
    SVG support might reduce the number of images which need storing, but a well-designed icon still needs to be customised to look good at very small and very large sizes, as the example in my answer demonstrates. This Windows Vista / 7 era design guide discusses the principles quite clearly. I couldn't find the equivalent for Fluent Design, but this Q&A touches on the same principle.
    – IMSoP
    Oct 30, 2021 at 13:34
  • 1
    So if anything it's the other way around: Microsoft considers bitmap rather than vector icons as a feature, because it allows designers to draw pixel-perfect icons, and adapt the style and detail for different contexts.
    – IMSoP
    Oct 30, 2021 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.