Base64は復号できますか？
Base64には「暗号化」がないので、「復号」という言い方も当てはまりません。正確にはデコードと言い、必ず元に戻せます——上をデコードモードに切り替えて貼り付け、クリックすれば元データです。 MD5やSHA-256のような一方向ハッシュとはまったく別物です。後者は不可逆ですが、Base64は完全に可逆な双方向のエンコードです。Base64で機微なデータを「暗号化」している例を見かけたら、それは暗号方式ではなくセキュリティ上の問題です。
data:image/png;base64,... のようなdata URIをそのまま貼り付ければ、接頭辞を自動で認識して取り除きます。デコード結果が画像ならその場でプレビューし、バイナリならダウンロードボタンを表示します。すべてブラウザ内で完結し、データは一切送信しません。data: URIをまるごと貼り付けられます。接頭辞は自動で取り除かれ、改行やスペースも無視されます。-_）や欠けた = のパディングにも自動対応するので、手直しは不要です。違います。そしてこれが一番大事な点です。Base64はエンコードです：任意のバイナリデータを64種類の印字可能文字（A-Z a-z 0-9 + /）で表現し直すだけのものです。鍵も秘密もなく、規則は公開されていて、手に入れた人は誰でも一手で元に戻せます。解決しているのは「この経路はテキストしか通せないが画像を送りたい」という問題であって、「他人に読ませたくない」という問題ではありません。ですからパスワードやマイナンバー、APIキーをBase64にしてからデータベースに保存したりフロントエンドのコードに書いたりしても、保護には一切なりません——本当に不可逆にしたいなら SHA-256オンライン暗号化を、パスワードの保存にはbcryptのようなスローハッシュを使ってください。
この種のリンクは data:text/html;charset=utf-8;base64,PGh0bWw+...のような形をしていて、メールサービスや一部の掲示板の「共有」機能でよく見かけます。開けないのはリンクが壊れているからではありません。Chromeは2017年からアドレスバーからトップレベルの data: リンクを直接開くことを禁止しており、FirefoxとEdgeもこれに追随しました。この仕組みがフィッシングに多用されたためです——偽のログインページを丸ごと1本のリンクに収められるうえ、アドレスバーには本当のドメインが表示されません。
中身はリンクの中にそのまま入っています。リンク全体を（先頭の data:text/html;charset=utf-8;base64, という接頭辞も含めて）上のデコード欄に貼り付けてください。本ページが接頭辞を自動で認識して取り除き、元の内容を復元します。結果がHTMLなら、ページのソースがそのまま表示されます。見る前に心構えを：知らない相手から送られてきたリンクなら、フィッシングページである可能性がかなりあります。中身を確認するのは構いませんが、そこにあるフォームにIDやパスワードを入力しないでください。
主に埋め込みです：小さなアイコンをCSSの background-image: url(data:image/png;base64,...) やHTMLの <img src>に直接書き込んでHTTPリクエストを1回減らす、あるいはJSON・Markdown・メール本文といったテキストしか置けない場所に画像を入れる、といった使い方です。代償としてサイズが約1/3増え（3バイトごとに4文字）、埋め込んだ画像はブラウザに個別キャッシュされません——1バイト変えるだけでCSSファイル全体のキャッシュが無効になります。ですから数KB程度の小さなアイコンにしか向きません。写真や大きな画像は素直にURL参照にしてください。上の「data URI の接頭辞を付ける」にチェックを入れれば、コードにそのまま貼れる文字列が得られます。
それは URLセーフ版（RFC 4648 §5）です。標準の文字集合にある + と / はURLやファイル名で特別な意味を持ち、クエリパラメータに入れるとエスケープされたり切れたりするため、 - と _に置き換えます。末尾の長さ合わせに使う = もURLでは邪魔になるので、省略されるのが普通です。JWTの3つのパートもこの方式です。本ページはデコード時にどちらの書き方も自動で判別して復元するので、手で置き換える必要はありません。エンコード時は「URLセーフな文字集合」にチェックを入れればこの形式で出力されます。
Base64には「暗号化」がないので、「復号」という言い方も当てはまりません。正確にはデコードと言い、必ず元に戻せます——上をデコードモードに切り替えて貼り付け、クリックすれば元データです。 MD5やSHA-256のような一方向ハッシュとはまったく別物です。後者は不可逆ですが、Base64は完全に可逆な双方向のエンコードです。Base64で機微なデータを「暗号化」している例を見かけたら、それは暗号方式ではなくセキュリティ上の問題です。
まず表示されるメッセージを見てください。本ページはデコード後にUTF-8として読もうとし、読めなければそれはそもそもテキストではないということです——画像やPDF、圧縮ファイルであれば、判定した形式を伝えたうえでダウンロードボタンを出します。素直にダウンロードするのが正しい操作で、無理に表示すれば当然文字化けします。テキストのはずなのに化ける場合は、元データがShift_JISやGBKなどUTF-8以外のエンコードである可能性が高く、本ページは一律UTF-8として解釈するため、文字集合を指定できるツールが必要です。
よくあるのは3つです。1つ目は、コピー時に末尾の数文字が抜けて長さが4の倍数にならずパディングもできない場合。2つ目は、Base64の文字集合にない文字が混じっている場合——チャットからコピーしたときに全角の引用符や三点リーダーが紛れ込む、といったケースです。3つ目は、その文字列が実はBase64ではなくURLエンコード（%3Chtml%3E のような形式）だった場合。改行やスペースはこのエラーの原因にはなりません。本ページが自動的に無視します。
Base64は3バイトを4文字で表すため、必ず元の 4/3、約33%増になり、さらに末尾のパディング文字が加わります。これは仕組み上決まっていることで、どのBase64ツールでも同じです。サイズが気になる場合は、先に圧縮してからエンコードするか、埋め込みをやめてURL参照に切り替えるのが正解です。
エンコードモードは 10 MB までです。これは技術的な限界ではなく、それ以上は意味がないからです：Base64の用途はテキストへの埋め込みで、10 MBのファイルはエンコードすると13 MBの文字列になり、どこに貼っても問題が起きます。デコードモードに固定の上限はありませんが、ブラウザは非常に長い文字列の処理が遅くなるため、数十MBの入力では一瞬固まることがあります。
違います。URLエンコード（パーセントエンコード）はURL内の特殊文字を %XXに置き換えるだけで、他の文字はそのまま残るため結果もある程度は読めます。一方Base64はすべて内容を64種類の文字で表現し直すため、結果はまったく読めませんが、任意のバイナリを安全に運べます。この2つはよく併用されます：Base64の結果をURLパラメータに入れる際、標準の文字集合を使っていると、その中の + と / をさらにURLエンコードする必要があります——URLセーフ版が存在するのはまさにこのためです。
できますが、文字集合に注意してください。Base64が扱うのはバイトであって文字ではないので、まず何らかのエンコードでバイト列に変換する必要があります。本ページは一律UTF-8を使っており、これが現在の標準的なやり方です。同じ文字列をShift_JISやGBKでエンコードしてからBase64にすると結果はUTF-8とまったく異なるので、双方が一致しないときはBase64の実装を疑う前に文字集合を確認してください。
いいえ。変換にはブラウザ内蔵の atob / btoa とFileReaderを使っており、ファイルはメモリに読み込まれ、変換結果がそのまま表示されるだけで、1バイトたりとも端末の外に出ません。ページを読み込んだあとネットワークを切断してもこのツールは通常どおり動きます——これが一番手軽な確認方法です。詳しくはプライバシーポリシー。