Is this tool secure for sensitive data?

Yes, all processing runs entirely in your browser. No data is sent to any server, making it safe for sensitive information.

Which file types can I encode?

Any file type. The tool reads the raw bytes of whatever you drop in and produces the Base64 string, PDFs, images, audio, ZIPs, binaries, anything. Very large files slow the browser down; the Base64 output is roughly 33% larger than the original.

無料Base64ファイルエンコーダー

任意のファイルをBase64データURLに変換 · すべてブラウザ内で完結します。

ファイルをここにドラッグ＆ドロップ

または

エンコードするファイルを選択またはドロップしてください。

使い方

ファイルをアップロード: 画像、PDF、フォント、音声、バイナリなど任意のファイルをドロップゾーンにドロップするか、クリックして参照してください。
Base64文字列を取得: ファイルはブラウザ内で即座に読み込まれ、Base64にエンコードされます。
コピーして使用: Base64文字列をコピーして、HTML、CSS、JSONペイロード、データURI、その他のテキスト形式に埋め込みます。

Base64ファイルエンコーダーを使う理由

バイナリファイルはHTML、CSS、JSON、XMLなどのテキストベースの形式に直接埋め込むことができません。Base64エンコーディングは、任意のバイナリファイルを安全なASCII文字列に変換し、テキストが許可されるあらゆる場所に埋め込むことができます。これは、HTMLへの画像の直接埋め込み（データURI）、CSSへのフォントの含有、ファイルアップロードエンドポイントなしでのメールやJSON APIでのファイル送信、自己完結型HTMLドキュメントの作成に不可欠です。

機能

あらゆるファイルタイプ: 画像、PDF、フォント、音声、動画、その他すべてのバイナリファイルをエンコードします。
データURI出力: 切り替えて、そのまま使えるデータURI（data:mime/type;base64,...）を取得し、直接埋め込みできます。
ファイルサイズ表示: 元のサイズとエンコード後のサイズを表示し、オーバーヘッドを確認できます。
ローカル処理: ファイルはブラウザ内で完全に読み込まれ、エンコードされます, アップロードは行われません。

よくある質問

Base64は元のファイルと比べてどのくらい大きくなりますか？

Base64エンコーディングはファイルサイズを約33%増加させます。100 KBの画像はBase64エンコードすると約133 KBになります。このオーバーヘッドは、バイナリコンテンツをテキストに埋め込むためのトレードオフです。

HTMLでBase64画像を使用できますか？

はい。<img src="data:image/png;base64,[あなたのBase64]"> のようなデータURIを使用します。これにより、外部HTTPリクエストなしで画像をHTMLに直接埋め込めますが、ページサイズは増加します。

ファイルサイズの制限はありますか？

このツールには強制的な制限はありませんが、非常に大きなファイル（10 MB以上）はエンコードが遅くなり、結果の文字列は非常に長くなります。大きなファイルにはサーバーサイドのソリューションを検討してください。

Base64 はどこから来たのか、そしてなぜまだ使っているのか

Base64 は 7 ビット ASCII パイプを通じて 8 ビットバイナリデータを運ぶように設計されました。最初の正式な仕様は、Privacy-Enhanced Mail のための RFC 989(1987 年 2 月)でした。RFC 1341(1992 年 6 月)、特に RFC 2045「MIME パート 1」(1996 年 11 月)が、これをバイナリファイルをメールに添付する標準的な方法にしました。現在の正典文書は RFC 4648(2006 年 10 月)で、URL セーフバリアントも定義しています。仕組みは単純です。入力の 3 バイト(24 ビット)を取り、4 つの 6 ビットグループに分割し、64 文字のアルファベット A-Z a-z 0-9 + / でそれぞれを検索し、= パディングを追加して出力長を 4 の倍数にします。出力サイズは入力のちょうど 4 ÷ 3 ≈ 133 % です。URL への埋め込み(JWT、OAuth、S3 事前署名 URL)では、RFC 4648 §5 の URL セーフバリアントが + を - に、/ を _ に置き換えます。パディングは通常省略されます。

`data:` URL: HTML と CSS の Base64

data: URL スキームは RFC 2397(1998 年 8 月)で指定されました。フォーマット: data:[<mediatype>][;base64],<data>。例: <img src="data:image/png;base64,iVBORw0KGgo..."> は追加の HTTP リクエストなしで PNG をインライン埋め込みします。WHATWG URL Living Standard は現代のブラウザーがこれらの URL をどのように解釈するかを管理し、HTML Living Standard は URL が許可されているところすべて(<img>、<link>、<iframe>、CSS url() 関数を含む)で有効であることを確認します。実用的なガイダンス:約 4 KB 未満のアセットには data URL を使用してください。HTTP リクエストを 1 つ節約することが 33 パーセントのペイロード膨張を上回ります。10 KB を超えると、ブラウザキャッシングを使用した通常のファイル参照がほぼ常に勝ちます、特に HTTP/2 多重化において。

このツールを動かすブラウザ API

