Base64 パディング処理

GeekFormat について

入力

文字 . お問い合わせ

入力

文字 . お問い合わせ

結果

{count 文字 =change} = 0

ブラウザ内で RFC 4648 標準に従い、Base64 末尾に必要な = padding の数を自動計算します。パディング追加と削除の双方向変換に対応し、規格に合わない Base64 文字列を修復します。すべてローカルで完結します。

Base64 パディングとは？

Base64 パディングとは RFC 4648 標準で規定された '=' 文字で、Base64 の出力長を 4 の倍数に揃えるためのものです。Base64 は 3 バイト（24 ビット）を 4 文字にマッピングしますが、末尾が 3 バイトに満たない場合は = でパディングを追加する必要があり、これがないとデコーダは末尾の実際のバイト数を判断できません。

パディングルール：① 元バイト数 mod 3 = 0 → 末尾 0 個の =；② mod 3 = 1 → 末尾 2 個の =；③ mod 3 = 2 → 末尾 1 個の =。任意の Base64 文字列の長さ mod 4 の結果は、不足している = の数と必ず一致します。

なぜパディングが必要か：Base64 のデコードには明確な境界が必要です。パディングがあることで、デコーダは末尾の = が何バイトに対応するのかを判別でき、曖昧さを避けられます。パディングがないと、1 バイトと 2 バイトの入力が同じ長さの Base64 にエンコードされ、デコード時にバイト数を判別できなくなります。

実際の用途：ほとんどのプロトコル（Data URL、MIME、JWT、設定ファイル）はパディングを厳格に守ります。一方、URL パス、ファイル名、短縮 URL など文字数を節約したい場面ではパディングを省略することもあります。本ツールは両方向の変換に対応しています。

ユースケース

Base64 デコードで発生するエラー（InvalidCharacterError や長さが 4 の倍数でないなど）を修復するため、まず = をパディング追加してからデコードする。
API、JWT、ログから取得した Base64 出力に対して、余分な改行や不足している padding を一括で整える。
Data URL を生成する際、Base64 部分が RFC 4648 に厳密準拠するようにし、ブラウザやサードパーティツールでのデコード失敗を防ぐ。
JWT トークン、設定ファイル、API クレデンシャルなどに対し、padding のチェックと追加を素早く行う。
URL やファイル名など、文字数を節約したい用途でパディングを削除する（プロトコルがサポートしている前提）。
Base64 エンコードの原理を学ぶ際に、入力バイト数と padding 数の対応関係を比較して確認する。

使い方

処理したい Base64 文字列を貼り付けるか入力します（padding の有無や改行があっても構いません）。
モードを選択します：追加モード（末尾に = を付加）または削除モード（末尾の = を除去）。
ツールが自動で結果を計算して表示し、文字数や padding の増減をリアルタイムで確認できます。
結果をクリップボードにコピーするか、.txt ファイルとしてダウンロードして後続の処理に利用します。

特徴

パディング数の自動計算：現在の入力に必要な = の数と既存の = の数の差をリアルタイムで表示します。
追加モード：任意の Base64 文字列を 4 の倍数長にパディング追加し、長さエラーをワンクリックで修復します。
削除モード：末尾の = を取り除き、URL やファイル名など文字数を節約したい場面に適しています。
改行・空白の自動無視：メールや JWT 出力に由来する改行付きの Base64 を貼り付けても正しく処理します。
リアルタイム文字数カウント：入力文字数、出力文字数、パディングの増減数を表示します。
ワンクリックコピー / ダウンロード：結果をクリップボードへコピーしたり、.txt ファイルとしてダウンロードできます。
ブラウザ内ローカル処理：すべての計算はブラウザ内で行われ、元のコンテンツはどのサーバーにもアップロードされません。

Best Practices

パディング追加前に、入力が本当に Base64 か確認する

