Base64 エンコーダー & デコーダー

はじめに

Base64 エンコーダー & デコーダーは、テキストを Base64 に変換し、Base64 をテキストに戻すための無料オンラインツールです。両方の操作は入力中にリアルタイムで行われ、ページのリロードや送信ボタンは必要ありません。ツールはブラウザ上で完全に実行され — サーバーに送信されるものは何もありません。

同じページに 2 つの独立したセクションがあります：エンコード用とデコード用です。各セクションには独自のテキストエリア、アップロードゾーン、アクションボタンがあり、モードを切り替えることなく双方向で作業できます。

Base64 とは

Base64 は、印刷可能な ASCII 文字のみを使用してバイナリデータを表現する方法です。暗号化や圧縮方式ではなく — テキスト用に設計されたシステム上でバイナリデータを安全に転送することを目的としています。

エンコードの仕組み

Base64 アルファベットは 64 文字を使用します：

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

エンコードプロセスは入力を 3 バイト（24 ビット）のグループに分割し、各グループを 4 つの 6 ビット値に分割します。各 6 ビット値（0–63）はアルファベットの 1 文字にマッピングされます。

入力：       F   o   o
バイナリ：   01000110 01101111 01101111
6 ビット：  010001 100110 111101 101111
10 進数：   17     38     61     47
Base64：    R     b    9     v

"Foo" は Rm9v にエンコードされます。

なぜ 64 なのか

64 が選ばれたのは、ほぼすべての文字セットで利用可能な文字（英字、数字、2 つの句読点）のみを使用する最大の 2 のべき乗だからです。これにより、Base64 は非 ASCII バイトを歪めたり拒否したりする可能性のある電子メールシステム、JSON ペイロード、URL、その他のテキストベースのチャネルで信頼性が高くなります。

各 Base64 文字は 6 ビットの情報を運びます（1 バイトは 8 ビット）。この 6:8 の比率が、エンコードされた出力が元の入力より約 33 % 大きくなる理由です — このトピックは後で詳しく説明します。

入力が 3 バイトの倍数でない場合

最後のグループが 3 バイト未満の場合、パディングが追加されます。エンコーダーは = 文字を追加して出力長を 4 の倍数にします：

• 残り 1 バイト → Base64 文字 2 個 + ==
• 残り 2 バイト → Base64 文字 3 個 + =
• 3 バイト完了 → Base64 文字 4 個、パディングなし

例えば、"Fo"（2 バイト）は Rm8= にエンコードされます。

Base64 ではないものについての注意

Base64 は出力が意味不明に見えるため、暗号化と混同されることがよくあります。すぐにデコードすると、鍵なしで元のテキストが明らかになります。データを保護する必要がある場合は、適切な暗号化アルゴリズム（AES、ChaCha20 など）を使用し、暗号化されたバイトを転送用に Base64 でエンコードしてください。Base64 だけでは機密性は提供されません。

Base64 の一般的な使用例

Base64 は Web 上の多くの日常的な場所に現れ、ユーザーが気付かないことがよくあります。

Data URI

最新のブラウザでは、data: URI を使用して画像、フォント、その他のメディアを HTML や CSS に直接埋め込むことができます：

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA...">

Base64 エンコードされた画像データは HTML ファイル自体に存在し — 別途 HTTP リクエストは必要ありません。これは小さなアイコン、スプライト、Web フォントで一般的で、追加の HTTP ラウンドトリップがインラインバイトよりもコストがかかる場合に使用されます。

ただし、Base64 Data URI は大きなアセットには常に最適な選択とは限りません。33 % のサイズオーバーヘッドにより、100 KB のアイコンが 133 KB のインラインテキストになり、ブラウザは HTML ページとは別にキャッシュできません。ほとんどのサイトでは、数キロバイト未満のアセットにのみ Data URI を使用しています。

JWT と API トークン

JSON Web Token は Base64url（URL セーフバリアント）を使用して、トークンのヘッダー、ペイロード、署名セグメントをエンコードします。このような JWT を検査したことがある場合：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

