Favicons and share images are what remain once the site is otherwise finished. Both live outside the page, which makes them easy to forget, and between them they carry the entire first impression whenever the site appears somewhere else: a browser tab, a bookmark, a link card in a messaging app.
A favicon is not one file
There was a time when one favicon.ico covered it. Today the icon appears in several places, each wanting a different size. Happily you do not need all of them — about four cover the ground.
From a design point of view the shape matters more than the sizes. Something legible at thirty-two pixels is not a shrunken logo but one element extracted from the logo. Scale a full wordmark down and the tab shows a grey smudge.
Checking it is easy: reduce the artwork to thirty-two pixels in your design tool and step back from the screen. If a recognisable shape survives, it passes; if it turns to mush, remove more. Thin strokes disappear first, so it is usually worth redrawing the mark with heavier strokes specifically for this size.
Decide on the background too. Transparency looks right on a light theme but a dark icon vanishes against a dark tab strip. A light shape on a solid background holds up everywhere.
Share images: 1200 × 630, and the safe area
This is the card that appears when someone pastes your link. The size that functions as a standard is 1200 by 630, roughly 1.91 to 1.
The design question is where it gets cropped. Different services crop the same image to different ratios, and some come close to a square. So keep anything important in the middle and treat the edges as margin. Type placed near an edge will be cut somewhere.
Type size is the other common trap. These cards are usually displayed small, so a size that looks comfortable on a 1200-pixel canvas is unreadable in situ. Shrink the canvas and check that it still reads — that is the only reliable test.
The absolute URL is not optional: another server reads that value, so a relative path resolves to nothing. And transparent PNGs invite the failure where a platform fills the background with white or black and your type disappears into it — paint the background yourself.
The trap everyone hits: the platform caches it
You fix the share image, paste the link again, and the old picture comes back. Inspect the tag and the new URL is sitting there correctly. Nothing is wrong with the code — the platform stored the preview on its own side.
This is the most important fact on the subject. Previews of links already shared do not change when you fix the tag. The card sitting in a chat thread, the image attached to a social post, are copies taken at that moment and there is no retroactive fix.
There are two responses. First, ask for a refresh through the platform’s sharing debugger — a tool that makes it re-fetch the address, and most major platforms offer one. Second, change the image filename. A new URL is a different image as far as the platform is concerned, which sidesteps the cache entirely.
Prevention matters more. Check share images before the page goes public. Fixing them afterwards leaves every link shared in the meantime carrying the old picture — and those are usually the links that travelled furthest during the launch.
The order to check in
A short sequence for before you publish. Check the favicon in an actual browser tab; inside a design tool it always looks fine. Open a row of tabs and see whether you can pick yours out at a glance.
Check share images on the pages that matter — home, the service page, a flagship article. The rest are covered by the default. Without a default set, the platform picks whatever image it finds first, and a chart from the middle of the body ends up as the share card.
Meta tags and structured data generally are covered in the SEO archive, and choosing image formats and sizes lives in the images and media series. To see how a site looks from the outside first, start with the diagnostic on the free tools page.