本ツールは末尾の = を追加するだけで、無効な文字を除去する機能はありません。入力に空白・中国語・改行以外の不正文字が混入していると、デコードは依然として失敗します。まずは Base64 クリーンアップツールで英数字以外の文字を取り除くことを推奨します。

Data URL と JWT では必ずパディングを付ける

Data URL（RFC 2397）と JWT（RFC 7519）はどちらもパディングを厳格に要求します。= を省略すると、多くの実装でデコードエラーや結果の不一致が発生します。送信前に本ツールで 4 の倍数長までパディング追加してください。

URL/ファイル名ではパディング省略可、ただし URL-safe 文字セットとセット

Base64 を URL パスやファイル名、短縮 URL に使う場合、padding を削除するだけでは不十分で、+ と / を - と _ に置換（Base64URL）する必要があります。= を省略しただけでは通常の標準 Base64 のままで、+ や / は URL 内で依然として不正です。

パディング削除後にデコードで「長さエラー」が出る

対象のツールがパディングを厳格に要求していることを意味します。追加モードに切り替えてから再度デコードを試してください。それでも失敗するなら、削除の過程で末尾以外の = を誤って消した可能性があり、入力そのものが不正です。

大きなファイルは先に分割してから処理する

本ツールは単一の Base64 文字列を想定しています。数十 MB 規模の Base64 エンコードファイルを扱う場合は、openssl base64 などのコマンドラインツールか、コード内で直接処理し、ブラウザのフリーズを避けてください。

教材やドキュメントでは padding 計算式も併記する

Base64 パディングは初心者が最もつまずきやすいポイントです。説明時には必ず「入力バイト数 mod 3 = 余り、それに応じた = の数」という対応表（当ページの referenceTables を参照）を添えてください。そうしないと、なぜ 1 個の場合と 2 個の場合があるのかが理解されません。

よくある質問

Base64 パディングは何のためにありますか？

Base64 出力の長さを常に 4 の倍数に揃え、デコーダに明確な終端境界を与える役割です。パディングがないと、1 バイトと 2 バイトの入力が同じ長さの文字列にエンコードされ、デコーダは元のバイト数を判別できません。

なぜ Base64 の長さは 4 の倍数でなければならない？

Base64 は 3 バイトを 4 文字にマッピングする固定比率のエンコード方式であるためです。入力が 3 の倍数に満たない場合、4 文字に揃えるために = でパディング追加する必要があります。4 の倍数でない Base64 は規格違反であり、不正なエンコードとみなされます。

パディングの数はどうやって計算する？

式は (4 - 入力バイト数 % 3) % 3 で、Base64 文字数を 4 で割った余りからも判定できます：余り 0 → 0 個、余り 2 → 1 個、余り 3 → 2 個の = が必要です。本ツールは自動で計算します。

パディングは削除できますか？

削除自体は可能ですが、プロトコルがサポートしている場合に限られます。例えばファイル名、URL パス、一部の JWT 実装はパディングなし Base64 を許容しますが、Data URL、MIME、設定ファイルは通常厳格に要求します。本ツールの削除モードは、プロトコルがサポートしていることを確認できた場合にのみご利用ください。

Base64 デコードで「長さが 4 の倍数ではありません」と表示されたら？

本ツールの追加モードに切り替えて、末尾に = をワンクリックで追加してください。それでもエラーが出る場合は、入力自体に不正な文字が含まれているか、途中で切り詰められている可能性があるため、Base64 クリーンアップツールで先に確認しましょう。

パディングを追加すると元のバイトは変わりますか？

変わりません。パディング追加は末尾に = を付け加えるだけなので、中間の文字は一切変更されず、元のバイトは完全に保持されます。デコード結果は元のデータとバイト単位で一致します。

改行や空白を含む Base64 に対応していますか？

はい、対応しています。本ツールは改行・復帰・空白を自動で除去してからパディングを計算します。メール添付、JWT 出力、設定ファイルに含まれる複数行の Base64 をそのまま貼り付けて問題ありません。

