Snapping to pixels in icon design

We want our designs to display clearly across all platforms for all users. To achieve this goal with digital icons, you need to adhere to the industry standard. It is recommended to apply snapping to pixels (pixel-snapping or pixel-fitting) so that the icons fit accurately on the pixel grid. This means that all strokes and shapes are snapped to 1 pixel increments and positioned clearly on pixels.

Most design systems and icon guidelines reflect this in their specifications – Google Material, Adobe Spectrum, IBM Carbon and Firefox Photon, to name a few.

The point is that since digital images are displayed on the screen in a matrix of pixels, aligning the elements to whole gives sharper results to pixels; placing items on subpixels or half-pixel results in more blurry images.

While curves and slanted lines may not fit perfectly to a square pixel, the idea is to be as accurate as possible.

It makes sense, but I wanted to dig a little deeper. Are these guidelines still valid with today s high-resolution screens? How important is pixel snapping in practice? What effect does device, browser, file type, software and icon scaling have on rendering?

To answer these questions, I ran a test.

Procedure

I created 4 test icons on a 48 x 48px canvas using a 2px stroke and a series of straight lines and curves.

• Option 1 was tied to 1 pixel
• Option 2 was tied to 0.5 pixel
• Option 3 was tied to 0.25 pixels
• Option 4 used an odd subpixel number (0.315 pixel)

I exported them from Illustrator and Sketch, in formats SVG and PNG, and displayed them on an HTML page in 4 sizes (original 48 x 48px, 64 x 64px, 32 x 32px, 24 x 24px). I then ran a test examining these assets in 3 browsers on 7 devices:

• MacBook Pro (Chrome, Firefox, Safari)
• Lenovo Thinkpad (Chrome, Firefox)
• Windows 10 gaming PC with monitor Acer P244W (Chrome, Firefox)
• iPad Pro (Chrome, Firefox, Safari)
• Pixel 3a (Chrome, Firefox)
• Motorola Moto E4 (Chrome, Firefox)
• iPhone 11 Pro (Chrome, Firefox, Safari)

I repeated the process 3 times to be sure of the results.

results

For our purposes, I ll summarize here. Unfortunately I can not illustrate all the results, it would be like talking about a matrix within a matrix. ?

• Snap to 1px and 0.5px generally gave the best results, but did not always work perfectly. In some cases, the pixel snapping effect was stronger, in others it was less. The lack of pixel binning on the Acer monitor gave extremely blurry results, while Apple devices were more lenient in rendering all options. It seemed that the lower the resolution, the more important pixel snapping is. Sometimes attachment to the whole pixel gave the maximum sharpness of the picture (ThinkPad, Acer), sometimes snapping to half a pixel (Pixel 3a, Motorola in one case) and sometimes snapping to 1px and 0.5px gave about the same result (Apple devices: MacBook Pro, iPhone 11 Pro, iPad Pro). Snap to 0.5px resulted in the least sharpness on the Acer monitor. It is important to note that I evaluated the sharpness of the icons at a very close distance (~ 10-12 cm) from the screen. When viewed at a normal distance, the picture may be better.
• The device (hardware + operating system + monitor) has a greater impact on rendering than the browser. The differences between browsers on the same device were minor, while the differences between devices were more visible. The Pixel 3a, for example, was pretty unbiased in rendering, smoothing out all the options pretty well. In contrast, the Lenovo Thinkpad display produced a sharper picture with jagged edges (ladder effect). When it comes to determining which snapping level was the sharpest, Windows 10 devices performed similarly, Android devices performed similarly, and Apple OS devices performed similarly. The operating system seems to have a big impact on rendering.
• In addition to icon design and export, many factors affect image sharpness. Enlarging the browser screen (up to 110%, 125%, 200%, etc.) changed the icons to appear clearer. Changing the size of the icons in the code (to 24px, 32px, 64px) also led to unpredictable results. In theory, a 24px icon (1px stroke) will be sharper than a 32px icon (1.33px stroke), but that wasn t always the case. Apart from this, there are many other factors: graphics card model, anti-aliasing settings, protective screens and films, viewer s distance from the screen, ambient lighting conditions, etc.
• The export to Illustrator and Sketch was identical, although I prefer Sketch. The SVG assets from Illustrator and Sketch were indistinguishable from each other. For PNGs, the difference was more noticeable, especially when zoomed in, but you will probably never view icons at 3200%. Sketch seems to apply smoother anti-aliasing.

• SVG surpassed PNG… On laptops and tablets, SVG and PNG performance was comparable. On mobile, SVG files were clearly sharper. In general, with no pixel snapping, SVG images rendered better, and were more flexible to zoom in and out as it is a vector format.
• Sharper does not always mean better, and a more precise definition is probably needed. There are different types of sharpness. We started with a general understanding of this word, but there is a nuance in its application. In my research, icons sometimes looked sharp but had jagged edges (Motorola, Thinkpad). Perhaps “clear” would be a better word.

Recommendations

The results of this test led me to one (not new) important recommendation – use whenever possible SVG-files… This is the most flexible format, and generally performs better:

• The icon designer can design one size that the interface designer can scale to different sizes (as far as the details allow; different sizes may require different levels of detail)
• The programmer can dynamically resize the icon in code and apply other transformations, such as fill color, stroke color, and stroke width.
• The end user can zoom in on their browser without compromising the quality of the icons.
• SVGs tend to look sharper than PNGs, even if not pixel-based
• SVG files are smaller than PNGs

A critic of the SVG format might say that it is difficult to achieve perfect clarity when you scale an asset to a different size. That s true, but it might be worth losing a little clarity in exchange for the above benefits, especially when there are so many factors beyond the designer s control.

A few more suggestions. Snap to 1px or 0.5px is preferred for both SVGand for PNG files. Design with the smallest overall size (create additional custom sizes as needed) and avoid scaling used PNG files. To support older devices with lower resolutions, it is better to use snap to 1px… Regardless of what you decide in terms of anchoring, it is important to develop a set of stylistic rules for your icons to achieve consistency. Simplify the math for yourself and don t forget to check the icons live in the context of the project.

Afterword: expectation versus reality

Pixel snapping is preferable, but don t get stuck. If it interferes with the clarity of the message or the desired aesthetic, then don t use it.

Despite stringent industry specifications, there is a serious lack of consistency. You will see this as you explore the digital products, websites, icon libraries, and source files around us. A quick audit of icons on Facebook, Instagram, Google and Twitter landing pages shows that some are pixel-bound, but most are not. A deeper analysis of the IBM Carbon icons shows that sometimes they break the rules:

The reason for the discrepancy between guidance and execution may be that pixel snapping is difficult to keep to scale. So sometimes there is a good reason to use subpixels, or perhaps pixel snapping is not as important as we think. Do your own investigation and make sure to first meet the important requirements of the icon pyramid of needs:

When we first started designing for the digital world, we encoded everything into precise pixels to get the look we wanted. We ve been tuned for the perfect pixel. But over time, we realized that the digital environment is flexible and our canvas is not accurate. Our code is adapted to serve many form factors using relative units, percentage based content blocks, flexible content transfer. I would suggest a similar responsive approach to icons – sacrificing precision a bit for more flexibility. Many great icon sets like Feather and Remix do just that.

? thanks: Toby Fried, Lonny Huff and Monica chang