> base64 encoder | text | file <

上の 入力 エリアにテキストを入力または貼り付けるだけです。自動エンコードはデフォルトで有効 — 入力中に 出力 ボックスへ Base64 の結果が表示されます。[ENCODE] をクリックするか Ctrl/Cmd + Enter でエンコードを手動実行できます。Base64 を使う用途（JWT、OAuth、URL → 両方オン）に合わせて --url-safe や --no-padding を切り替えてください。すべてブラウザ内で完結: アップロードなし、ログなし、入力に紐づくネットワーク通信は一切ありません。

入力エリア下の [upload file] ボタンをクリックし、最大 100 MB までのファイルを選択します。エンコーダーは FileReader.readAsArrayBuffer で読み取り、btoa を介して 32 KB のチャンクごとにストリーム処理（大きなファイルでブラウザがクラッシュしないように）し、完全な Base64 を出力ボックスに書き込みます。より大きなファイルはコマンドラインのエンコーダーをご利用ください: base64 < input.bin > output.txt（macOS/Linux）、または PowerShell の [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin'))。

Base64 を Data URI（例: data:image/png;base64,...）として整形したい場合は、出力の先頭に MIME タイプと ;base64, を付加するか、専用の 画像 → Base64 ツールをご利用ください。PNG、JPG、GIF、WebP、SVG 向けにそのまま貼り付け可能な Data URI を出力します。

3 種類はすべて RFC 4648 で定義されています:

• 標準 Base64 (§4) は A-Z a-z 0-9 + / のアルファベットと = パディングを使用。出力長は常に 4 の倍数。MIME、HTTP Basic 認証、JSON 文字列値に適しています。

• URL セーフ Base64 (§5) は + を - に、/ を _ に置換。URL のパス・クエリパラメータ・ファイル名・JWT セグメントに Base64 を埋め込むときに必須 — 標準の +/ はパーセントエンコードが必要になります。

• パディングなし（§4・§5 の両方、base64url unpadded） は末尾の = を除去。長さはもはや 4 の倍数ではありませんが、デコーダーは余りを 4 で割って元の長さを計算できます。JWT（RFC 7515 の base64url）、WebAuthn、一部の CBOR/COSE 実装で利用されます。

どのバリアントを想定するかはデコーダーに伝える必要があります — 弊ツールの Base64 デコーダー は 3 種すべてを自動判定します。

主要な言語とランタイムはすべて Base64 エンコードを標準搭載しています。コピー&ペーストで使えるスニペット:

JavaScript (ブラウザ):
btoa('Hello') // SGVsbG8=
// UTF-8 の場合:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 対応

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL セーフ、パディングなし

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL セーフ、パディングなし

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...)（パディングなし）
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

