新しいSVG faviconを本番環境にデプロイしました。Chromeデスクトップでは完璧に見えました。ところが、SlackでユーザーがSafari iOSのスクリーンショットを共有し、あなたのタブには空白の白い四角が表示されていました。「自分のマシンでは問題ない」と「どこでも動作する」の間のギャップこそ、favicon compatibility testが埋めるために設計されたものです。
favicon compatibility testは単なる視覚チェックではありません。ブラウザ、OS、検索エンジンが実際にfaviconをリクエストするあらゆる環境に対して、アイコンスタックを検証する構造化された監査です。一般的なfavicon testerと本物の互換性テストの違いは、フォーマット、サイズ、コンテキスト、レンダリングモードといった範囲の広さにあります。
Favicon Compatibility Testが実際にチェックするもの
ほとんどの開発者は「互換性」を「表示されるかどうか」と捉えています。本当の互換性は少なくとも5つの次元をカバーし、1つでも欠けると本番環境でサイレント障害が発生します。
- フォーマット互換性 — SVG、PNG、ICO、レガシーGIFはブラウザによって動作が異なります。
- 解像度互換性 — 16x16、32x32、48x48、96x96、180x180、192x192、512x512はそれぞれ特定のコンテキストを対象とします。
- コンテキスト互換性 — ブラウザタブ、アドレスバー、ブックマークバー、Pinned Tab、ホーム画面、Google検索結果。
- テーマ互換性 — ライトモード、ダークモード、Safariのtinted tabs。
- クロール互換性 — Googlebotが安定したURLからアイコンファイルを実際に取得できるかどうか。
各次元には異なる障害モードがあります。ICOファイルは256KBを超えるとSafariで壊れます。SVG faviconはChromeでフラットカラーをレンダリングしますが、正しく記述された場合にのみprefers-color-schemeを尊重します。WHATWG仕様は明示的なサイズヒントを持つrel='icon'を定義しており、ブラウザはこれらのヒントを使用して適切なファイルを選択します（WHATWG HTML Living Standard）。
Mzu favicondlで互換性テストを実行する
Mzu favicondlは、互換性テストを単一のスクリーンショットではなく、階層化されたワークフローとして扱います。URLを貼り付けると、ツールはサイトが公開しているすべてのアイコンファイルを取得します — HTMLの<link>タグ、ルートの/favicon.ico、site.webmanifest、Apple Touch参照などです。その後、ブラウザが実際に使用するコンテキストで各ファイルを検査できます。
テストワークフローには3つの段階があります。
- インベントリ — サイトが提供するすべてのアイコンファイルを収集します。マニフェスト内の隠れたファイルも含みます。
- レンダリングチェック — 重要なサイズ（16、32、48、96、180）で各ファイルをプレビューします。
- フォーマット変換 — 不足しているフォーマット（SVGからICO、ICOからPNG）を生成し、スタックのギャップを埋めます。
この段階的なアプローチが重要なのは、ほとんどの互換性障害はレンダリングバグではなく、ファイルの欠落だからです。サイトがrel='icon' type='image/svg+xml'を宣言していても404を返す場合、Safariにはアイコンがまったく表示されません。Mzu favicondlのインベントリステップは、これらのギャップを即座に明らかにします。
参照HTMLスタック
以下は、下記の互換性マトリクスを通過する最小限のHTML linkタグスタックです。これを<head>に配置してください。
<link rel='icon' href='/icon.svg' type='image/svg+xml'>
<link rel='icon' href='/icon-96.png' sizes='96x96' type='image/png'>
<link rel='icon' href='/favicon.ico' sizes='32x32'>
<link rel='apple-touch-icon' href='/apple-touch-icon.png' sizes='180x180'>
<link rel='mask-icon' href='/safari-pinned.svg' color='#1a1a1a'>
<link rel='manifest' href='/site.webmanifest'>テストすべき互換性マトリクス
焦点を絞ったfavicon compatibility testは、これまでに出荷されたすべてのデバイスをカバーする必要はありません。現代のブラウザが実際に使用するサーフェスをカバーする必要があります。以下は、デプロイ前に実行することを推奨するマトリクスです。
| コンテキスト | 最小ファイル | よくある障害 |
|---|---|---|
| ブラウザタブ（Chrome、Firefox、Edge） | SVGまたは32x32 PNG | linkにsizes属性がない |
| ブラウザタブ（Safari） | SVGまたは32x32 PNG | ICOファイルが256KBを超える |
| アドレスバー | 16x16 PNGまたはICOエントリ | マルチサイズICOが提供されていない |
| Pinned Tab（Safari） | モノクロSVG | フルカラーSVGを使用している |
| ホーム画面に追加（iOS） | 180x180 PNG | 透明背景（iOSが白を追加） |
| ホーム画面に追加（Android） | 192x192 + 512x512 maskable | maskableセーフゾーンがない |
| Google検索結果 | クロール可能、正方形、≥48x48 | CDNがGooglebotをブロック |
スタックのいずれかの行にギャップがある場合、そこが互換性テストの失敗点です。修正は通常、単一のファイル変換であり、Mzu favicondlが直接処理するステップです。
クリーンな互換性結果を得るためのプロのヒント
互換性テストを一貫して壊す3つのパターンがあり、すべて回避可能です。
同じSVGを異なるサイズで二重に提供しないでください。 <link rel='icon'>のsizes属性はヒントであり、スイッチではありません。SVGは解像度に依存しないため、ブラウザはSVGファイルに対してこれを無視します。WHATWG仕様に従ってスケーラブルアイコンを宣言する正しい方法は、sizes='any'を追加することです。
ダークモードは出荷後ではなく、出荷前にテストしてください。 透明なSVG上の黒いロゴは、Chromeのダークタブストリップでは見えなくなります。Mzu favicondlでは、SVGをライト背景とダーク背景の両方で並べてプレビューできます。コントラストが不十分な場合は、SVG自体にprefers-color-schemeメディアクエリを追加してください。
常にマルチサイズICOを含めてください。 今日でも、ルートの/favicon.icoファイルはブラウザ、クローラー、古いRSSリーダーによってリクエストされます。16、32、48ピクセルのエントリを持つマルチサイズICOは、1つのファイルですべてのレガシーコンテキストをカバーします。
スタックに実際に必要なファイルの詳細なチェックリストについては、2026 favicon audit checklistをご覧ください。また、新しいアイコンをデプロイする前に、すべてのブラウザコンテキストを視覚的に確認したい場合は、all-browsers favicon testerがワークフローのその側面を説明しています。
まとめ
favicon compatibility testは、あなたのラップトップでアイコンがレンダリングされるかどうかの問題ではありません。すべてのブラウザ、OS、検索エンジン、レンダリングモードが正しいファイルを取得、解析、表示できるかどうかの問題です。これをフォーマット、解像度、コンテキスト、テーマ、クロールの5次元監査として扱うことで、推測がチェックリストに変わります。Mzu favicondlはインベントリと変換パイプラインを提供します。あなたの仕事は、デプロイ前にマトリクスを行ごとに確認することです。