Base64エンコーダー・デコーダーの使い方 – オンラインでデータをエンコード・デコード

Base64エンコーディングはデータサイズを正確に33.3%（4/3比）増加させます。3バイトのバイナリ入力ごとに4バイトのBase64出力が生成されます。150KBの画像は200KBのBase64文字列になります。100KBを超えるファイルでは、サイズペナルティがほぼ常に埋め込みの利便性を上回ります。データURIの代わりに通常のファイルURLを使用してください。

Base64は暗号化ではなくエンコーディングです。Base64文字列を見た人は誰でも即座にデコードできます。キー、パスワード、秘密はありません。パスワード、APIキー、機密ユーザーデータの保護にBase64を決して使用しないでください。セキュリティが重要な場合は、AES-256-GCMまたは類似の認証付き暗号化アルゴリズムを使用し、その後オプションで暗号化されたバイナリ出力をテキストセーフな保存や転送のためにBase64エンコードしてください。

JWT（JSON Web Token）の場合、各セグメント（ヘッダー、ペイロード、署名）は独立してBase64URLエンコードされています。形式はheader.payload.signatureで、各部分がドットで区切られています。中央のセグメントをデコーダーに貼り付けて、JWTライブラリなしでトークンのクレーム（ユーザーID、有効期限、発行者、スコープ）を検査できます。

HTMLやCSSにデータURIとして画像を埋め込む場合、常に正しいMIMEタイプを指定してください。PNG画像にはdata:image/png;base64,、JPEGにはdata:image/jpeg;base64,、SVGにはdata:image/svg+xml;base64,を使用します。誤ったMIMEタイプはブラウザがバイナリデータを誤って解釈し、壊れた画像を表示する原因となります。SVGの場合は、Base64の代わりにテキストベースのdata:image/svg+xml,形式の使用を検討してください。そちらの方が小さく、人間が読めます。

URLセーフBase64は、+文字を-に、/を_に置き換えて、エンコードされた文字列をURL、クエリ文字列パラメータ、ファイル名でパーセントエンコーディングなしで安全に使用できるようにします。標準の+と/はURLコンテキストで特別な意味を持ちます（+はクエリ文字列でスペースを表し、/はパスセパレータです）。エンコードされたデータをURLに埋め込む場合は常にURLセーフBase64を使用してください。

1MBを超えるファイルをBase64エンコードしないでください。その閾値を超えると、33%のサイズ増加とブラウザのメモリオーバーヘッドによりエンコードが遅くなり、数十万文字の扱いにくい文字列が生成されます。大きなファイルの場合は、代わりにmultipart/form-dataアップロード、直接ファイルURL、またはクラウドストレージのオブジェクトURLを使用してください。

16進エンコーディング（Base16）はBase64の代替で、16文字（0-9、A-F）を使用し、データサイズが2倍になります（Base64の33%に対して100%のオーバーヘッド）。バイナリデータのコンパクトなテキスト表現が必要な場合はBase64を使用してください。デバッグ用にバイトレベルの可読性が必要な場合は16進を使用してください。各バイトが正確に2つの16進文字になり、個々のバイトの検査が容易になります。

Base64文字列の末尾の=パディング文字は、元のデータで最後の3バイトブロックのうち何バイトが不足していたかを示します。1つの=は2バイトのパディング（入力がフルブロックより1バイト不足）を意味します。2つの==は4バイトのパディング（入力が2バイト不足）を意味します。=のないBase64文字列は、入力長が正確に3で割り切れたことを意味します。パディングはデコードに数学的に必要ですが、デコーダーが正しい長さを推測する場合、URLセーフコンテキストでは省略できます。

メールシステムでは、Base64はMIME（Multipurpose Internet Mail Extensions）標準によって、テキストベースのメール形式内でバイナリ添付ファイルをエンコードするために使用されます。メールに画像やPDFを添付すると、メールクライアントはファイルをBase64エンコードし、受信者のクライアントに元のファイルタイプとデコード方法を伝えるMIMEヘッダーで包みます。これは、生のメールソースでContent-Transfer-Encoding: base64ヘッダーと共に見られるのと同じBase64エンコーディングです。