Resizing Images and Generating Favicons for the Web

Resizing an image sounds like the simplest operation in image editing, and most of the time it is — until you squash a logo by accident, try to enlarge a thumbnail, or realize your favicon looks fine on a desktop tab but wrong on an iOS home screen. The operation itself is trivial; the choices around it are what matter. Get them wrong and you ship distorted artwork or a favicon set that only half works.

Downscaling versus upscaling

Downscaling discards information, and that is usually fine. A 4000-pixel-wide photograph reduced to 800 pixels keeps the detail that matters at display size and throws away the rest, often looking sharper at 800 pixels than the original did. Storage and bandwidth drop proportionally. There is rarely a reason not to downscale an image to the size it will actually be displayed at — pick the target size from the layout, export at that size plus a 2x variant for high-DPI screens, and stop there.

Upscaling cannot recover detail that was never captured. Enlarging a 100-pixel image to 400 pixels asks the software to invent fifteen of every sixteen pixels through interpolation, and the result is softer and less detailed, not more. If you need a larger image, the fix is a higher-resolution source, not a bigger resize. The one legitimate use of upscaling is filling a layout slot at low cost — and even then, an SVG or a genuinely higher-resolution asset is the better answer.

Aspect ratio and the distortion trap

The single most common resizing mistake is changing width and height independently, which stretches the image into a wider or taller version of itself. Logos and faces are where this is most visible, but everything looks wrong: circles become ovals, squares become rectangles, text looks italic. Lock the aspect ratio so width and height scale together — most tools expose this as a chain icon between the two fields, and the resize tool preserves it by default. The only time to unlock it is a deliberate crop, where you are choosing to discard edges to hit a specific aspect ratio rather than distorting the whole frame.

What a favicon set actually needs

A favicon is not one file. It is a small collection of files at specific sizes and formats, because browsers and platforms request different things and a single PNG cannot satisfy all of them.

• favicon.ico — the legacy default, requested by every browser at the site root. An .ico file is unusual because it bundles multiple sizes in one file — commonly 16x16, 32x32, and 48x48 — so a single request serves every classic browser context.
• apple-touch-icon.png — a 180x180 PNG used when an iOS user adds your site to their home screen. iOS rounds the corners and applies its own mask, so ship a square image with the logo filling most of the frame and no transparency.
• Manifest PNGs — a web app manifest references 192x192 and 512x512 PNGs for installed PWAs and Android home screens.
• Optional assets — an SVG favicon for modern browsers that support it, and a Safari pinned-tab mask icon for older Safari versions.

At 16x16 pixels you have very little room to work with, so the source artwork matters as much as the export sizes. A detailed logo that reads well at 512x512 often turns into an unrecognizable smudge at 16x16; for the smallest sizes you usually want a simplified mark — just the core glyph, no fine detail, no thin strokes. Many favicon generators let you supply a separate simplified source for the tiny sizes specifically.

Generating each of these by hand is tedious and error-prone, which is the entire reason a favicon generator exists. Feed it one high-resolution square source — 512x512 or larger — and it produces the full bundle, including a multi-size .ico, in a single pass. If your source is in an unusual format, run it through a converter first to get a clean square PNG.

Serving them correctly

Link only what you ship, and reference each file explicitly in the document head:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/icon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/manifest.webmanifest">

Keep the source at 512x512 or larger, export each target size from that single master rather than scaling up from a smaller version, and you have a favicon set that looks correct on a desktop tab, an iOS home screen, and an installed PWA without any further work. Resizing and favicon generation are the kind of task that benefits enormously from being done once, correctly, from a single high-quality source, rather than patched together file by file. Spend the few minutes getting the source square and high-resolution, lock the aspect ratio, downscale rather than upscale, and the output set will serve every context a browser can throw at it.