ドットで区切られた各セグメントは Base64url エンコードされた JSON です。任意のセグメントをこのツールのデコードセクションに貼り付けて、その内容を検査できます。

メール添付ファイル（MIME）

電子メールはもともと 7 ビット ASCII 用に設計されました。バイナリの添付ファイル（画像、PDF、スプレッドシート）を送信するために、MIME 標準はそれらを Base64 としてエンコードします。メールクライアントはメッセージを開くときに自動的にデコードします。

時々混乱を引き起こす詳細：MIME Base64 は慣習的に 76 文字ごとに改行します。メールソースから Base64 データを抽出すると、埋め込まれた改行が含まれている可能性があります。このツールのデコーダーは改行を自動的に処理するため — 前処理なしで複数行の MIME Base64 を貼り付けることができます。

PEM 証明書と鍵

SSL/TLS 証明書と秘密鍵は PEM 形式で配布され、Base64 エンコードされた DER データをヘッダー行とフッター行でラップします：

-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw
...
-----END CERTIFICATE-----

PEM は基本的にラベル付きラッパー付きの Base64 です。PEM ファイルの Base64 本文をデコードして、生の DER コンテンツを検査できますが、結果はバイナリであり、読み取り可能なテキストではありません。

HTTP ベーシック認証

HTTP Basic auth ヘッダーは ユーザー名:パスワード を Base64 としてエンコードします：

Authorization: Basic YWRtaW46c2VjcmV0

文字列 YWRtaW46c2VjcmV0 は admin:secret の Base64 エンコードです。Base64 はここではシリアライゼーションメカニズムであり、セキュリティではありません — 認証情報はヘッダーを見た人なら誰でも簡単にデコードできます。

.b64 ファイルとは

.b64 ファイルは、その内容全体が Base64 文字列であるプレーンテキストファイルです。.b64 拡張子は「このファイルは Base64 データを含んでいます」という命名規則です — 任意のテキスト、ソースコード、バイナリ形式とは異なります。

.b64 ファイルに遭遇する可能性がある場面：

• このようなツールからエンコードされた出力をエクスポートする
• 暗号鍵や証明書をポータブルなテキスト形式で保存する
• ファイルベースのワークフローを使用するシステム間で Base64 データを交換する

.b64 ファイルはプレーンテキストなので、任意のテキストエディタで開き、内容を確認したり、文字列をデコーダーにコピーしたりできます。このツールは、エンコードセクションとデコードセクションの両方で、ドラッグ＆ドロップまたはファイル選択により .b64 ファイルを受け付けます。

仕組み

ツールはブラウザの組み込み Base64 関数を UTF-8 セーフティのための追加レイヤーとともに使用します。

コア変換

JavaScript は Base64 用に 2 つのネイティブ関数を提供します：

• btoa(入力) — 文字列を Base64 に変換（バイナリ→ASCII）
• atob(入力) — Base64 を文字列に戻す（ASCII→バイナリ）

これらの関数は Latin-1（ISO-8859-1）文字でのみ機能します。中国語、日本語、絵文字など、Latin-1 範囲外の文字を含む文字列を渡すと、btoa() は DOMException をスローします。

UTF-8 セーフなエンコード

すべての Unicode テキストを正しく処理するために、ツールはネイティブ関数をラップします：

