ブラウザでSVGが表示されない？よくある原因と対処法
SVGが壊れた画像アイコンになる、または何も表示されない理由
SVGファイルは本来、扱いやすいはずです。ラスタ形式の画像とは異なり、無限に拡大縮小できるため、通常は信頼性が高いはずです。しかし、SVGがレンダリングされない場合、その失敗はしばしば静かで、混乱を招きます。壊れた画像アイコンが表示されたり、真っ白な四角が表示されたり、グラフィックがあるはずの場所に何も表示されなかったりします。破損したJPEGは少なくとも明らかに壊れているように見えますが、問題のあるSVGはテキストエディタでは完璧に見えても、Chrome、Firefox、Safariでは何も表示されないことがあります。 問題は通常、いくつかの明確な点に集約されます。WebサーバーからのMIMEタイプが間違っている、ファイル内のXMLが不正、インラインコードをブロックするセキュリティポリシー、またはSVGが視覚的にゼロサイズでレンダリングされるサイズの問題です。それぞれ解決策が異なり、これらを混同すると何時間も無駄にすることになります。このガイドでは、「ファイルを検証してください」といった曖昧なアドバイスではなく、確認すべき具体的な設定や属性とともに、それぞれの原因を詳しく解説します。 始める前に重要な区別があります。SVGの問題の中には、デザインツール（Illustrator、Figmaなど）でのエクスポート時に始まるものと、ファイル変換中に発生するものがあります。オンラインツールを使ってファイルをSVGに変換して破損した場合、それはサーバーが誤設定している完璧なSVGとは異なる種類の問題です。この2つの違いを明確にしていきます。
間違ったMIMEタイプ：多くの開発者が見落としがちなサーバー側の問題
`<img>`タグやCSSの`background-image`を使ってSVGを表示する場合、ブラウザはサーバーから送信される`Content-Type`ヘッダーを検査します。もしそのヘッダーが正しい`image/svg+xml`ではなく`text/plain`や`application/octet-stream`と読み取られた場合、ほとんどのブラウザは画像をレンダリングすることを単純に拒否します。ファイル自体は完璧かもしれません。 これは、本番環境でSVGが破損する最も一般的な原因の一つであり、ローカル開発では見過ごされがちです。なぜか？ローカルでは、おそらくファイルをディスクから直接開いているだけで、サーバー経由で提供しているわけではないからです。この問題はデプロイ後に初めて顔を出します。 これを診断するには、ブラウザのDevTools（F12）を開き、「Network」タブに切り替えてページを再読み込みします。リクエストリストからあなたのSVGを見つけ、クリックして「Response Headers」を確認してください。`Content-Type`の行は`image/svg+xml`である必要があります。もしそれ以外であれば、それが問題の原因です。修正はファイルではなくサーバー側で行います。 Apacheでは、`.htaccess`ファイルに`AddType image/svg+xml .svg .svgz`を追加することでこれを修正できます。Nginxユーザーは、`nginx.conf`の`types`ブロック内に`image/svg+xml svg svgz;`を追加します。IISを使用している場合は、Internet Information Services Managerを使用して、`.svg`拡張子に対するMIMEタイプマッピングを`image/svg+xml`に追加する必要があります。 NetlifyやVercelのようなマネージドプラットフォームを使用している場合、これは設定ファイル（`netlify.toml`または`vercel.json`）で処理されます。例えばNetlifyの構文では、`[[headers]]`ブロックを使用して特定のパスの`Content-Type`を設定します。これは5分でできる修正ですが、何時間ものフラストレーションを解消できます。ただし、ネットワークパネルを確認することを知っていれば、の話です。
不正なXML：SVGファイル自体に問題がある場合
SVGはXMLドキュメントであり、厳格な解析ルールに従います。閉じタグが一つ欠けている、エスケープされていないアンパサンド、あるいは重複した`id`があるだけで、一部のブラウザではファイル全体がサイレントに失敗することがあります。ヒントです。もしあなたのSVGがChromeではレンダリングされるのにFirefoxではされない場合、不正なXMLが最も疑わしい原因です。FirefoxはXMLエラーに関して非常に明確です。 自分で確認するには、SVGファイルをFirefoxのウィンドウに直接ドラッグしてみてください。XMLが壊れている場合、Firefoxは「XML Parsing Error: not well-formed at line 47, column 12.」のように、行番号と列番号を含む明確なエラーメッセージを表示します。それがあなたの宝の地図です。VS Codeのようなテキストエディタでファイルを開き、その正確な場所へ移動してください。 何を探すべきか？多くの場合、`&`と書かれるべきリンク内のアンパサンド（`&`）です。あるいは、閉じられていない`<path>`や`<g>`要素が見つかるかもしれません。エンコーディングの問題も古典的なもので、デザインツールがUTF-8を宣言せずに標準ASCII範囲外の文字をエクスポートするケースです。非ASCII文字を含むSVGファイルは、常に`<?xml version="1.0" encoding="UTF-8"?>`で始まるべきです。 古いバージョンのAdobe Illustratorは、独自のXMLネームスペースを含むファイルをエクスポートする傾向がありました。これは技術的には無効ではありませんが、無駄な容量を増やし、時としてパーサーを混乱させることがあります。SVGOのようなオプティマイザでこれらのファイルを通すと、通常これらのネームスペースが削除され、これは良いことです。危険なのは、グラフィックの見た目が何らかの形でこれらの独自の属性に依存していた場合で、その場合はファイルをクリーンアップすると予期せず破損する可能性があります。 CocoConvertを使用してファイルをSVGに変換し、出力にXMLエラーがある場合は、結果ページのフィードバックボタンからお知らせください。私たちはこのような変換アーティファクトを積極的に探し出し、修正しています。
インラインSVGとコンテンツセキュリティポリシーの競合
SVGマークアップをHTMLに直接貼り付けるのは強力な手法ですが、大きな注意点があります。SVGがDOMの一部になるということです。これは、それがページのコンテンツセキュリティポリシー（CSP）の対象となることを意味します。厳格なCSPは、SVGの一部をサイレントに無効にし、混乱を招く可能性があります。 これは特に、`<script>`要素、アニメーション用の`<style>`ブロック、または外部シンボル定義を参照する`<use>`要素を含むSVGに当てはまります。`script-src 'self'`のような一般的なCSPディレクティブは、SVG内のインラインスクリプトの実行をブロックします。`img-src 'self'`のようなディレクティブは、`<image href="https://external-domain.com/...">`を介して参照される外部画像のSVGへの読み込みを妨げる可能性があります。 良いニュースは？ブラウザが何が問題なのかを正確に教えてくれるということです。ブラウザの開発者コンソール（「Network」タブではなく「Console」タブ）を開き、赤いエラーメッセージを探してください。CSP違反は非常に明確で、「Refused to load the script because it violates the following Content Security Policy directive: script-src self.」のように、どのリソースがブロックされ、どのポリシーディレクティブが原因であったかを明記します。 これを修正する方法は、SVGのニーズによって異なります。`style-src`ディレクティブに`'unsafe-inline'`を追加することもできますが、これはセキュリティポリシーを弱めることになるため、強くお勧めしません。アニメーションSVGのより良い解決策は、CSSを外部スタイルシートに移動し、`<?xml-stylesheet type="text/css" href="styles.css"?>`でリンクすることです。外部ファイルを指す`<use>`要素の場合、シンボルをインライン化するか、`img-src`ポリシーを調整してオリジンをホワイトリストに登録する必要があります。 CocoConvertや同様のツールによって生成されたSVGにはスクリプトがないため、`script-src`の競合は発生しません。ただし、変換されたSVGが色やフォントにインラインCSSを使用している場合、`style-src`の競合は依然として発生する可能性があります。
SVGを不可視にするViewportとViewBoxの誤設定
これは最もイライラする種類のSVG問題です。ブラウザはSVGを完璧にレンダリングしていますが、ゼロサイズで、または画面外のどこかにレンダリングされています。壊れた画像アイコンは表示されず、何も見えません。DevToolsで空白をじっと見つめ、そこに`<svg>`要素があるのに画面には何も表示されないという、この特有の苦痛を知っている人は多いでしょう。 重要なのは、グラフィックの内部座標系を定義する`viewBox`属性と、SVGがページ上で占めるスペースを定義する`width`および`height`属性との関係です。これらが欠けていたり、一致していなかったりすると、混乱が生じます。 Figmaのエクスポートでよく見られます。SVGに`width="100%"`と`height="100%"`が指定されているのに`viewBox`がない場合です。そのSVGを明示的な高さを持たないコンテナに入れると、SVGは高さゼロに崩壊します。修正方法は、元のアートボードの寸法に一致する`viewBox`（例：`viewBox="0 0 800 600"`）を追加するか、CSSでコンテナ要素に高さを指定することです。 もう一つの典型的なケースは、パスデータが`viewBox`の座標範囲をはるかに超えて描画されているSVGです。もし`viewBox`が`"0 0 100 100"`なのにパスデータが`M 500 500`から始まっている場合、グラフィックは画面外に400単位描画されていることになります。これは、デザインツールでシェイプを移動する際に、アートボードの原点をリセットしなかった場合に発生します。これを修正するには、デザインツールに戻り、すべてのオブジェクトを選択して「バウンディングボックスのリセット」コマンドまたはそれに相当する機能を使用し、再度エクスポートしてください。 これを診断するには、DevToolsでSVGを検査します。計算された幅または高さが0の場合、サイズ設定が原因です。一時的に`<svg>`タグに直接`style="border: 1px solid red; width: 200px; height: 200px;"`を追加して、問題を強制的に顕在化させることもできます。これにより可視のボックスが作成され、グラフィックの一部が表示されているかどうかが明らかになります。
SVG内部でのフォントと外部リソースの読み込み失敗
SVGは常に自己完結型ではありません。フォント、画像、グラデーション、フィルターなどの外部リソースを参照できます。これらの外部呼び出しが失敗すると、欠落した部分がいかに重要かによって、SVGは部分的にレンダリングされるか、完全に間違って見えることがあります。 フォントの失敗は頻繁に起こる頭痛の種です。`<text>`要素でカスタムフォントを指定しているSVGは、そのフォントが利用できない場合、システムデフォルトにフォールバックします。これは通常、レンダリングを完全に破壊するわけではありませんが、テキストがコンテナから溢れ出し、レイアウト全体が崩れる原因となることがあります。私のアドバイスは、Web用にSVGをエクスポートする前に、常にテキストをアウトライン（パス）に変換することです。Illustratorでは「書式」>「アウトラインを作成」、Inkscapeでは「パス」>「オブジェクトをパスへ」です。これによりフォントへの依存関係と、それに伴うあらゆる種類の問題が完全に解消されます。 SVG内の外部画像はさらに扱いにくいです。URLを指す`<image>`タグは、URLがダウンしている、画像サーバーに適切なCORSヘッダーがない、またはCSPがオリジンをブロックしているために失敗する可能性があります。ブラウザはエラーアイコンを表示せず、画像があるべき場所に空白をレンダリングするだけです。「Network」タブで404ステータスまたはステータス0のリクエストを確認してください。これはCORSまたはCSPブロックを示していることが多いです。 ラスタ画像を含むPDFまたはAIファイルを変換する場合、CocoConvertはそれらの画像をbase64データURIとしてSVGに直接埋め込みます。これにより外部参照の問題は解決しますが、SVGファイルが巨大になる可能性があります。数枚の写真を含むPDFは、簡単に5MB以上のSVGになることがあります。そのような場合、はっきり言いますと、PNGやWebPに変換する方がより実用的な選択です。SVGが常に正しい答えであるかのように装うつもりはありません。
変換が問題の原因である場合（そしてその対処法）
時には問題があなたのブラウザやサーバーにあるわけではありません。SVGファイル自体が最初から壊れており、それは劣悪な変換プロセスの犠牲者です。この可能性を認識することが重要です。なぜなら、それは環境のデバッグをやめて、ファイルを徹底的に調査し始めるべきだということを意味するからです。 一般的な変換アーティファクトには、異常に高い精度（小数点以下15桁以上）を持つパスデータがあり、これはファイルを肥大化させ、パーサーをタイムアウトさせる可能性があります。また、CMYKからサポートされていないRGB値への不正確な色空間変換や、ソースファイルが非ラテン文字スクリプトを使用していた場合の破損したテキストエンコーディングも含まれます。独自のXMLに依存する形式から変換する場合に、ネームスペース宣言が欠落していることもあります。 変換がうまくいっていないと疑う場合、最も速い確認方法はInkscapeでSVGを開くことです。Inkscapeは無料でクロスプラットフォームであり、非常に寛容なSVGパーサーを持っています。もしInkscapeではファイルが正しく見えるのにChromeで壊れている場合、問題はブラウザ固有のものである可能性が高いです。もしInkscapeでも壊れている場合、変換プロセス自体が失敗し、出力が破損していることになります。 CocoConvertは堅牢な変換ライブラリを使用していますが、完璧な自動ツールは存在しません。数百のレイヤーを持つ非常に複雑なAIファイルや、透明度効果に大きく依存するPDFは、不完全なSVG出力を生成する可能性があります。このような状況では、最も信頼できる方法は、元のアプリケーションでソースファイルを開き、直接SVGにエクスポートし、CocoConvertは、シンプルなPNGからSVGへの変換や、印刷用のSVGからPDFへの変換など、私たちが得意とする形式のペアに使用することです。 もし変換によって破損したSVGが得られた場合、結果ページのフィードバックフォームを使用して報告してください。可能であれば元のファイルも添付してください。具体的な例が、私たちが皆さんのために変換パイプラインを改善する方法であり、私たちはそれらの報告を真剣に受け止めています。