> エンコード | デコード | 実行 <

A: 64文字アルファベットを使用したBase64バイナリからテキストエンコードスキーム。Base64データ変換、画像埋め込み、メール添付、APIデータ転送に不可欠。

A: 100%無料Base64コンバーター。ファイルサイズ制限なし。無制限Base64エンコード/デコード操作。ローカルBase64処理のみ。

A: 100%安全Base64処理。ローカルBase64エンコード/デコード。サーバーアップロードゼロ。あなたのBase64データはデバイスから離れません。

A: 標準Base64は+/文字を使用。URL安全Base64は-_文字を使用。URL安全Base64はウェブURL、ファイル名、HTTPヘッダーに最適。

A: はい。画像からBase64コンバーター: /image-to-base64/。PNG、JPG、GIF、SVG Base64エンコードをサポート。全ファイル形式対応。

A: Base64はエンコード、暗号化ではありません。Base64は可逆データ表現。安全ではありません。セキュリティにはAES暗号化を使用、Base64ではありません。

A: 高速Base64エンコーダー/デコーダー + オフラインBase64処理 + ファイルサイズ無制限 + URL安全Base64 + 高度オプション + 完全無料。

A: Base64 は、任意のバイナリデータを A–Z、a–z、0–9、+、/ の 64 種類の ASCII 印字可能文字だけで表現するエンコード方式です（RFC 4648 §4）。3 バイト（24 bit）を 4 文字（各 6 bit）に変換するため、出力サイズは元の約 4/3（+33%） になります。メール、JSON、URL、HTTP ヘッダーなどテキストしか通さない経路にバイナリを安全に載せたいときに使います。Base64 は暗号化ではありません。誰でも逆変換できるため、機密データは別途 AES などで暗号化してください。

A: 上のテキストエリアに Base64 文字列を貼り付け、[デコード] を押すだけで UTF-8 のテキストに復号されます。処理はすべてブラウザ内で完結するため、API キーや秘密鍵を含む文字列もサーバーへ送信されません。結果は [コピー] ボタンでワンクリックでクリップボードに入ります。Base64URL（-/_）も自動で判別します。

A: 日本語も含め任意のテキストを入力して [エンコード] を押してください。内部では一度 UTF-8 にエンコードしてから Base64 化するため、「こんにちは」のようなマルチバイト文字も正しく扱えます。パディング（=）を外したい場合や URL に貼り付けたい場合は --url安全 / --パディングなし オプションを切り替えてください。

A: 標準の btoa() / atob() は Latin-1 しか受け付けず、日本語をそのまま渡すと InvalidCharacterError になります。UTF-8 込みで扱うには次のイディオムが定番です：

// encode
const b64 = btoa(unescape(encodeURIComponent('こんにちは')));
// decode
const text = decodeURIComponent(escape(atob(b64)));

A:
Node.js：Buffer.from('こんにちは').toString('base64') / Buffer.from(b64, 'base64').toString('utf8')
Python：import base64; base64.b64encode('こんにちは'.encode()).decode() / base64.b64decode(b64).decode()
PHP：base64_encode($str) / base64_decode($b64)
シェル：printf 'こんにちは' | base64（macOS では base64 <<< 'こんにちは'）

A: Base64 は 3 バイト単位で 4 文字に変換するため、元データのバイト数が 3 の倍数でない場合は末尾に =（余った場合）または ==（1 バイトだけ残った場合）を付けて 4 文字の倍数に揃えます。RFC 4648 標準ではパディングが必須ですが、JWT / OAuth / WebAuthn など URL に載せるケースではパディングを省略するのが慣例です。長さから自動復元できるため実害はありません。

A: アルファベットの最後 2 文字が異なります。
• 標準 Base64（§4）：+ と / を使用。URL/ファイル名では特別な意味を持つのでそのままでは不便。
• Base64URL（§5）：-（ハイフン）と _（アンダースコア）に置き換え、パディング = も省略するのが通例。URL・HTTP ヘッダー・Cookie・ファイル名にそのまま入れられます。
エンコード対象のバイト列は同じなので、3 文字だけ置換すれば相互変換できます。詳しくは /ja/base64url/ をご覧ください。

A: 固定で約 33% 増えます（正確には ceil(n/3)*4 バイト）。さらに多くのフォーマットでは 76 文字ごとに改行が入るため、改行分だけ僅かに増えることがあります。HTTP で Base64 文字列を送る場合は gzip / brotli を有効にすると Base64 は圧縮が効きやすく、実効オーバーヘッドは数 % 程度にまで縮みます。

A: data: スキームを使い、外部ファイルを参照する代わりにバイナリを HTML / CSS に直接埋め込む仕組みです。書式は data:<mime>;base64,<payload>。例：<img src="data:image/png;base64,iVBORw0KGgo…">。HTTP リクエストを 1 回減らせる反面、キャッシュが効かず HTML/CSS 自体のサイズが膨らむため、2 KB 未満のアイコンに使うのが基本ルールです。画像変換は /ja/image-to-base64/ から行えます。

A: 文字列→バイト列→Base64 の順に処理する限り問題ありません。文字化けが起きる典型例：(1) Shift_JIS / EUC-JP のバイト列を Base64 化した文字列を UTF-8 として復号した、(2) ブラウザで btoa('こんにちは') を直接呼び InvalidCharacterError が出た、(3) 片側だけ encodeURIComponent を通した。本ツールは常に UTF-8 を前提に処理するので、他システムからの文字列を扱う際は相手側の文字コードを確認してください。

A: なりません。Base64 は公開されたエンコード規則で、鍵もなく 1 行のコードで戻せます。パスワード、API キー、個人情報、医療情報などを Base64 だけで「隠した」つもりになるのは重大な設計ミスです。機密性が必要な場合は AES-GCM や ChaCha20-Poly1305 のような認証付き暗号を使い、必要に応じてその結果を Base64 で文字列化してください。