Favicons, web manifests and share images

You do not need a dozen PNGs to look considered. You need a consistent mark, a short manifest, one large preview image, and a way to prove that each surface is using the file you think it is. I keep that set in the same release as the HTML on leej.uk, and I rebuilt the tools on this site — the Favicon Generator, the Web App Manifest Validator, the OG Image Maker and the Meta & Social Previewer — because I was tired of checking them by hand.

These files are how the site appears outside itself

A page can be typographically perfect and still look like a missing-image box in Slack, or a generic globe in a mobile tab. The files in this checklist do not change your search ranking on their own. They do change whether a person trusts a link, finds your tab again, or saves the site to their home screen.

Treat them as part of the design system, not as afterthoughts:

• One mark. The same shape should appear in the tab, on the home screen and (cropped with care) in a share image. If you change the logo, change every surface, including any app icons if you also ship on a phone. I have the same rule for Apple work: a change of mark goes everywhere, including the Watch where the icon is tiny.
• One name. The manifest’s name and short_name, the Open Graph og:title and the HTML title should agree about who you are. They can be different lengths; they should not be different brands.
• One theme colour that matches the header you actually ship, in light and dark if you have both.

The rest of this article is the minimum set that covers current browsers, and the checks that catch a stale cache.

Favicons: SVG, PNG and the ICO leftover

A modern default I am happy to ship is:

• an SVG favicon, if the mark is simple enough to read at small sizes
• a 32×32 PNG fallback (and often a 16×16 if you already have it)
• a legacy favicon.ico at the site root, because some tools still request that URL without reading your HTML

In the document head:

<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon-32.png" sizes="32x32" type="image/png">
<link rel="shortcut icon" href="/favicon.ico">

A few practical rules:

• The SVG should be a square viewBox with a simple shape and enough contrast in both light and dark tabs. If the mark disappears on a dark browser chrome, add a background or a media-query-friendly pair of files. Some browsers now request a media="(prefers-color-scheme: dark)" icon; if you add that, test both themes rather than assuming it works.
• Don’t use a 16-pixel-tall wordmark as the only favicon. Letterforms collapse. A monogram or a symbol works better at that size, the same way a focused Apple app needs a mark that survives a small icon grid.
• favicon.ico can contain several resolutions, but a single 32×32 ICO is already better than a 404 at /favicon.ico. Browsers will request that path even if you never mention it.
• Give the files a cache-busting query or a hashed name when you change them, and update the href. A favicon is one of the most stubbornly cached files on the web.

The Favicon Generator will produce a reasonable set from a square source image. Start from a large, sharp original, not from a screenshot of the existing tab icon.

Apple touch icons and the files phones still request

Safari on iOS, and some other mobile browsers, look for a large PNG they can put on the home screen. The conventional file is a 180×180 PNG, declared as:

<link rel="apple-touch-icon" href="/apple-touch-icon.png">

A few related requests still appear in logs, even if you never advertised them:

• /apple-touch-icon.png and /apple-touch-icon-precomposed.png at the site root
• padded or older sizes, on devices or browsers that predate the 180×180 convention

You do not have to provide every historical size. You should:

• put a 180×180 PNG at the URL you declare, without a transparent background that looks wrong on a home screen
• avoid writing small text into the icon; it will not survive the rounded mask
• remember that this file is a raster image. If you change the mark, export it again rather than hoping the SVG favicon will be reused here

Apple also uses the web app manifest, where it is present, for some install paths. The touch icon is still worth shipping, because a long-press or an “Add to Home Screen” from Safari has used it for years, and because a missing file becomes a generic screenshot of your page.

If you have a dark theme, do not automatically invert the touch icon. Home-screen icons sit on a wallpaper you do not control. A simple mark on a solid background is more reliable than a transparent one.

The web app manifest, icons and theme colour

A web app manifest is a JSON file that names the site, its start URL, its icons and a theme colour. You do not have to make the site installable as a PWA for a manifest to be useful; browsers also use it to pick icons and colours.

A small, honest manifest looks like this:

{
  "name": "Lee Johnson",
  "short_name": "Lee Johnson",
  "start_url": "/",
  "scope": "/",
  "display": "browser",
  "background_color": "#ffffff",
  "theme_color": "#ffffff",
  "icons": [
    {
      "src": "/icon-192.png",
      "sizes": "192x192",
      "type": "image/png",
      "purpose": "any"
    },
    {
      "src": "/icon-512.png",
      "sizes": "512x512",
      "type": "image/png",
      "purpose": "any"
    }
  ]
}

And in the head:

<link rel="manifest" href="/manifest.webmanifest">
<meta name="theme-color" content="#ffffff">

Choices worth being deliberate about:

• display: browser is the honest value for a content site you do not intend to open fullscreen. standalone is for an app-like experience, and it comes with the expectation that you have thought about navigation without the browser chrome.
• start_url and scope should be on the canonical host, and should not point at a preview hostname or a tracking URL.
• Icons: a 192 and a 512 PNG cover most install and splash uses. Maskable icons ("purpose": "maskable") need extra safe padding, because the platform will crop them to a circle or squircle. If you do not have a version padded for that crop, omit maskable rather than shipping a clipped mark.
• Theme colour should match the header. If you have a light and a dark header, you can ship two theme-color meta tags with prefers-color-scheme media queries, and matching values in the manifest if you maintain a dark variant. Test both; a white theme colour on a dark header looks like a bug.

Validate the file rather than eyeballing it. The Web App Manifest Validator will catch missing names, broken icon paths, nonsense sizes and a start_url outside the scope. Serve the manifest with a JSON content type (application/manifest+json or application/json), not as text/html.