function encode(text, urlSafe, noPad) {
  let utf8 = encodeURIComponent(text);
  let base64 = btoa(utf8);
  if (urlSafe) base64 = base64.replace(/\+/g, '-').replace(/\//g, '_');
  if (noPad) base64 = base64.replace(/=+$/, '');
  return base64;
}

function decode(base64) {
  let restored = base64.replace(/-/g, '+').replace(/_/g, '/');
  while (restored.length % 4 !== 0) restored += '=';
  let utf8 = atob(restored);
  return decodeURIComponent(utf8);
}

encodeURIComponent はテキストを UTF-8 パーセントエンコード形式に変換し、btoa が処理できる ASCII 文字のみを含むようにします。デコードパスは逆の順序でこれを元に戻します。

これが重要である理由を確認するには、絵文字 "😊" を btoa で直接エンコードしてみてください — エラーがスローされます。UTF-8 ラッパーを使用すると、J UmbKSA4bQ になり、正しく 😊 にデコードされます。

URL セーフ入力の処理

デコード関数は、文字列を atob に渡す前に常に 2 つの変換を実行します：

1. - を + に、_ を / に置き換える（URL セーフエンコードを元に戻す）
2. 文字列長が 4 の倍数でない場合、= パディングを追加する

つまり、デコード側で設定を変更する必要はありません。標準 Base64、URL セーフ Base64、パディングあり・なしを問わず、デコーダーが自動的に処理します。

イベントフロー

テキストエリアに入力または貼り付けを行うと、input イベントリスナーが起動します。スケジューラーは急なキー入力をバッファリングし（約 16 ミリ秒のデバウンスで 1 フレームに合わせる）、エンコードまたはデコード関数を実行します。結果は次の画面更新時に出力テキストエリアに表示されます。

標準 Base64 vs URL セーフ Base64

エンコードセクションの 2 つのチェックボックスは、Base64 の 2 つの明確に定義されたバリアントに対応しています。

標準 Base64（RFC 4648 §4）

完全なアルファベットを使用：A–Z、a–z、0–9、+、/。これが元の形式で、+ と / が特別な意味を持つ場所を除いてどこでも機能します。

URL セーフ Base64（RFC 4648 §5）

URL で問題を引き起こす 2 つの文字を置き換えます：

標準 Base64 Pz4/Pj8+QA== は URL セーフ形式で Pz4_Pj8- QA_ になります（注：例ではパディング = も省略されていますが、URL セーフでもパディングを使用できます）。

それぞれの使用タイミング

このツールのデコード側は使用されたバリアントを自動的に検出するため、設定を変更せずに任意の形式を貼り付けることができます。

よくある誤解

一部の開発者は URL セーフ Base64 が別のアルゴリズムだと考えています。そうではありません — アルファベットの 2 文字が変わるだけです。任意の標準 Base64 デコーダーは、処理前に - → + および _ → / をマッピングすることで適応できます。これはこのツールがデコード側で行っていることです。

Base64 のパディング

Base64 文字列の最後にある = 文字はパディングです — エンコードされたデータの一部ではありません。

パディングが存在する理由

Base64 は入力を 3 バイトのグループで処理します。最後のグループが 3 バイト未満の場合、エンコーダーは = をパディングとして追加し、全長を 4 の倍数にします。これは一部のデコーダーで必要とされ、複数の Base64 文字列を曖昧さなく連結できるようにします。

「パディングなし」の意味

「パディングなし」を有効にすると、エンコーダーは出力から末尾の = 文字を削除します。例：

• 入力：Fo → Rm8=（パディングあり）→ Rm8（パディングなし）
• 入力：Foo → Rm9v（どちらの場合もパディングなし — 正確な 3 の倍数）

多くの最新システムはパディングなしの Base64 を受け付け、このツールのデコーダーは常にそれを処理します。出力の送信先システムがパディングを必要としない、または望まない場合にこのオプションを有効にします。

相互運用性マトリックス

このツールのデコードセクションは、4 つの組み合わせすべてを自動的に受け付けます：

調整する設定はありません。デコーダーは処理前に入力を正規化します。

パディングが必要な場合

一部のシステムは厳密にパディングを必要とします。特に：

• Data URI: data:image/png;base64,... — ブラウザのパーサーは正しくパディングされた Base64 を期待します。
• 古い Base64 ライブラリ: 一部の実装はパディングなしの入力を完全に拒否します。

ターゲットシステムがパディングを必要とするかどうか不明な場合は、有効にしたままにします（デフォルト）。パディングの削除は、エンコーダーとデコーダーの両方を制御している場合にのみ安全です。

Base64 と他のエンコード方式の比較

Base64 はいくつかのバイナリ→テキストエンコード方式の 1 つであり、それぞれ密度、アルファベットサイズ、使用例において異なるトレードオフがあります。

Base64 が最も人気がある理由

Base64 はほとんどの実用的なアプリケーションにとってスイートスポットです。入力サイズが 2 倍になる Hex と比較して、Base64 の 33 % オーバーヘッドは大幅に効率的です。Base85 と比較して、Base64 は実装が簡単で（すべての言語に組み込みデコーダーがある）、そのアルファベットは Base85 の文字（" や \ など）が一部のコンテキストで引き起こす引用の問題を回避します。

他の方式を使用するタイミング

• Hex: サイズよりも人間の可読性とデバッグが重要な場合。4f6f のような Hex 文字列はエンコードされたデータとして即座に認識できます。b293 は Base64 としてはあまり明白ではありません。
• Base32: 大文字小文字の区別が不要な場合（例：電話で読み上げる、製品に印刷する）。Base32 は大文字と数字のみを使用します。
• Base85: 制限されたチャネルでオーバーヘッドの 1 バイトが重要で、パイプラインの両端を制御している場合。

一般的な Web エンコードには、Base64 が正しいデフォルトの選択肢です。このツールはその慣習に従います。

パフォーマンスとサイズに関する考慮事項

Base64 はシンプルで普遍的ですが、大規模なデータを扱う際には実際のコストが重要になります。

33 % のオーバーヘッド

入力 3 バイトごとに出力 4 バイトになり、比率は 4:3 です。実際には、パディングと改行を含めると、オーバーヘッドは小さな入力で約 37 %、十分に大きな入力で 33 % に安定します。

Base64 と圧縮

Base64 テキストの Gzip（または Brotli）圧縮は一般的に効果がありません。Base64 出力は均一な文字分布を持ち — 64 文字のそれぞれがほぼ同じ頻度で出現する — そのため、圧縮アルゴリズムが利用するパターンが排除されます。圧縮された Base64 文字列は、元のバイナリデータで達成可能な 60–80 % の削減と比較して、多くの場合非圧縮形式よりわずか 5–10 % 小さいだけです。

つまり：

• 圧縮する前に Base64 エンコードしないでください。最初に圧縮し、必要に応じてエンコードします。
• Base64 のオーバーヘッドを補うためにトランスポートレベルの圧縮（HTTP gzip など）に頼らないでください。それは機能しません。

Base64 を使用すべきでない場合

テキストのみのチャネルにバイナリデータを収める必要がある場合、Base64 は有効です。チャネルがネイティブにバイナリ転送をサポートしている場合は、Base64 を省略します：

• ファイルアップロード: JSON 内の Base64 ではなく、multipart/form-data で生のバイナリを使用します。ファイルは 33 % 大きくサーバーに到達し、アップロードに時間がかかります。
• データベースストレージ: Base64 テキストではなく、バイナリデータを BYTEA（PostgreSQL）、BLOB（MySQL/SQLite）、varbinary（MSSQL）として保存します。
• サービス間 API 呼び出し: Base64 エンコードされた JSON 文字列ではなく、バイナリフィールドを持つ gRPC、Thrift、MessagePack を使用します。

テキストペイロード（JWT ペイロード、HTML コンテンツ、メール本文）の場合、オーバーヘッドは無視でき、Base64 の利便性はトレードオフの価値があります。

キャッシュへの影響

Base64 Data URI を HTML や CSS に埋め込むと、エンコードされたコンテンツはページリソースの一部になります。ブラウザはその Data URI を独立してキャッシュできません — ページへの変更はそれを無効にします。<img src="icon.png"> 経由でリクエストされる別の画像ファイルは、将来の Cache-Control ヘッダーでページ間でキャッシュできます。数キロバイトを超えるアセットの場合、個別のファイルがほとんどの場合より優れたパフォーマンスを発揮します。

よくある落とし穴と誤解

Base64 はシンプルですが、いくつかの繰り返し発生する誤解が実際のエラーを引き起こします。

Base64 は暗号化ではない

これが最も一般的な誤解です。Base64 の出力がランダムな文字のように見えるため、多くの開発者はある程度の保護を提供すると想定しています。そうではありません。デコードには鍵や秘密は必要ありません。Base64 文字列は公開可能な読み取り可能テキストとして扱ってください。

サービスがパスワードや API キーを Base64 として保存しているのを見た場合、それはセキュリティ問題として扱ってください — データは平文で保存されています。

大文字小文字の区別

Base64 アルファベットは大文字と小文字を区別します：

• 大文字：A–Z（値 0–25）
• 小文字：a–z（値 26–51）

R と r のようなタイプミスは、デコードされた値を完全に変更します。デコード出力が正しくないように見える場合は、入力の大文字小文字エラーを確認してください。

MIME 改行

MIME エンコードされたメール添付ファイルは、Base64 本文を 76 文字ごとに改行します：

SGVsbG8sIHdvcmxkISBUaGlzIGlzIGEgdGVzdCBvZi BiYXNlNjQgZW5jb2Rpbmcu
VGhpcyBpcyB0aGUgc2Vjb25kIGxpbmUu

すべての Base64 デコーダーがこれらの埋め込まれた改行を処理するわけではありません。このツールは処理します — 前処理なしで複数行の MIME Base64 を直接貼り付けてください。改行を処理しないデコーダーは、歪んだ結果またはエラーを生成します。

隠れた空白

メール、PDF、Web ページからテキストをコピーすると、目に見えない空白文字（スペース、タブ、ゼロ幅スペース、改行なしスペース）が混入する可能性があります。これらは有効な Base64 ではありません。有効に見える Base64 文字列がデコードできない場合は、最初にプレーンテキストエディタに貼り付けて隠れた文字を確認するか、ソースから再コピーしてください。

パディング付き文字列の連結

2 つのパディング付き Base64 文字列を直接連結しても、必ずしも正しくデコードされるとは限りません。パディング = は各文字列の最後のグループに属し、連結によって曖昧な境界が生じる可能性があります。これは意図的です — パディングは個々の文字列の曖昧さを防ぎます。複数部分のデータの場合は、各部分を個別に処理してください。

使い方

Base64 エンコーダー & デコーダーの使用には、セットアップ、登録、アカウントは必要ありません。

テキストを Base64 にエンコード

1. Base64 エンコードセクションで、入力テキストエリアにテキストを入力または貼り付けます。
2. 出力エリアはエンコードされた結果で自動的に更新されます。
3. 必要に応じて、URL セーフ（Web セーフバリアント）またはパディングなし（末尾の = を削除）を有効にします。
4. コピーをクリックしてエンコードされたテキストをクリップボードにコピーするか、Base64 をダウンロードをクリックして .b64 ファイルとして保存します。

Base64 をテキストにデコード

1. Base64 デコードセクションで、Base64 文字列を入力エリアに貼り付けます。
2. デコードされたテキストが出力エリアに即座に表示されます。
3. 入力が有効な Base64 でない場合は、エラーメッセージが表示されます。
4. コピーまたはダウンロードをクリックして、デコードされた結果を保存します。

ファイルアップロードの使用

• エンコードセクション: .txt ファイルをアップロードゾーンにドロップして、エンコードするコンテンツを読み込みます。
• デコードセクション: .b64 または .txt ファイルをドロップして、デコードする Base64 コンテンツを読み込みます。

ファイルの内容が読み取られ、入力テキストエリアに配置され、即座に処理されます。

チュートリアル

シナリオ: API と通信する Web アプリケーションを構築しています。API は、リクエストペイロードにパディングなしの URL セーフ Base64 としてエンコードされた短いテキストフィールドを含めることを期待しています。テキストをエンコードし、出力を確認し、API が受け入れることを確認する必要があります。後で、同じ API からデコードする必要がある Base64 エンコードされたフィールドを含む応答を受け取ります。

このチュートリアルでは、完全なラウンドトリップを説明します。

パート 1: エンコード

1. ブラウザで Base64 エンコーダー & デコーダーを開きます。左側にエンコード、右側にデコードの 2 つのセクションが表示されます。

2. エンコード入力エリアに次のテキストを入力します：

   こんにちは、API サーバー。これがペイロードです。
   

   出力エリアに標準 Base64 エンコードが即座に表示されます。結果は 44GT44KT44Gz44Gf44Gv で始まります。ここまでは順調です。

3. API 仕様では、パディングなしの URL セーフ Base64 が必要です。URL セーフとパディングなしの両方のチェックボックスを有効にします。出力がどのように変化するかを観察します：

   • + 文字（ある場合）は - になります
   • / 文字は _ になります
   • 末尾の = 文字が削除されます

4. コピーをクリックして、エンコードされた結果をクリップボードにコピーします。API リクエストペイロードに貼り付けます。

パート 2: デコード

5. API が Base64 エンコードされたフィールドを含む JSON ペイロードで応答します：

   {
     "status": "ok",
     "message": "eyJzdWIiOiAiMTAwMSIsICJuYW1lIjogIkFQSSBHYXRld2F5In0="
   }
   

6. message の値をコピーして、デコード入力エリアに貼り付けます。

   出力エリアにデコードされたテキストが即座に表示されます：

   { "sub": "1001", "name": "API Gateway" }
   

7. JWT のような JSON ペイロードが読めるようになりました。API が URL セーフ Base64 を使用していた場合（文字列に + や / がない、または - や _ がある場合）、デコーダーが自動的に処理したはずです。

パート 3: ファイルベースのワークフロー

8. エンコードされたペイロードをファイルを好む同僚に送信する必要があるとします。エンコードセクションでBase64 をダウンロードをクリックします。ブラウザの「名前を付けて保存」ダイアログが開き、download.b64 がファイル名として提案されます。ファイルを保存します。

9. 同僚がファイルを受け取り、同じツールを開きます。download.b64 をデコードセクションのアップロードゾーンにドラッグします。ファイルの内容が入力エリアに表示され、デコードされたテキストが即座に表示されます。

このラウンドトリップ — オプション付きでエンコード → コピーまたはダウンロード → 自動検出でデコード — は、最も一般的な実際のワークフローをカバーしています。ツールがすべての正規化を処理するため、文字のバリアントやパディングルールについて考える必要はありません。

プロのヒント

• 同時にエンコードとデコード: 2 つのセクションは独立しています。エンコードセクションでテキストを入力しながら、デコードセクションに別の Base64 文字列を貼り付けることができます。これを使用して、両方向の入力と出力を並べて比較します。

• JWT には URL セーフ: JWT トークンを扱う場合は、常に URL セーフモードを有効にします。JWT セグメントは URL セーフバリアント（RFC 7515）を使用します。JWT セグメントをデコードセクションに貼り付けると、ツールが URL セーフ文字を自動的に検出します。

• 貼り付ける前に空白をトリミング: Base64 データの一部のソースには、末尾の改行やスペースが含まれています。デコーダーはトリミングされた入力を最も適切に処理します。「無効な Base64 文字列」エラーが表示された場合は、貼り付けられたテキストに余分な空白がないか確認してください。

• 大きな出力はダウンロード: 長い Base64 文字列の場合は、コピーではなくダウンロードボタンを使用します。ネイティブの「名前を付けて保存」ダイアログで保存場所を選択でき、結果は転送やアーカイブが可能な .b64 または .txt ファイルとして保存されます。

• 入力の代わりにアップロード: テキストや Base64 データを含むファイルがすでにある場合は、アップロードゾーンにドラッグします。これはファイルを開き、すべて選択し、コピーし、貼り付けるよりも高速です — 特に大きなファイルの場合。

• デコードして形式を確認: Base64 文字列を受け取り、テキストとバイナリデータのどちらが含まれているかわからない場合は、デコードセクションに貼り付けます。出力が読めるテキストであれば完了です。文字化けや置換グリフ（ ）が含まれている場合、元のソースはバイナリ（画像、PDF、その他の非テキスト形式）であった可能性があります。

代替ツール

Base64 をエンコードまたはデコードするには、他にもいくつかの方法があり、それぞれに異なるトレードオフがあります。

プライバシー、リアルタイムフィードバック、コマンドライン知識不要で Base64 テキストをエンコードまたはデコードするには、このツールが最適なユーザーエクスペリエンスを提供します。

データプライバシー

Base64 エンコーダー & デコーダーは、すべての文字をブラウザ内で完全に処理します。入力したテキストがサーバーに送信されたり、データベースに保存されたり、システムに記録されたりすることはありません。

すべての変換は、ブラウザのメモリ内で JavaScript のネイティブ btoa() および atob() 関数を使用して実行されます。このページには、アナリティクススクリプト、トラッキングピクセル、サードパーティの埋め込みは含まれていません。Cookie、localStorage、sessionStorage のエントリは作成も読み取りもされません。

ページの初期読み込み後、ツールは完全にオフラインで機能します。インターネットから切断しても、中断することなくエンコードとデコードを続けることができます。機内モードでツールを使用するか、ブラウザの開発者ツールでネットワークアクティビティを検査して確認できます — ページ読み込み後、デバイスからリクエストが送信されることはありません。

トラブルシューティング

技術仕様

• コアアルゴリズム: btoa() / atob() を encodeURIComponent / decodeURIComponent でラップして UTF-8 セーフを実現
• 標準: RFC 4648 §4（標準 Base64）、RFC 4648 §5（URL セーフ Base64）
• 入力処理: デコード時の自動 URL セーフ文字変換（- → +、_ → /）およびパディング正規化
• リアルタイム処理: テキストエリアの input イベントリスナー、約 1 フレーム（16 ミリ秒）にデバウンス
• ファイル I/O: アップロードは FileReader API、ダウンロードは showSaveFilePicker（File System Access API）と <a download> フォールバック
• ダウンロード形式: .b64（エンコード済み）、.txt（デコード済み）
• アップロード形式: .txt（エンコードセクション）、.b64 / .txt（デコードセクション）

パフォーマンスベンチマーク

2020 年製ミッドレンジノートパソコン（Chrome 120）で測定。パフォーマンスは入力サイズに比例して線形にスケーリングします。100 KB 未満の一般的なテキストペイロードの場合、変換は事実上瞬時に行われます。

ブラウザ互換性

showSaveFilePicker は Chromium ベースのブラウザ（Chrome、Edge、Opera、Samsung Internet）が必要です。Firefox と Safari では、ダウンロードは自動的に <a download> メソッドにフォールバックします。

プライバシーとセキュリティ

• ゼロデータ送信：すべてのテキスト処理はブラウザのメモリ内で行われます
• Cookie、localStorage、sessionStorage は使用されません
• ツールページに分析スクリプトやトラッキングスクリプトはありません
• ページの初期読み込み後は完全にオフラインで機能
• 登録、ログイン、API キーは不要

機能

• テキストを Base64 にエンコード、Base64 をテキストにデコード（リアルタイム変換）
• URL セーフモード（+/ の代わりに -_ を使用、RFC 4648 §5）
• パディングなしオプション（末尾の = を削除、RFC 4648 §3.2）
• Base64 エンコード方式と .b64 ファイル形式の組み込み解説
• .txt および .b64 ファイルのドラッグ＆ドロップアップロード対応
• ネイティブの「名前を付けて保存」ダイアログで .b64/.txt として結果をダウンロード
• 完全クライアントサイド — サーバー送信なし、オフラインでも動作

よくある質問