Base64 エンコード / デコード

ブラウザ内でテキストを Base64 に変換し、再びデコードします。UTF-8 に安全に対応し、任意の URL-safe バリアントも利用できます。データがサーバーにアップロードされることはありません。

入力

0 行 · 0 文字

モード

URL-safe

Base64 エンコード / デコードの使い方

1
エンコードかデコードを選ぶ
テキストを Base64 に変換するにはモードを「Encode」に、Base64 文字列を読めるテキストに戻すには「Decode」に設定します。
2
入力を行う
テキストまたは Base64 を入力パネルに入力するか貼り付けます。必要に応じて「URL-safe」をオンにすると、URL やファイル名に適した文字セットを使います。
3
変換する
「Convert」をクリックすると、UTF-8 と絵文字に完全対応した変換がブラウザ内でローカルに実行されます。

4
コピーまたは入れ替える
結果をコピーするか、「Swap」を使って出力を入力に戻しモードを切り替えると、素早く往復変換できます。

Base64エンコーディング完全ガイド

Base64とは実際に何なのか

Base64はバイナリからテキストへのエンコーディング方式です。任意のバイナリデータを、プレーンテキスト向けに作られたシステムを通っても壊れない64個の印字可能なASCII文字だけを使って表現します。RFC 4648で定義された標準のアルファベットは、26個の大文字A-Z、26個の小文字a-z、10個の数字0-9、そして2個の記号 + と / です。これで合計64個の記号となり、2の6乗が64であることから、1文字あたりちょうど6ビットのデータを表現するのに過不足ありません。

この名前は文字通りの意味です。10進数（base 10）が10個の数字記号を使い、16進数（base 16、hex）が16個を使うのと同じように、64進数（base 64）は64個を使います。このエンコーディングは完全に可逆かつ無損失で、エンコードしたバイトはデコードすると1バイトも違わず元どおりに戻ってきます。これこそがすべての目的です。

Base64が存在する理由

多くの通信経路は、生のバイトではなくテキストを運ぶように設計されており、印字可能なASCIIの範囲外にあるものは何でも壊してしまいます。電子メールが典型例です。当初のSMTP規格は7ビットのプロトコルで、バイナリデータの最上位ビットを破損させたり削り落としたりすることがあったため、MIMEは画像やファイルの添付を安全に送るためにBase64を使います。同じ問題は、バイナリをテキスト的な何かの中に乗せて運ぶ必要があるたびに現れます。

あなたは気づかないうちに絶えずBase64に出会っています。データURIは data:image/png;base64,iVBORw0K... のように画像をHTMLやCSSに直接埋め込むので、小さなアイコンに別途リクエストが要りません。JSON Web Token（JWT）はドットで結ばれた3つのBase64url区間です。HTTP Basic認証は username:password のBase64を送ります。ブラウザは組み込みの btoa と atob 関数を通じてこれを提供しており、バイナリのペイロードをJSONやXML、あるいはURLに詰め込む標準的な方法でもあります。

3バイトから4文字への対応の仕組み

Base64は入力を3バイトずつ処理します。3バイトは24ビットで、24は6ビットの4つのグループにきれいに割り切れます。各6ビットのグループは0から63までの数で、これがアルファベットの1文字になります。したがって入力3バイトごとに必ずちょうど4文字の出力が生まれ、これがBase64がデータをおよそ3分の1ふくらませる理由です。エンコード後の形は元のサイズの約133%になります。

重要なのはアルファベット内での位置です。インデックス0はA、25はZ、26はa、51はz、52は0、61は9、62は +、63は / です。エンコードされた文字列を手作業で読むには、各文字を対応するインデックスに戻し、そのインデックスを6ビットで書き、すべてのビットを連結し、そのビット列を8ビットのバイトに切り直します。

実例: "Man" のエンコード

3つの文字 M、a、n を取り上げましょう。これらのASCIIバイト値は77、97、110で、2進数では 01001101、01100001、01101110 です。これら24ビットを1つの列に連結します: 010011010110000101101110。これを4つの6ビットグループに切ります: 010011、010110、000101、101110。

これらのグループは数 19、22、5、46 です。それぞれをアルファベットで引くと T（インデックス19）、W（インデックス22）、F（インデックス5）、u（インデックス46）になります。したがって "Man" は "TWFu" にエンコードされます。これはパディングを必要としない、きれいな3バイトから4文字への変換です。デコードは単にこの手順を逆に実行するだけです。

パディングと等号

入力は常に3バイトの倍数とは限らないため、Base64には余りを知らせる方法が必要です。1バイトが余るときは、2文字に続けて2つのパディング記号（==）でエンコードされ、2バイトが余るときは、3文字に続けて1つのパディング記号（=）でエンコードされます。パディング文字はデータを運びません。最後のグループが何個の本物のバイトを表すかをデコーダーに伝えるだけです。

