SVG画像はベクター形式なので劣化がなくてキレイかつ便利！とお思いのみなさま、突然ですがSVG画像の「中身」を見たことはありますでしょうか。
SVG画像が上記のような特徴を持つのは、画像としても扱えるXML形式の文書でもあるためで、JPG, PNGのようなピクセルベースのラスター形式画像とは根本的に構造が異なっています。
その証拠に、中身がバイナリデータであるJPGやPNG画像の内部は人が見ることのできる形をしていません（VS Codeなど賢いエディタであれば中身は見せず画像プレビューが表示されます）が、SVG画像はテキストエディタであればあっさりその中身を除くことができます。
その中身を垣間見たなかでもし以下の記述にピン！と来るものがあればこの記事は読んでいただく必要はないかもしれません。
<image xlink:href="data:image/png;base64, [...省略...]" />ただしどんな画像であっても見た目では形式までわかりませんし、 <img> タグなどで読み込んでしまえばどれも同じ「画像」扱いになってしまうので、ふつうはその中身まで見ようとしないことがほとんどかと思います。
いったいSVG画像に潜むこの記述のどこが問題なのか……わかりますでしょうか。
解説：base64によるインライン化
ここに base64 とありますが、これは64進数：アルファベット（a~z, A~Z）と数字（0~9）、一部の記号（+,/）の64文字を用いることで、バイナリデータをテキスト変換する方式のことです。
https://developer.mozilla.org/ja/docs/Glossary/Base64
Base64 とは、バイナリーからテキストへの符号化を行う手法のグループであり、バイナリーデータを 64 を基数とする表現に変換することで、ASCII 文字列で表すことができます。
そのため ,[...省略...] とした部分には本来Base64に変換済の元・バイナリデータの文字列がズラッと並んでいることになるのですが……そこも基本的には人が読める形をしていません。（実際読む意味もあまりないので）その手前にある xlink:href=data:image/png; に注目しましょう。
まず xlink:href= とは、SVG内部から外部のリソースを参照するための記載です。
CSSの背景画像などでよく使う url() と似たようなものですが、ここでは data:image/[画像形式]; というData URIスキームを併用することで、外部からの参照ではなくSVGの内部に直接（インライン化された）画像データを埋め込むことができるようになっています。
この場合ならば data:image/png; なのでこの後に続くもの（base64変換された文字列）を「PNG画像」として扱うことを示しています。ほかにもJPG画像として扱いたければ data:image/jpg; などになりますが……。
つまり、上記コードの記載があった時点で、「base64変換されたPNG画像データ」がまるっとSVG画像の中に入っているということがわかります。
そうなるとこれは……本当にSVG画像なんでしょうか？
原因：便利すぎるSVG
何故このようなキメラ画像が生まれてしまうのか、という原因についてはまずSVGという形式がそもそも持っている便利さ……というより良くも悪くも門戸の広さにあります。
問題にされている <image xlink:href=... /> は上記で解説した通り外部からの画像リソースを参照して画像を表示するためのものなので、本来は <image xlink:href="example.png" /> のようにしてSVG内に他の画像を意図的に参照し、取り込むための属性表記です。
※現在は xlink:href の利用自体が非推薦で、 href を使うべきではあるようです。
https://developer.mozilla.org/ja/docs/Web/SVG/Reference/Attribute/xlink:href
https://developer.mozilla.org/ja/docs/Web/SVG/Reference/Attribute/href
ただしその画像をテキストで埋め込めるようbase64変換し、外部の画像データ自体を全てインライン化してしまっても……何の問題もなく書き出せてしまうのがSVGという画像形式なのです。
SVG画像を表示するだけのブラウザ側からすれば、参照先の画像が外部の example.png なのか、インラインで埋め込まれた data:image/png;base64,… なのかにさしたる違いはないということです。
また各種デザインツールから画像を書き出す際にこのようなSVG画像の特性を理解していないと、デザインデータ自体に外部から「埋め込み」「リンク」されている画像を含んだままSVGとして書き出してしまうことが起こりうるのですが、こうした場合に上記の画像のbase64変換＋インライン化が行われてしまいます。
もちろん .jpg や .png （ラスター画像）のデータをそのまま直接 .svg （ベクター画像）として扱うことはできないため、書き出しの際には .svg 内に埋め込むことで表示の解決を図ろうとします。
当たり前のことながら .jpg のために作られたバイナリデータを .png にすることはできませんしまた逆も然りですが、ことSVGという箱自体には何をどんな形で詰め込んでも（文法が間違えていたりしない限りは） .svg という画像ファイルの表示が成立してしまいます。
これらがいわゆる「偽SVG」を生み出してしまう主な原因と思われます。
解決：偽SVGは悪なのか？
base64によるインライン化や「SVG画像の中にインライン化された別画像がいる」こと自体は、それぞれが正しい手続きによるものなので技術的にはそもそも悪でもなんでもありません。
先の通り <img> を使えばどれも皆同じ画像扱いなので表示上は成立して（しま）いますし、base64やData URI自体はCSS内に軽量な画像……それこそSVGで作ったアイコン画像などを変換して直接埋め込む手段としても使われることもあります。
ただし、中身にラスター画像がいることに気付かないままSVG＝ベクター画像の恩恵を受けられると思って .svg を書き出してしまっていることは実装や運用上、紛れもない「悪」になるかと思います。
（ピクセルベースの画像をSVG形式で書き出すだけで高画質化できるような魔法はありません）
また画像本体がテキストとしてインライン化されてしまった以上、画像圧縮などの取り扱いも不便になる〜そもそもbase64変換は圧縮が目的ではなく容量サイズ面の効率も悪いため、不意に起きてしまうことはあれど意図的に利用する利点はほとんどないと言ってよいでしょう。
参考に2026年4月時点で偽SVGを配布しているサイトの例を紹介しておきます。
Instagramブランドアセットとブランドガイドライン | Meta
まさかそんなと思いますが、なんと全く同じカラーロゴのPNG画像（5000×5000px） Instagram_Glyph_Gradient.png が2.6MBという容量サイズに対して、 Instagram_Glyph_Gradient.svg はなんと4倍以上の10.9MBとなっています。それだけでもビックリなのですが、しかもSVG内に埋め込まれているPNG画像の解像度は約半分（2499.85×2499.85px）になっているという……本来は軽くてキレイなはずのSVG画像を扱おうとするうえではただただ「もったいない」ミスになります。
（ただし、これは類推ですがロゴデータならば .svg 形式の準備がないとおかしいというお問い合わせへの対応や、SVGは写実的な表現には弱いためグラデーションではロゴをうまく再現できなかったなど……「あえて」こうしている理由もあるかもしれませんが）
……このように大企業でも起こりうる・気付くのは難しい現象なのですが、深く考えずとりあえずSVGにしようとするのではなく、表示したい画像それぞれに「向いた」形式で画像を書き出し・管理することが重要になるかと思います。