SVG データURIエンコーダ | base64 より 30% 軽い CSS 用 data URI 生成
SVG マークアップを最小限のパーセントエンコードで data:image/svg+xml URI に変換し、background-image: url(…) の形でそのまま CSS に貼れるスニペットまで一発で出力するツールです。base64 化は元のバイト数を必ず 33% 増やしますが、このツールが採る方式は < > " # % といった「url() を壊す文字」だけを %xx に置き換える方針なので、アイコン SVG 程度なら base64 比でおおむね 20〜35% 軽くなります。
💡 このツールについて
Webpack の svg-inline-loader や Vite の ?inline を入れるほどでもないけれど、ボタンや疑似要素の背景に小さな SVG アイコンを 1 枚だけ埋め込みたい、という場面は地味によくあります。HTTP リクエストを 1 本減らせばその分だけ FCP も縮みますし、url() に置けば :hover で別アイコンに差し替えるのも CSS だけで済みます。
base64 でも同じことはできますが、base64 は元データを 3 バイトずつ 4 文字に展開する仕組み上、必ず元の 33% 増になり、しかも CSS の中で改行されると醜く崩れます。一方、SVG はテキストなので「URL に直接埋めても困らない文字」がほとんどで、本当にエスケープが要るのは < > # % と、外側 url() のクォートと衝突する " か ' のどれか一方だけ。Yoksel の url-encoder で知られたこの方針が、典型的なアイコンで base64 を 30% 前後下回る理由です。
fill 色の上書きは、<svg ... fill="currentColor"> を別色のバリアントとして量産したいときに便利です。元 SVG を 1 枚作っておけば、3 色違いの data URI を一度に生成できます。
🧐 よくある質問
url("...") と url('...') のどちらを選ぶべきですか?
PostCSS や Sass の文字列リテラルとの衝突を避けたい場面では single (') が無難です。プレーンな CSS だけなら double のほうがエスケープが少なく、わずかに軽くなります。
fill 上書きを使うと元の fill="currentColor" も書き換わりますか?
はい。fill= を含むすべての属性を置換します。currentColor の挙動を残したい場合は fill 欄を空にしてください。
base64 のほうが軽くなることはありますか?
あります。複雑な path で < や " が多い SVG、あるいは Sketch などからエクスポートされた XML 宣言・コメント込みのファイルは、パーセントエンコード後の文字数が膨らんで base64 を上回ることがあります。サイズ比較カードで実測してから採用するのが安全です。
xmlns 属性は省略してよいですか?
url() 経由で背景画像として描画する場合は必須です。<svg> を <img> の data URI にせず CSS 背景として使う場合、ブラウザは Image オブジェクトを通すので xmlns がないと描画されません。
256 KB を超える SVG は扱えませんか? ファイル読み込みは 256 KB で弾いていますが、これは「data URI に埋めて意味があるサイズ」の目安です。それより大きい SVG は別ファイルとして配信したほうが結果的に速くなります。
📚 豆知識
Yoksel が url-encoder で示した「< > # % と外側クォート相当だけを encode する」最小エンコード方式は、2016 年頃に GitHub の SVG icon インライン化トレンドと結び付いて広まりました。当時、CSS-in-JS が普及する前のクラシカルな CSS でアイコンを動的に切り替える定番手法の一つになり、Tailwind の bg-[url('data:image/svg+xml,...')] も実はこの系譜の上に乗っています。