たとえば、1文字の "M"（バイト77、2進数 01001101）は6ビットに整えると 010011 と 010000 になって T と Q を与え、その後 == で完成して "TQ==" になります。単語 "Ma"（2バイト）は末尾に1つの等号がついた "TWE=" にエンコードされます。Base64文字列の末尾の等号を数えれば、元の長さが3の倍数だったかどうかがわかります。

URLセーフな変種

標準の + と / の文字は、すでに別の意味を持っている場所では問題を起こします。URLではスラッシュがパスの区切りを分け、フォームエンコードされたクエリ文字列ではプラス記号がスペースと解釈されるため、通常のBase64の値はリンクやファイル名に入れると壊れることがあります。これも RFC 4648 由来のURLセーフなアルファベットは、+ を - （ハイフン）に、/ を _ （アンダースコア）に置き換えてこれを解決します。

このツールでURLセーフのオプションをオンにすると、その変種が生成され、末尾の = パディングも除去されます。等号もまたURL内ではエスケープが必要だからです。その結果はクエリパラメーター、パスの区間、Cookie、ファイル名にそのまま収まります。これはJWTや多くのWeb APIで使われているエンコーディングです。ただし、URLセーフな入力はURLセーフなデコーダーでデコードすることを忘れないでください。- と _ の文字は標準のアルファベットでは有効ではないからです。

Base64はエンコーディングであって暗号化ではない

これはBase64に関する、最も重要でありながら最も誤解されている事実です。エンコーディングはデータを肉眼に対して見えにくくするだけで、秘匿性はまったく提供しません。鍵もなく秘密もないので、誰でもこのツールを含むあらゆるツールを使ってBase64文字列を瞬時にデコードできます。Base64をパスワードやAPIキー、個人データを隠す手段として扱うのは、深刻なセキュリティ上の誤りです。

Base64が解決するのは輸送の問題であって、秘匿の問題ではありません。バイナリをテキストのみの通信経路を通って安全に移動できるようにするのです。本当の保護が必要なら、まずAESのような本物のアルゴリズムでデータを暗号化し、その上でその暗号文をテキストとして運ぶ必要がある場合にだけBase64エンコードしてください。エンコーディングと暗号化は別の仕事です。

よくある間違いと実用的なヒント

最も多い誤りは文字セットの取り違えです。Base64自体はバイトしか知らないので、テキストをエンコードする前に、そのテキストをどうやってバイトにするかを決めなければなりません。このツールはUTF-8を使っており、これがアクセント付きの文字や絵文字が正しく往復する理由です。同じ文字列を別の場所で別の文字セットとしてエンコードすると、異なるBase64になります。2つ目によくある落とし穴は空白です。一部のエンコーダーが挿入する改行（MIMEは76文字で折り返します）はデータの一部ではなく、デコードの前に取り除かなければなりません。厳格なデコーダーはそれらを拒否することもあります。

ほかの落とし穴としては、標準のアルファベットとURLセーフなアルファベットを混ぜること、パディングのない文字列は厳格なデコーダーが受け付ける前にパディングを復元する必要があるかもしれないことを忘れること、そしてBase64が容量を節約すると思い込むことがあります。Base64は決して容量を節約せず、常にペイロードを約3分の1ふくらませます。ここでデコードに失敗したときは、まず迷い込んだスペース、欠けた等号、あるいはURLセーフなアルファベットに属する - や _ がないかを確認してください。

よくある質問

ここでのエンコードとデコードの違いは何ですか?

エンコードは通常のテキストを Base64 表現に変換し、デコードは Base64 文字列を元のテキストに復元します。モードの切り替えで両者を行き来できます。

URL-safe オプションは何をしますか?

URL-safe な Base64 では、+ と / の文字が - と _ に置き換えられ、末尾の = パディングが除去されます。そのため、エスケープなしで URL やクエリ文字列、ファイル名にそのまま使えます。

絵文字や英語以外の文字に対応していますか?

はい。変換前にテキストは UTF-8 としてエンコードされるため、アクセント付き文字、非ラテン文字、絵文字もエンコード・デコードで正確に保持されます。

デコード時に不正な Base64 を貼り付けるとどうなりますか?

不正な Base64 を検出すると、文字化けした出力ではなく入力エラーのメッセージを表示します。誤字を確認するか、エンコードモードに切り替えるよう促されます。

データはどこかに送信されますか?

いいえ。コンバーターは JavaScript を使ってブラウザ内で完結するため、テキストや Base64 文字列がデバイスから外に出ることはありません。機密データや独自データにも安全に使えます。