Kit — Base64 変換

Base64 エンコード・デコード

テキストは入力しながら双方向に変換。ファイルは Base64 とデータURLに変換でき、逆に貼り付けてファイルとして保存もできます。日本語や絵文字も壊れず、デコードに失敗したときは何行目の何文字目が不正かまで表示します。

URLやファイル名、JWTなどに埋め込むときの形式です。デコード側は両方の形式を自動で受け付けます。

Base64

まだ何もありません

この処理はブラウザ内で完結します。ファイルはどこにも送信されません。

ほかの Base64 ツールと違うところ

日本語で壊れない

ブラウザ標準の btoa は Latin-1(1文字=1バイト)しか受け付けず、日本語を渡すと例外になります。よく出回る回避策は非推奨の関数に依存しています。ここでは UTF-8 のバイト列に変換してから符号化するため、日本語も絵文字も結合絵文字もそのまま往復します。

失敗した場所を教える

デコードできない Base64 の原因は、たいてい1文字だけです。全角スペース、チャットアプリが変換した引用符、途中で切れた末尾。ここでは「何行目の何文字目のどの文字か」を出すので、3000文字の中から目で探す必要がありません。

貼り付けたまま受け付ける

メールは Base64 を76文字ごとに折り返します。JWT や URL のものは記号が -_ で、末尾の = が落ちています。どれもそのまま貼れば通ります。整形し直してから貼る必要はありません。

Base64 の基礎

Base64 は暗号化ではありません鍵がなく、誰でも即座に元に戻せます。読めないのは人間だけで、保護にはまったくなりません。パスワードやAPIキーを Base64 にして設定ファイルに書いても、隠したことにはなりません。Base64 の目的は「バイナリを、テキストしか通らない経路に安全に通すこと」です。
なぜ約1.33倍になるのか3バイト(24ビット)を6ビットずつ4文字に割り当てる方式のため、必ず 4/3 = 約133%になります。パディングの分だけさらに数バイト増えます。画像をデータURLで埋め込むと転送量が3割増える、というのはこの計算がそのまま効いています。
URLセーフ形式はいつ必要か標準の Base64 が使う + と / は、URLのクエリ文字列やファイル名では別の意味を持ちます。そこで + を -、/ を _ に置き換えたのが URLセーフ形式です。JWT の各パートはこの形式で、末尾のパディング = も省略されています。
データURLの使いどころと限界data:image/png;base64,... の形にすると、画像を外部ファイルにせず HTML や CSS に直接埋め込めます。小さなアイコンではリクエストが1回減って有利ですが、大きな画像では転送量が1.33倍になるうえキャッシュも効かなくなるため、たいてい逆効果です。

よくある質問

日本語や絵文字はそのまま戻りますか?

戻ります。UTF-8 として符号化しているため、往復しても内容は変わりません。ただし相手のシステムが別の文字コード(Shift_JIS など)を前提にしている場合は、そちらでは正しく読めません。

メールからコピーした Base64 に改行が入っています

そのまま貼り付けてください。改行・スペース・タブはすべて無視して復号します。多くのメール転送方式が76文字ごとに折り返すため、これは異常ではありません。

どのくらいのサイズのファイルまで扱えますか?

25MBまでです。変換中は元データ・中間データ・Base64 文字列がすべてメモリ上に同時に存在するため、上限を設けています。また Base64 が非常に長い場合は画面表示を省略しますが、コピーと保存は通常どおり使えます。

貼り付けた内容やファイルは送信されますか?

送信されません。変換はすべてブラウザ内で行われ、ページを閉じれば消えます。ただし Base64 は暗号化ではないため、変換結果をどこかに貼る際は元の内容が読めることを前提にしてください。

JWT の中身を見られますか?

ドット(.)で区切られた2番目の部分を貼り付ければ、ペイロードのJSONが読めます。URLセーフ形式・パディングなしでも受け付けます。ただし署名の検証は行いません(内容の真正性は確認できません)。