Turn a Logo into Favicon Files That Stay Recognizable

The first favicon I generated from a full company logo was technically perfect and visually useless. At 16 pixels, the symbol, company name, and tagline became a gray-blue crumb. The fix was not another converter; it was accepting that a favicon needs its own crop.

Prepare the source before resizing it

• Prefer an original SVG or a large lossless PNG over a screenshot or repeatedly saved JPEG.

• Crop to a square canvas without stretching the logo.

• Remove taglines and details that cannot survive at 16×16 pixels.

• Keep the recognizable mark centered with breathing room for rounded or maskable crops.

• Preview against light and dark backgrounds when the source contains transparency.

• Keep the master file; generated favicon sizes are outputs, not future editing sources.

Option A: generate the package in an online converter

The original article used the favicon.io image converter. Its current interface accepts a PNG, JPG, or BMP, previews the result, and downloads a ZIP containing browser, Apple touch, Android/PWA, ICO, and manifest assets. Interfaces and package contents can change, so inspect the downloaded archive rather than assuming it matches an old screenshot.

1. Open the converter and upload the prepared square source.

1. Inspect the preview at its actual small size, not only enlarged.

1. Download the generated ZIP and scan it with your normal local security controls.

1. Extract it into a temporary directory and list the files before copying anything into the project.

1. Open the 16px, 32px, touch, and large app icons individually.

1. Keep only the formats your site declares and supports.

A typical package may contain favicon.ico, 16×16 and 32×32 PNGs, an Apple touch icon, 192×192 and 512×512 app icons, and a web manifest. Those files serve different browser and operating-system surfaces; they are not interchangeable duplicates.

Option B: generate raster files locally with ImageMagick

A local command is useful when favicon generation belongs in a repeatable build or the source cannot leave your machine. The example below assumes a square icon-source.png with the intended padding already designed. ImageMagick CLI names differ by major version: current releases use magick, while older distributions may expose convert.

$ magick icon-source.png -resize 16x16 favicon-16x16.png
magick icon-source.png -resize 32x32 favicon-32x32.png
magick icon-source.png -resize 180x180 apple-touch-icon.png
magick icon-source.png -resize 192x192 app-192.png
magick icon-source.png -resize 512x512 app-512.png
magick icon-source.png -define icon:auto-resize=256,128,64,48,32,16 favicon.ico

What the generation commands imply

• magick reads the source independently for each output, avoiding repeated resize-of-a-resize degradation.

• -resize 16x16 fits the image within that box; a non-square source will not magically gain a square canvas.

• The 180px PNG targets Apple touch-icon use, while 192px and 512px assets are relevant to installed web-app metadata.

• icon:auto-resize asks the ICO writer to include several embedded raster sizes in one file.

• Shell success proves files were written, not that the tiny artwork is legible; visual inspection remains mandatory.

Inspect dimensions and format instead of trusting filenames

$ magick identify favicon.ico favicon-16x16.png favicon-32x32.png apple-touch-icon.png app-192.png app-512.png

What the inspection catches

• identify reads image metadata without changing the files.

• A multi-image ICO should produce multiple frames or entries, revealing the embedded dimensions.

• PNG filenames are only labels; the reported geometry proves whether the image has the promised size.

• Unexpected format, zero-byte output, wrong dimensions, or a decode error should stop deployment.

Judge each icon at the size people will see

• 16×16: look for a recognizable silhouette and clean contrast, not internal detail.

• 32×32: confirm curves and diagonal edges do not become muddy.

• Touch icon: check the background and margins because platforms may add rounded treatment.

• Maskable app icon: keep critical artwork within the safe zone so adaptive crops do not remove it.

• Dark browser chrome: verify transparent dark marks do not disappear.

If a generated 16px icon fails, simplify the master or create an optical small-size variant. Enlarging the preview does not improve the asset; it only makes the failure easier to inspect.

Deploy assets with matching HTML and manifest metadata

<head>
  <link rel="icon" href="/favicon.ico">
  <link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
  <link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
  <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
  <link rel="manifest" href="/site.webmanifest">
</head>

What the browser learns from the markup

• Each href is root-relative and must resolve from the deployed origin.

• type identifies PNG resources, while sizes describes their real intrinsic dimensions.

• The ICO provides a compatibility fallback with multiple internal sizes.

• apple-touch-icon serves an Apple-specific home-screen/Web Clip convention.

• The manifest is separate JSON metadata for installed web-app behavior and must reference its own valid icon paths.

{
  "name": "Example Site",
  "short_name": "Example",
  "icons": [
    {
      "src": "/app-192.png",
      "type": "image/png",
      "sizes": "192x192"
    },
    {
      "src": "/app-512.png",
      "type": "image/png",
      "sizes": "512x512"
    }
  ]
}

What the manifest does—and does not do

• The icons array supplies candidates for installed-app surfaces.

• src, type, and sizes must agree with files the server actually returns.

• Chromium guidance calls for at least 192px and 512px icons for installable experiences.

• These entries do not replace the browser-tab rel="icon" declarations.

• A maskable icon needs a deliberately padded asset and an appropriate purpose; do not label an ordinary edge-to-edge icon maskable without redesigning it.

Verify the deployed result, not the ZIP on your laptop

1. Request every icon URL directly and confirm a 200 response, correct content type, and expected image.

1. Inspect the live document head to ensure the deployed HTML contains the declarations.

1. Open the manifest URL and validate its JSON and icon paths.

1. Use browser DevTools to check for 404s, redirects to HTML, CSP blocks, and unexpected caching.

1. Test a fresh browser profile and, if supported, an installed-app flow.

1. Retain the old package or deployment revision until the new assets are confirmed.

When the old icon refuses to leave

Favicons can remain in browser, bookmark, service-worker, application, and CDN caches. First prove the public URL serves the new bytes. Then purge controlled caches and consider publishing a versioned filename with updated markup. Repeated hard refreshes are not a substitute for identifying which cache still owns the old response.

Small files deserve deliberate review

A converter can produce six valid files in seconds, but it cannot decide whether your mark survives sixteen pixels or whether a private logo should be uploaded. Prepare the source, inspect each output, keep metadata aligned with deployment, and test the actual public page. The result will be tiny; the workflow should not be careless.

Related favicon work

• Understand favicon formats, browser selection, and caching before choosing outputs.

• Pick accurate colors from a logo or image when recreating the mark.

• Optimize larger website images separately from favicon and app-icon packaging.