Why an incomplete favicon set shows a placeholder on some devices
A search engine, browser, and mobile system request a site icon not “in general,” but at a specific address, in a specific size, and with certain background requirements.
If there is no file at that address, the engine does not try to carefully scale what it found—it substitutes a system placeholder. On desktop, this is a gray sheet on the tab; in search results, a neutral globe; and it is far from always noticeable immediately.
Usually a favicon set is assembled partially: one image is made for the tab, and that is where people stop.
But the home screen icon, the pinned tab icon, the tile in the app list, and the preview for a link in messengers are separate entities with their own file names, sizes, and rules.
A missing element from the set silently drops out, and the placeholder in search returns even after the main icon has already been fixed.
A separate problem is scale. A logo drawn for a wide banner turns into an unreadable mark in a small square: thin lines merge, the wordmark disappears, and a colored blob remains.
A home screen icon in this form is not recognizable, and a person who has already opened the site does not associate the tile with the brand—at best they do not tap it, at worst they consider it junk.
Inertia also adds up: browsers and systems keep the substituted placeholder in their storage, so replacing one file on the server changes nothing—a complete set and correct links to it are needed.
We break down how this is covered: an inventory of all points where site icons are requested, a matrix of sizes and formats, generation from a single source, and checking on real devices—tab, search results, home screen, pinning.
What a unified icon set provides: effect on release and maintenance
A single icon source instead of manually uploading a set
The entire set is assembled from a single vector source in the repository: the generation recipe outputs both the image in the tab and the icon on the phone’s home screen, as well as images for the app manifest.
Sizes and formats do not diverge between branches, and editing one file updates the whole set. There are noticeably fewer manual steps in a release: instead of uploading, renaming, and arranging into folders—one command that runs directly in the build.
Post-publication edits do not wait for the next release
You updated the logo—change the source and publish only the icons, without rebuilding the entire application. The set is versioned together with the code, so you can see which version went out to users and what to roll back if the appearance differs from the expected one. Post-publication edits take minutes and do not become a separate task in the queue.
Support requests about a “missing” icon go away
Browsers cache icons aggressively, and a typical failure is desynchronization: the markup has a new file, the manifest has an old one, and some users still have the previous one.
When all links are generated from a single source and checked at build time, this class of defects and the requests associated with it simply disappear.
A complete favicon set: implementation options and their limitations
The basis of the set is a single vector source: edits in it propagate automatically to raster copies of the required sizes. The set remains consistent, and changing the logo does not turn into manually redrawing a dozen files. But one file does not cover all scenarios—hence three real approaches.
| Option | When it fits | Limitations |
|---|---|---|
| One vector basis and raster copies | A site without installation as an app | Some browsers cache the icon aggressively; the update is visible with a delay |
| Extended composition: sizes and versions for dark theme | Services with bookmarks and different color schemes | More files: version control and careful page markup are needed |
| Complete set with web app installation | A product that users put on the home screen | The system applies its own mask and background—the edge of the frame is cropped |
Web app installation is a separate scenario: Safari and mobile systems crop the icon differently; in some places it is cropped in a circle, in others it gets a background backing.
That is why the composition includes separate copies for the mask and monogram, as well as a wide option for tablets and desktop.
We state platform limitations before the start, not after delivery: aggressive caching in some browsers, delayed icon updates in bookmarks, and different behavior when adding to the home screen. That is why we check both scenarios separately—installation and normal tab opening.
Workflow: from icon audit to handover of the regulation
An icon set is not one file in the root, but a coordinated kit: markup in head, a web app manifest, icons for tabs, shortcuts, browser history, and home screens.
Assembling it manually with every logo edit is a sure way to get desynchronization: an old mark in one place, cropped margins in another. That is why we follow a fixed order—from icon audit to handover of the regulation.
- Icon audit. Inventory: what is in the root, what the manifest pulls in, which addresses return errors, where there are duplicates, and how the current template and mobile version show the mark.
- Set composition scheme. We agree on a table “carrier — format — size — purpose”: tab, bookmark, shortcut, home screen, installed app. The table works as an agreement: nothing extra, nothing forgotten.
- Preparation of the basis. We reduce the mark to a vector source, define the grid and safe area for cropping by mask. Separately—a dark theme version and a simplified mark for small sizes where details merge.
- Build. Icons are generated from a single source in the build pipeline, names get a hash, and markup and manifest are updated automatically. Editing the logo ceases to be a manual operation on a dozen files.
- Device testing. We check on real phones, tablets, and desktop browsers: adding to the home screen, installing the app, behavior during updates. We separately check cache and version reset on the delivery side—otherwise the old icon lives with the user for months.
- Handover of the regulation. We provide a document: where the source is, how to add a size, who the owner is, and what is included in the release check list. We run through it with the client’s team so the next update of the mark happens without us.
Project artifacts: sources, ready-made sets, and documentation
The client is left not with an archive of images, but with a working kit from which any size of the mark can be assembled and updated without us. The files are stored in the repository next to the code—icons change in the same commit as the markup.
- Master source of the mark — a vector file with separated layers, a defined safe area, and separate versions for light background, dark background, and monochrome. Any size is assembled from it without loss of quality.
- Ready-made platform sets — SVG for modern browsers, a container with several raster sizes for older ones, a PNG set for the iOS shortcut, and a maskable version with extra margins for Android.
- Web app description file — a filled-in manifest: full and short name, theme and background colors, display mode, start URL, and icon list. The system takes data from here when installing to the home screen.
- Markup block for connection — ready-made lines of links to icons and theme colors; inserting into the template comes down to copying, without manually selecting sizes.
- Update regulation — where the master is, how to rebuild the sets, how to reset browser and messenger caches, and what to check after publication.
- Acceptance checklist — a list of places where we check the result: tab, bookmarks, home screen shortcut, preview when sending a link.
- Entry in the project documentation — who is responsible for icons and at what point they are reviewed when the corporate identity changes.
The kit is designed so that the team can then work with it on their own: replacing the mark takes minutes and does not require rebuilding the site.
Case study: the site tile stopped being replaced with a system placeholder
The public part of the project had eleven templates and three design themes, and before a unified build appeared, icons were drawn and arranged into folders manually.
The set diverged: one template still had the previous logo icon, another had a single small image in the root, and a third linked to a file deleted during repository cleanup.
In bookmarks and on the home screen tile, the browser substituted a system placeholder—that was the main flow of requests.
We reduced generation to a single build: the vector master is run through RealFaviconGenerator and a custom script, producing a complete set—legacy ICO, raster sizes for bookmarks and shortcuts, a separate branch with transparent margins for system masking, a large icon for the home screen, and a monochrome one for dark theme.
All markups have the same block of required links, the manifest specifies purpose and theme color, and file names contain a content hash—neither cache nor delivery network serves the previous version.
Metrics before and after. Before: nine files in four folders, three of them outdated, and updating the logo took about forty minutes of manual editing with a guaranteed forgotten section.
After: twenty-seven files from one command, updating is replacing the master and rebuilding, and divergence between sections is structurally impossible because the source is one.
The build step checks hashes against links in the templates and stops deployment if the set is incomplete.
The eliminated class of defects was a system placeholder instead of the tile and different icons when installing to the home screen on different platforms.
In the quarter after implementation—not a single icon-related request; template coverage with required links remains at one hundred percent: regressions are caught by the build, not by the client in the browser.
What to do if the site is already added to home screens?
A pinned icon is not requested from the site every time it opens: the system takes the file at the moment of addition and keeps a local copy. Therefore, replacing the image at the same path will not show for everyone—some devices will remain with the old image.
A working technique is to version names: icon-192-v2.png instead of overwriting icon-192.png, and keep the previous files accessible.
Platform behavior differs. On Apple iOS, the home screen icon is taken from apple-touch-icon and updates reluctantly—most reliably after re-adding.
Android browsers tie the shortcut to the installed web app: the updated manifest is pulled in on launch, but the launcher may keep the old image until the shortcut is reinstalled.
Preserving installations is ensured by the immutability of the app identity—the site origin, start_url, scope, and id in the manifest. Changing any of these fields means a different app to the system: the user loses both the shortcut and saved installations.
Old icon files must remain in place at the same time—a 404 at the previous path breaks updates for already installed shortcuts.
A separate case is changing the site address: the shortcut stores an absolute path and after a move opens the old page or an error; it cannot be transferred programmatically.
Here a permanent redirect from the old address and the correct address in the manifest work, so that a new installation immediately leads where it should.
Typical doubts about icons, cache, and app installation
Doubts at acceptance are almost always technical, not a matter of taste.
We collected what is most often asked before the start: why one image is not enough, how long the old icon lives after editing the mark, why the small version has to be drawn anew, and what the set adds to page markup.
Why is one image not enough?
The browser scales it itself, and the mark loses stroke thickness: on a light panel the outline disappears, on a dark one the shape merges with the background.
The set is separate files for system masks, dense screen grids, and an option for app installation, where the mark is shown in a square with cropping at the edges.
How quickly will the icon update after editing the mark?
Files are served with long caching, so the name contains a content fingerprint: editing changes the path, and the browser fetches the new version immediately, without manual clearing for the user.
Links in the markup and installation descriptor are updated in the same release—a delay is possible only in intermediate caches, where a reset is needed.
Why is the small mark drawn separately?
In the tab square, details merge into a blob, so for a small size the shape is simplified: thin outlines are removed, gaps between elements are increased, and sometimes one letter is left. This is not the same file reduced automatically, but a standalone drawing for a narrow size.
What does the set add to page markup?
Several links in the document head and a descriptor file. They do not affect weight or loading speed: the system and browser request the required size on demand, not together with the document. The markup remains valid, and no extra requests appear during normal browsing.
Let’s discuss the task: what source files to send for an estimate
To come back with an estimate of the set composition and a work plan, rather than with a series of clarifying questions, one message is enough. Below is the minimum by which we can already see the scope and name the timelines.
- site or test stand address—we will see which icons are currently served in the browser, bookmarks, and on the phone;
- logo in vector (SVG, AI, or PDF); if there is no vector—a raster source at the maximum possible resolution so that we can build the contours ourselves;
- current set: what is already in the root and connected in the markup, including legacy formats such as ICO, and which of these you want to keep;
- brand requirements: brand colors, safe area around the mark, the minimum size at which the logo is still recognizable, and a brand book, if there is one;
- list of places where the set must work: browser tab, bookmarks, desktop shortcut, phone home screen, link preview in a messenger;
- reference—a couple of examples of icons whose presentation you like, or a direct link to how not to do it;
- site constraints: what you have access to—markup, theme, domain root—and whether there is a dark interface theme that needs a separate option.
This will be enough for us to come back with the set composition, a list of formats and sizes, a work plan, and build timelines. Describe the task—let’s discuss.