シェル (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=。Linux では base64 -w 0 で 76 列での折り返しを抑止できます。

Base64 出力は入力より約 33% 大きくなります: 入力 3 バイトごとに出力 4 文字になります。正確な式: パディングを含めると ceil(n / 3) × 4、含めない場合は ceil(n × 4 / 3)。さらに 76 列（MIME）や 64 列（PEM）で改行する場合はオーバーヘッドが数バイト増えます。

例:
• 1 KB のバイナリ → 約 1.37 KB の Base64
• 100 KB の画像 → 約 137 KB の Data URI
• 1 MB の PDF → JSON 中で約 1.37 MB の Base64

Base64 を避けるべきケース:
• 大きなファイル転送: 10 MB の画像を HTML に Base64 で埋め込むと、パース後は 13.7 MB のテキストとなり、メインスレッドをブロックし、個別キャッシュもできません。<img src="/assets/photo.png"> を推奨。
• パフォーマンス重視の API: JSON 中の 500 KB の Base64 ペイロードは、同等のバイナリエンドポイントより約 2〜3 倍遅くパースされます。
• セキュリティ対策として: Base64 は暗号化ではありません — 誰でもデコードできます。機密性が必要なら AES-GCM などを使用してください。
• データベースの BLOB: 生バイトを BLOB/BYTEA として保存すれば、Base64 テキストより 33% のストレージを節約でき、エンコード/デコードの往復も不要です。

JWT (RFC 7515) と OAuth PKCE (RFC 7636) はどちらも パディングなしの URL セーフ Base64（通称 base64url）を使用します。本ツールで生成するには: --url-safe と --no-padding の両チェックボックスをオンにしてからテキストをエンコードします。

プログラミング言語での等価:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

base64url が必要な JWT の代表的なフィールド: ドットで区切られた 3 セグメント（ヘッダー、ペイロード、署名）、OAuth PKCE の code_verifier/code_challenge、WebAuthn のチャレンジ、Web Push の p256dh/auth キー、Google の Request.state パラメータなど。

よくあるバグは、標準 Base64（+/）の JWT を送信してしまうこと — + が転送時に URL デコードされてスペースになるため、API 側で不正として拒否されます。

はい、ただし 1 点注意があります。このエンコーダーが生成するのは Data URI の Base64 部分 — ;base64, 以降の部分です。完全な Data URI を作成するには、先頭に次を付加します:

data:<mime-type>;base64,<encoded-output>

主な MIME タイプ:
• data:image/png;base64,... — PNG 画像
• data:image/jpeg;base64,... — JPEG 画像
• data:image/svg+xml;base64,... — SVG（または Base64 を使わず data:image/svg+xml;utf8, が通常は小さい）
• data:application/pdf;base64,... — PDF ファイル
• data:application/font-woff2;base64,... — フォント埋め込み
• data:text/plain;charset=utf-8;base64,... — Base64 でラップされたテキスト

画像や SVG の場合は、画像 → Base64 ツールが、CSS background-image、インライン <img src="...">、<object data="..."> タグにそのまま貼り付けられる完全な Data URI を出力します。

サイズに関する注意: 20〜30 KB を超える Data URI は、ブラウザがプリロードできないため LCP（Largest Contentful Paint）を損ないます — インラインの Base64 画像は小さく保ち、大きめのアセットは loading="lazy" を付けた通常の <img> を優先してください。

はい — 何もブラウザから外に出ません。 エンコーダーはネイティブの btoa()、TextEncoder、FileReader API を使用し、すべて JavaScript で完結します。入力内容に関するネットワーク通信・テレメトリ・ログ・サードパーティ分析は一切ありません。DevTools のネットワークタブを開きながらエンコードを実行しても、関連リクエストがゼロであることを確認できます。

ただし、Base64 は暗号化ではありません — 可逆的なエンコードであり、出力を持っている人なら誰でもデコードできます。そのため:
• 本番のシークレットをエンコード形式でもチャット・スクリーンショット・ログに貼り付けない。
• HTTP Basic 認証の Authorization: Basic ヘッダーは TLS（HTTPS）上でのみ安全です。平文 HTTP 上では簡単に傍受されます。
• 本当に機密性を確保したいなら、AES-GCM、age、sops、あるいは KMS を使用してください — 必要なら転送用に暗号文を Base64 エンコードします。

厳格なデータ持ち出し制限のある環境では、ページをオフライン保存（Cmd/Ctrl + S）してください。サーバー依存はないため、1 度ロードすれば完全エアギャップで動作します。

エンコーダーはファイルハンドラーのハード上限により 最大 100 MB のファイルに対応 — ほとんどの画像、PDF、ZIP アーカイブ、短い動画に十分な大きさです。パフォーマンス目安:

• < 1 MB: エンコードは 50 ms 未満で完了、UI フリーズなし。
• 1 – 10 MB: CPU 次第で 100〜500 ms。32 KB のチャンクでエンコードするためブラウザは応答可能。
• 10 – 100 MB: 2〜15 秒。巨大な Base64 文字列を貼り付け/スクロールする際、出力テキストエリアがわずかにもたつく可能性あり。必要に応じて DevTools から出力を .txt ファイルとしてダウンロードしてください。
• > 100 MB: ブロック — ブラウザのメモリオーバーヘッド（入力バイト + バイナリ文字列 + Base64 文字列 ≈ ファイルサイズの 3〜4 倍）でタブがクラッシュするリスクがあります。代わりに:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

ストリーミングやマルチ GB のワークフローについては、メモリに全部を読み込まずに済む Node.js/Python のチャンク方式を解説した 大きなファイルの Base64 エンコード をご覧ください。

本エンコーダーは UTF-8 を使用します。現代的な Web、JSON、Linux、macOS、ほとんどのプログラミング言語のデフォルトと同じエンコーディングです。内部では、テキストを new TextEncoder().encode(input) に通して常に UTF-8 バイトを生成し、それから Base64 にエンコードしています。

なぜこれが重要か: 古い JavaScript の btoa() 関数は Latin-1 しか扱えず、é、中、😀 のような文字で InvalidCharacterError を投げます。弊ツールのラッパーが UTF-8 変換を肩代わりするため、絵文字、中国語、日本語、韓国語、アラビア語、キリル文字、あらゆる Unicode コードポイントが正しくエンコードされます。

別のエンコーディングが必要な場合:
• UTF-16 LE（Windows ネイティブ）: まれ — 多くはレガシー互換の兆候です。とりあえず new TextEncoder({ fatal: true }).encode(s) を使い、上流で変換してください。
• ISO-8859-1 / Latin-1: コードポイント 0〜255 をバイトに手動マップしてからエンコード。
• GB18030、Shift_JIS、EUC-KR: Node.js では iconv-lite のようなライブラリで先にトランスコードしてください。

注意が必要な落とし穴: 元データがすでに非 UTF-8 エンコーディング（例: レガシー MySQL ダンプを読み込んだ場合）であれば、まず正しいコーデックでデコードし、UTF-8 に再エンコードしてから Base64 にしてください — そうしないと Base64 をデコードしたときに文字化けがそのまま残ります。