画像をBase64の文字にする

画像を選ぶと data:image/png;base64,… の文字列と、 そのまま貼れる HTML・CSS を作ります。元の大きさと、文字にしたあとの大きさを並べて出します。

文字にすると、かならず約1.33倍にふくらみます

ここがこのページの本体です。画像を文字に直す仕組みは、3バイトを4文字に置きかえるものだと決まっています。 だから中身が何であっても、4を3で割った 1.333… 倍に必ず大きくなります。 小さくなることは一度もありません。

なぜ3と4なのかというと、置きかえる先の文字が64種類しか用意されていないからです。64は2を6回かけた数なので、 1文字で運べるのは6ビットぶん。もとの1バイトは8ビットです。 6と8の最小公倍数は24なので、24ビット（＝3バイト）が、6ビット×4文字で ぴったり収まります。ここが割り切れる最小の組み合わせでした。

表のいちばん下を見てください。1MiB の写真は1,398,104文字になります。 原稿用紙（400字）にするとおよそ3,500枚ぶんです。 これを HTML に直接書くと、その HTML 自体が同じ文字数ぶん重くなります。

この「約33パーセント増える」という言い方は、 電子メールの決まりを書いた文書にも、そのままの数字で載っています。1970年代からずっと同じ割合で、この先も変わりません。仕組みが3対4だからです。

実際にはもう少し増えます。1つは、いまから説明する末尾の =。 もう1つは改行で、メールの決まりでは1行76文字までと定められているため、 76文字ごとに改行が入って、そのぶんまた長くなります。 ただしこのページが作る data URL には改行を入れません ── URL の途中で行を折ることはできないからです。

終わりの「=」は、データではありません

Base64 の文字列の終わりに = が付いているのを 見たことがあると思います。これは中身を表している文字ではありません。4文字ぶんに足りなかったところを埋めた印です。

3バイトずつ取っていくので、最後にバイトが余ることがあります。そのときの決まりは 3通りだけです。

• ちょうど割り切れたとき ── = は付きません
• 1バイト余ったとき ── 2文字ぶんの中身になり、== が2つ付きます
• 2バイト余ったとき ── 3文字ぶんの中身になり、= が1つ付きます

ここが逆に見えるところです。余りが少ないほど、埋める印は多くなります。 埋めているのは「余った量」ではなく「4文字に足りなかった量」だからです。 1バイトしか無ければ、4文字のうち2文字ぶんも空いてしまう、というわけです。

なお、この印を省いてもよい場面はありますが、決まりの本文は「別の文書がそう言っていない限り、必ず付けなければならない」と書いています。長さが4の倍数になっていること自体が、途中で切れていないことの手がかりになるからです。

SVG は、Base64 にしないほうが短くなります

ここは知っていると得をするところです。絵を文字列にする書き方には、Base64 を使わない道もあります。

data URL の決まりを読むと、書き方はdata:・型・;base64・カンマ・中身、という並びで、3番目の「;base64」は省いてよいことになっています。 省いたときは、URL にそのまま置けない文字だけを%22 のような形に直して並べます。

SVG は中身が文字でできています。タグも数字も英字なので、直さなければいけない文字はごくわずかです。 いっぽう Base64 は、中身が何であろうと6ビットずつに刻み直すので、必ず1.33倍になります。だいたいの SVG では、 直さずに並べたほうが短くなります。

ただし「必ず短い」とは書きません。 飾りの多い SVG や、日本語の文字が入った SVG では逆になることもあります。 だからこの道具は、SVG を選んだときに両方の長さを実際に数えて、 短かったほうを出しています。

何バイトから損になるかは、自分で決められます

「埋め込むべきか、別ファイルのままにすべきか」に、決まった答えはありません。 ただし判断のもとになる数は、自分で出せます。

data URL の決まりを作った文書には、「この仕組みは短い値にだけ役立つ」とはっきり書かれていて、 続けて HTML の側に1024文字という上限の例が挙げられています。 では、1024文字に収まる PNG はどれくらいでしょうか。

data:image/png;base64, という書き出しだけで22文字使います。 残りは1,002文字。 4文字で3バイトを運ぶので、750バイトまで入る計算です。1キロバイトにも届きません。いま使っているブラウザがそこで切るわけではありませんが、この仕組みが想定している大きさが分かります。

もう1つ、大きさ以外に効くことがあります。埋め込んだ画像はHTML や CSS の一部になるので、その画像だけを取っておくことができません。 同じアイコンを10ページで使えば、10ページぶん重くなります。 逆に、そのページでしか使わない小さな絵なら、往復が1回減るぶんが効いてきます。

拡張子ではなく、中身の先頭を見ています

画像の形式は、ファイルの名前ではなく先頭のバイトで見分けています。 PNG なら「PNG」という3文字が、GIF なら「GIF89a」という6文字が、ファイルのいちばん先頭に必ず書いてあります。 JPEG は FF D8 FF という3つの数で始まります。

どの形式がどのバイトで始まるかは、ブラウザの作り方を決めているMIME Sniffing Standard（新しいタブで開きます）の表から取りました。ブラウザ自身が、送られてきたものが本当に画像かどうかを この表で確かめています。

だから、名前を .png に変えただけの JPEG を選んでも、JPEG だと見抜きます。 拡張子を信じて data:image/png と書いてしまうと、 その文字列は中身と違う名札を付けたまま配られることになります。

見分けられない形式もあります。AVIF や HEIC はこの表に載っていないので、この道具は形式を言い当てません。 そのときはブラウザが言ってきた型をそのまま使い、「言い当てたのではない」ことを画面に書きます。 分からないものを分かったふりで PNG と書いたりはしません。

文字を Base64 にしたいときは、別のページです

このページが引き受けているのは画像のファイルだけです。 文章や日本語を Base64 に直したいときや、Base64 の文字列を元に戻したいときは、Base64 とURLエンコードの変換のページが担当しています。 あちらは文字とバイト列の行き来を、 こちらはファイルの大きさがどう変わるかを引き受けています。

出どころ: 3バイトを4文字にする規則・末尾の = の数・検算用の値はRFC 4648（新しいタブで開きます）の4章と10章、「約33パーセント大きくなる」と「1行76文字まで」はRFC 2045（新しいタブで開きます）の6.8章、data URL の書き方と「短い値にだけ役立つ」「1024文字」はRFC 2397（新しいタブで開きます）から取りました。表の数はすべてその場で計算していて、手で書き写した数はありません。