Base64 エンコード
テキストやファイルを Base64 に変換します。絵文字・アクセント付き文字・日本語も UTF-8 として正しくエンコードされ、URL セーフを選べば URL や JWT にそのまま使える文字列になります。
Latin-1 ではなく UTF-8 で正しく処理
ブラウザ標準の `btoa` は Latin-1 の範囲外でエラーになるため、簡易スクリプトでは日本語が壊れがちです。このツールは先に UTF-8 のバイト列へ変換するので、「café」「日本語」や絵文字も正確に往復します。UTF-8 を前提とする環境でデコードすれば元に戻ります。
トークンやクエリ文字列向けの URL セーフ出力
標準の Base64 は URL 上で意味を持つ `+` と `/` を使い、`=` のパディングもエスケープが必要になりがちです。URL セーフを選ぶとそれぞれ `-` と `_` に置き換えられ、パディングも省かれます。JWT や OAuth の state パラメータで使われている形式です。
ファイルにも対応(データ URI 用の画像も)
ファイルを選ぶとそのバイト列をエンコードします。`data:image/png;base64,` の後ろに貼れば CSS や HTML に画像を埋め込めますし、書類を Base64 文字列で受け取る API にも使えます。処理は手元で行うためアップロードの待ち時間はありません。
よくある質問
ファイルやテキストは送信されますか?
いいえ。貼り付けた内容がブラウザの外に出ることはありません。ページは小さな JavaScript を読み込むだけで、計算はすべて手元の端末で行われます。送信先のサーバーそのものが存在しません。 証明書や認証情報を Base64 にする場面は多いため、読み込み後はオフラインでも動作するように作られています。
Base64 は暗号化ですか?
違います。ここははっきり書いておきます。Base64 は符号化であって暗号化ではありません。鍵なしで誰でも即座に復号できます。バイナリをテキスト経路で運ぶために使うものであり、パスワードやトークンを隠す用途には使えません。
改行はどんなときに必要ですか?
メール(MIME)は 76 文字ごと、PEM 形式の証明書は 64 文字ごとの改行を求めます。一方で多くの API やデータ URI は改行のない 1 行を期待します。対象の仕様が求めていない限り、改行は入れないでください。
出力が元より 3 割ほど大きくなるのはなぜ?
Base64 は 3 バイトを 4 文字の ASCII で表すため、エンコード後はおよそ 133% の大きさになり、さらにパディングが加わります。テキストしか通せない経路でバイナリを安全に運ぶための代償です。