このページは HTML Living Standard の FileReader API を使用しています(元々 W3C File API First Public Working Draft 2009 年 11 月。Chrome 13 / Firefox 3.6 / Safari 6 / Internet Explorer 10 で出荷)。FileReader.readAsDataURL(blob) は完全な data:<mime>;base64,<...> 文字列を 1 つの呼び出しで返します。レガシーの代替手段は btoa()(歴史的な Unix「binary-to-ASCII」コマンドにちなんで名付けられ、JavaScript DOM Level 0 のホールドオーバー)ですが、非 Latin-1 入力では UTF-8 を介してトランスコードしない限りスローします。現代の代替品は Uint8Array.prototype.toBase64()で、TC39 Stage 4 で ECMAScript 2025 に追加されました。Chrome 132(2025 年 1 月)、Firefox 133(2024 年 11 月)、Safari 18.2(2024 年 12 月)で出荷されました。新しいコードには新しい API を使用してください。古いブラウザとの互換性のためには btoa を予約してください。

このツールの出力が実際にどこに行くか

HTML / CSS でのインラインアイコンと小さな画像、自己完結型またはオフライン優先のドキュメント用。
JSON ファイルアップロードペイロード、バックエンドが multipart/form-data ではなく JSON フィールドの Base64 文字列を期待する場合。
MIME メール添付ファイル: RFC 2045 はすべての非 7 ビットボディに Base64(または quoted-printable)を要求します。つまりすべての PDF、画像、文書添付ファイル。
JWT / OAuth トークン: すべての JWT は . で連結された 3 つの URL セーフ Base64 セグメントです。
テストフィクスチャを git にコミットすると、テスト画像 / サンプルドキュメントがテストファイルとともに移動します。
Push API を介してバイナリブロブを配信する場合の Web Push ペイロード。
ファーストペイントの FOIT(invisible text のフラッシュ)を避けるために CSS に埋め込まれた クリティカルパス Web フォント、トレードオフ受け入れ。

よくある間違い

Base64 を暗号化として扱う。Base64 はエンコーディングであり、セキュリティではありません。文字列を持っている人は誰でもブラウザでデコードできます。資格情報、API キー、または PII を「隠す」ために Base64 を絶対に使用しないでください。
data:<mime>;base64, プレフィックスを忘れる。裸の Base64 文字列は data URL ではありません。<img> がレンダリングするには完全な形式 data:image/png;base64,<your-base64> が必要です。
URL セーフと標準 Base64 を混在させる。JWT と S3 事前署名 URL は URL セーフ(- と _)を使用します。これらのコンテキストに標準 Base64(+ と /)を貼り付けると、サイレントなデコード失敗が発生します。
CSP data: ディレクティブを忘れる。Content Security Policy に img-src 'self' があるページは、すべての data:image/... URL のロードを拒否します。img-src 'self' data: を明示的に許可する必要があります(font-src、media-src などについても同様)。
メインスレッドで 100 MB のファイルを同期的にエンコードする。FileReader.readAsDataURL は 200 MB のファイルで UI を数秒間ブロックします。約 20 MB を超えるものについては、Web Worker またはストリームチャンクを使用してください。
btoa("é") を直接呼び出す。btoa は UTF-8 ではなく Latin-1 を期待するため、InvalidCharacterError をスローします。btoa(unescape(encodeURIComponent(text)))(レガシー)を使用するか、現代の toBase64() メソッドを介して Uint8Array を渡してください。
500 KB のロゴを data URL としてインライン化する。33 パーセントの膨張に加えてブラウザキャッシングの損失は、ページロードごとに 500 KB-1 回ではなく 665 KB をダウンロードすることを意味します。通常のアセット参照を使用してください。

その他のよくある質問

Base64 の正確なサイズオーバーヘッドは何ですか?

正確に入力の 4 ÷ 3 ≈ 1.333×、プラス 1-2 バイトの = パディング。999 バイトの入力は 1332 文字の Base64 になります(999 ÷ 3 = 333 ちょうどなのでパディングなし)。1000 バイトの入力は 1336 になります(1 バイトのパディング)。data URL の場合、プレフィックスバイトを追加してください(例えば data:image/png;base64, は 23 文字)。

JWT または S3 事前署名 URL の URL セーフ Base64 を取得するにはどうすればよいですか?

このツールから標準 Base64 出力を取り、2 つの置換を適用します: + → -、/ → _。JWT は特に末尾の = パディングを削除します。S3 はそれを保持します。RFC 4648 §5 がバリアントを文書化しています。

破損なしに Base64 を介してファイルをラウンドトリップできますか?

はい。Base64 はロスレスエンコーディングです。Base64 にエンコードしてから戻ってデコードすると、バイト単位で同一のオリジナルが生成されます。データを失う唯一の方法は、Base64 文字列を切り捨てる(例えばストレージで文字を制限する)、またはデコード時に標準と URL セーフのアルファベットを混同することです。

このツールが処理できる最大ファイルサイズは何ですか?

ハードな制限はありません。実際にはブラウザメモリが天井です。100 MB のファイルをエンコードするには、約 100 MB の入力プラス 133 MB の出力、加えて結果文字列の DOM オーバーヘッド、おそらく合計 400 MB が必要です。モバイルでは、約 30 MB を超えると失敗が予想されます。エンコーディングはメインスレッドで実行されるため、処理中に UI がフリーズします。20 MB を超えるファイルの場合、サーバーサイドまたは Web Worker ソリューションがより快適です。

私のファイルはどこかにアップロードされますか?

いいえ。ファイルはブラウザの FileReader.readAsDataURL API で読み取られ、完全にブラウザ内で実行されます。ネットワークリクエストは行われず、ファイルのコピーはどのサーバーにも保存されません。DevTools のネットワークタブを開いてファイルをドロップしてください: エンコーディング中にゼロの送信リクエストが表示されます。