Open Graph and a large preview image

When someone pastes a URL into iMessage, Slack, LinkedIn, WhatsApp or a social network, the preview comes from Open Graph tags and a large image, not from the favicon. The Open Graph protocol is the usual convention; X also looks at Twitter Card tags, which can share the same image.

A minimum set:

<meta property="og:type" content="website">
<meta property="og:site_name" content="Lee Johnson">
<meta property="og:title" content="Favicons, web manifests and share images">
<meta property="og:description" content="A checklist for favicons, Apple touch icons, a web app manifest and Open Graph images.">
<meta property="og:url" content="https://leej.uk/articles/favicons-manifests-and-share-images">
<meta property="og:image" content="https://leej.uk/og/favicons-manifests-and-share-images.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="The title of the article on a plain background, next to the site mark.">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="https://leej.uk/og/favicons-manifests-and-share-images.png">

A few constraints are more important than a perfect design:

• Use an absolute HTTPS URL for og:url and og:image, on the canonical host. A relative path is a common way to get a blank preview.
• A large landscape image is the safe default. The size most platforms have documented for a large card, for years, is 1200×630 pixels. Confirm if you are targeting a specific platform that publishes its own dimensions, and don’t invent a new standard for its own sake. The OG Image Maker will produce a 1200×630 image you can start from.
• The image should still make sense if cropped. Chat apps crop differently. Keep the title and the mark in the centre third, and don’t put the only important words on the far edge.
• Don’t put a wall of text in the image. The title and description already exist as tags. The image is a recognisable companion, not a second article.
• One image per page is enough in most cases. A unique image for every article is nice; a unique, accurate title in the tags matters more. A default site image is better than a missing one, as long as it does not claim to be a screenshot of a page it is not.

You do not need a separate “Twitter image” unless you want a different crop. If you set twitter:image, keep it in sync with og:image, or you will debug the wrong file when a preview is stale.

Alt text, cache and the preview that will not update

og:image:alt is the alt text of the share image. Write it as you would for any other image: what the picture shows, not “image” or the file name. Some platforms ignore it; some will use it, and it is cheap to get right.

The harder problem is cache. Chat apps and social platforms fetch the image once and keep it. After you replace a file at the same URL, previews can show the old image for a long time.

A process that works:

1. Change the URL when you change the image. A query string (?v=20261110) or a hashed file name is enough, as long as the tag points at the new URL.
2. Fetch the image URL yourself with curl -sSI and confirm a 200, a sensible content type, and that you are not being redirected to a login or a homepage.
3. Use each platform’s official debugger where it has one, after the new URL is live, to ask it to refetch. I will not list every vendor’s tool here because those URLs change; search for the current one when you need it.
4. Don’t test only in a chat thread that already saw the old URL. Open a new conversation, or a private window, after the debugger has been run.

The Meta & Social Previewer will show you what your tags currently say, which is the right first check. It cannot force another company’s cache to update.

If a preview is still wrong, look at the obvious causes before you redesign the image: HTTP rather than HTTPS, a relative og:image, a 404, a blocked path in robots.txt, or a login wall. A crawler that cannot fetch the image cannot show it.

A minimum set that covers modern browsers

If you want a punch-list for a small site, this is the set I ship and then stop expanding until there is a reason:

• /favicon.svg and /favicon-32.png, linked from the head
• /favicon.ico at the root
• /apple-touch-icon.png at 180×180, linked from the head
• /icon-192.png and /icon-512.png, listed in the manifest
• /manifest.webmanifest, linked from the head
• a theme-color meta tag that matches the header
• one 1200×630 share image per page, or a well-chosen default, referenced with absolute Open Graph and Twitter Card tags and alt text

You can add maskable icons, a dark SVG favicon, and per-article images later. You do not need an old-fashioned list of ten PNG sizes in the head, and you do not need a Windows tile tag unless you have a reason to support it.

Put the files in the same deploy as the HTML that points at them. A new article with an old, unversioned logo in the share image is a release bug, not a design choice — the same kind of completeness I want before an App Store launch, and the same versioning discipline as App Store screenshots and previews.

How to check each surface

Work through the surfaces, rather than trusting a single validator:

• The tab icon looks sharp, and is correct in both light and dark browser chrome, on desktop and on a phone.
• https://your-domain/favicon.ico returns a file, not a 404 or the homepage.
• “Add to Home Screen” on iOS uses the touch icon you designed, not a screenshot of the page.
• The manifest validates, its icons load, and start_url opens the page you meant. Use the Web App Manifest Validator.
• The theme colour matches the header in light and, if you have it, dark.
• og:title, og:description, og:url and og:image are present, absolute and accurate. Check them with the Meta & Social Previewer.
• The share image is the current file, at the current URL, and still readable if the edges are cropped.
• A fresh chat preview, after any platform debugger has been run, shows the new image rather than last year’s.

If you change the mark, run the list again. Icon work is only finished when the last cached surface has caught up.

Key takeaways

• A small, consistent set is enough: SVG plus PNG favicon, a root ICO, a 180×180 Apple touch icon, 192 and 512 manifest icons, and one large share image.
• The web app manifest should tell the truth about the name, start URL and display mode, and its icons should actually load.
• Open Graph tags need absolute URLs, a 1200×630-class image, and alt text; a separate X image is optional and must not drift.
• Change the image URL when you change the image, because tab icons and chat previews cache harder than you would like.
• Check each surface in a real browser, a home-screen add, and a fresh link preview, not only in a generator.

If you want a second pair of eyes on a set of site icons, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.