Base64 パディングと Base64URL は同じものですか？

別物です。Base64 パディングは末尾の = 文字の有無に関する話で、Base64URL は文字セットの話（+ を - に、/ を _ に置換）です。本ツールはパディングのみを扱いますので、URL-safe 変換には専用の Base64URL ツールをご利用ください。

内容はサーバーにアップロードされますか？

アップロードされません。すべてのパディング計算はブラウザ内でローカルに実行され、元の Base64 文字列がデバイスの外に出ることはありません。機密性の高いデータ（クレデンシャル、token）も安心してご利用いただけます。

トラブルシューティング

デコードで「長さが 4 の倍数ではありません」と表示される

本ツールの追加モードで = をパディング追加してから再度デコードしてください。それでもエラーが出る場合は、入力に不正な文字が含まれているため、Base64 クリーンアップツールで先にチェックすることをおすすめします。

入力に不正な文字が混入している疑いがある

標準 Base64 は A-Z a-z 0-9 + / = のみを含み、それ以外の文字（中国語、空白、改行以外の記号）はすべて不正です。本ツールは改行と空白を自動で無視しますが、その他の不正文字は Base64 クリーンアップツールで先に除去する必要があります。

パディング削除後も URL でエラーが出る

URL に ? & = など URL エンコードが必要な文字が残っているか、Base64 文字セットに含まれる + / などが含まれている可能性があります。パディング削除は URL-safe 化を意味しないため、Base64URL 変換や URL エンコードを追加で行ってください。

貼り付けても何も表示されない

入力がすべて空白文字（改行、スペース、タブ）の可能性があります。本ツールはこれらの空白を無視して計算しますが、完全に空白のみの入力は結果を生成しません。Base64 文字を少なくとも 1 文字以上入力してください。

用語集

padding = 文字: RFC 4648 標準で規定された Base64 末尾のパディング文字で、不足している実バイトを示す役割を持ちます。有効なパディングは文字列末尾にのみ現れます。
4 の倍数: RFC 4648 標準における Base64 の出力長は 4 の倍数でなければならないと規定されています。デコード時に厳格 Base64 モードでは違反すると即エラーになります。
padding 計算式: 必要な = 数 = (4 - 入力バイト数 % 3) % 3。これは Base64 文字数 mod 4 を見ることと同じで、結果 0/2/1 はそれぞれ 0/1/2 個の = に対応します。
パディングなし Base64: 末尾の = を省略した Base64 の変種で、URL パスやファイル名でよく使われますが、厳密には RFC 4648 標準に準拠しないため一部のプロトコルではデコードに失敗します。
Base64 文字セット: A-Z、a-z、0-9、+、/ の合計 64 文字に加え、= がパディングに使われます。それ以外の文字は無効であり、Base64 クリーンアップツールで先に除去する必要があります。

Base64 パディングルール早見表

Base64 入力バイト数と末尾 = padding 数の対応関係です。

入力バイト数	mod 3	Base64 文字数	= padding 数	例（入力→出力）
`3n`	0	`4n`	0	ABC → QUJD
`3n+1`	1	`4n+2`	2	AB → QUI=
`3n+2`	2	`4n+3`	1	A → QQ==

主なプロトコルの padding 要件

プロトコルごとに = padding の要件は異なり、誤って省略するとデコードに失敗します。

利用シーン	padding 要否	典型的な用途
`Data URL (RFC 2397)`	推奨（互換性のため）	HTML / CSS / 画像埋め込み
`JWT (RFC 7519)`	必須（厳格）	OAuth / API 認証
`MIME (RFC 2045)`	必須	メール添付エンコード
`URL パス / ファイル名`	任意（多くは省略）	短縮 URL / キャッシュキー
`設定ファイル（YAML / JSON）`	必須	クレデンシャル・署名保存