Base64エンコード/デコード
文字をBase64にしたり、元に戻したりします。
無料・登録不要
使い方
- 1「テキスト」に入れます
- 2「変換方向」でエンコードかデコードを選びます
- 3「変換する」を押します
例
入力例
Hello, World!
結果の例
SGVsbG8sIFdvcmxkIQ==
あわせて使えるツール
使い方と例文
Base64エンコード/デコードの使い方
- 1エンコードまたはデコードを選択します
- 2変換したいテキストを入力します
- 3「変換する」ボタンをクリックして結果をコピーします
Base64エンコード/デコードの例文・サンプル
エンコード例
Hello, World!
SGVsbG8sIFdvcmxkIQ==
デコード例
44GT44KT44Gr44Gh44Gv
こんにちは
よくある質問
Base64エンコード/デコードは無料ですか?
スマートフォンでも使えますか?
入力したコードやデータは安全ですか?
判断基準と失敗例
良いBase64エンコード/デコードの判断基準
API 連携やデータ埋め込みで Base64 の変換が必要になったら、変換結果を使う前に下の判断基準で確認してください。最初に押さえるべき大前提は、Base64 は「暗号化」ではなく単なる表現形式の変換だということです。
Base64 を「暗号化」と誤解していないか
Base64 は誰でも元に戻せる変換であり、中身を隠す効果はゼロです。見た目がランダムな文字列になるため誤解されがちですが、秘匿の手段としては使えません。
変換方向は正しいか
エンコード(テキストを Base64 に)とデコード(Base64 をテキストに)を取り違えていないかを確認します。エンコード済みの文字列をさらにエンコードすると、相手側で 1 回のデコードでは元に戻りません。
デコード結果が文字化けしていないか
Base64 はバイト列の変換なので、元データの文字コードが違うとデコード結果が文字化けします。日本語が崩れた場合は、元データがどの文字コードで作られたかを確認します。
URL で使うなら URL セーフ版が必要か確認したか
通常の Base64 に含まれる「+」「/」「=」は URL の中で特別な意味を持つため、URL に埋め込む用途では URL セーフな変種が使われます。送り先の仕様がどちらを期待しているかを確認します。
改行や余分な空白が混ざっていないか
メールやチャット経由でコピーした Base64 文字列には、途中に改行や空白が入り込んでいることがあります。デコードに失敗する時は、まず文字列の途中に余計な文字がないかを疑います。
機密データの貼り付け先を確認したか
認証情報やトークンを変換する時は、貼り付け先のツールがサーバーに送信しないことを確認します。本ツールはブラウザ内で変換が完結し、入力内容を送信しません。
ありがちな失敗例(NG → 改善)
NGパスワードを Base64 にエンコードして「暗号化したから安全」と考えて保存・送信する。
改善秘匿が必要なデータには暗号化の仕組みを使い、Base64 は形式変換としてだけ使う。
Base64 は手順を知っていれば誰でも一瞬で元に戻せます。秘匿の効果はまったくありません。
NG通常の Base64 文字列をそのまま URL のパラメータに入れて、受け取り側でデータが壊れる。
改善URL に入れる場合は、URL セーフな形式が必要かどうかを送り先の仕様で確認してから変換する。
「+」「/」「=」は URL の中で別の意味に解釈されるため、通常の Base64 のままでは正しく届かないことがあります。
NGメール本文からコピーした Base64 文字列を、途中の改行ごと貼り付けてデコードに失敗する。
改善貼り付け前に文字列の途中の改行・空白を取り除き、ひと続きの文字列にしてから変換する。
Base64 は文字の並びがそのままデータなので、余計な文字の混入や欠落があると正しく復元できません。
くわしい説明
テキストをBase64形式にエンコード、またはBase64文字列をデコード。API認証やデータ転送時の変換に。
Base64 変換をブラウザだけで済ませたいとき
Base64は、データを英数字と一部の記号(+ / =)だけの文字列で表す方式です。Base64は、バイナリデータをテキスト形式で送受信できるようにするエンコード方式です。Web開発・API連携・メール添付・JWT トークン解析などで頻繁に使われますが、ブラウザの開発者ツールで毎回コードを書いて変換するのは手間です。本ツールはテキストを Base64 にエンコード、または Base64 文字列をデコードする処理を、ブラウザ内で実行します。サーバー送信なしのクライアントサイド処理のため、機密データも外に送らずに扱えます。
画面にあるのは「テキスト」の入力欄と「変換方向」の選択(エンコードとデコードの2つ)だけです。扱えるのは貼り付けたテキストで、画像ファイルを読み込ませる欄はありません。以下では、編集部が実際にこのツールで4パターンを変換し、返ってきた文字列とエラー文をそのまま載せます。
JWT のペイロード確認や data URI 作成で Base64 変換が要る場面
【1. JWT トークンのデコード解析】Web認証で使うJWTのペイロード部分(Base64エンコードされている)を読み解く時に使えます。
【2. データURIスキームの作成】CSSやHTMLに小さな画像を埋め込む data:URI では、画像を Base64 にした文字列が使われます。本ツールで扱えるのはその文字列の確認と変換で、画像ファイルから変換する場合はサイト内の画像の Base64 変換ツールを使います。
【3. APIで送受信するバイナリデータの処理】REST APIで画像やファイルをやり取りする時、Base64エンコードされたデータを確認・編集できます。
いずれも「相手のシステムが Base64 の形で渡してくる」「Base64 の形で渡さなければならない」場面です。逆に、中身を人に見せたくないから Base64 にする、という使い方はこの一覧に入りません。Base64 は手順を知っていれば誰でも元に戻せる変換で、隠す効果はないためです。実際に日本語をエンコードして戻した結果を次に置きます。
日本語テキストをエンコードして戻した実処理結果
最初に試したのは、日本語のエンコードとデコードの往復です。変換方向に「エンコード」を選び、テキスト欄に次の1文を入れました。
入力: こんにちは、無料AIツール集です。 出力: 44GT44KT44Gr44Gh44Gv44CB54Sh5paZQUnjg4Tjg7zjg6vpm4bjgafjgZnjgII=
続けて、この出力をそのままテキスト欄に貼り直し、変換方向を「デコード」に切り替えました。
入力: 44GT44KT44Gr44Gh44Gv44CB54Sh5paZQUnjg4Tjg7zjg6vpm4bjgafjgZnjgII= 出力: こんにちは、無料AIツール集です。
往復して元の日本語に完全に戻り、読点や句点も含めて文字化けは起きませんでした。出力を見ると、元の1文よりも文字列が長くなっていること、末尾に「=」が付いていることが分かります。この「=」は Base64 で長さを整えるための文字で、コピーの範囲から外れるとデコードに失敗する原因になります。
ただしこれは今回の1文で見えた範囲で、どんな文字コードのデータでも同じように元へ戻る保証ではありません。自分のデータで使う前に、まず短い1文で往復させて確かめてください。
壊れた文字列と URL セーフな Base64 をデコードした実処理結果
次の2つは、うまくいかない側の結果です。どちらも変換方向は「デコード」を選んでいます。
入力: !!!not-valid-base64!!! 出力: エラー「この入力はBase64形式ではありません。テキストをBase64に変換する場合は「エンコード」を選択してください。」
入力: aGVsbG8tXw-- 出力: 同じエラー「この入力はBase64形式ではありません。テキストをBase64に変換する場合は「エンコード」を選択してください。」
後者は壊れたデータではありません。URL の中で別の意味を持ってしまう「+」を「-」に、「/」を「_」に置き換えた、URL セーフ Base64 と呼ばれる書き方の文字列です。トークンや ID の受け渡しでは珍しくない形式ですが、本ツールは標準の Base64 だけを受け付けるため、記号だらけの壊れた文字列を入れたときとまったく同じ文言のエラーになりました。
Base64 デコードで分かったクセと、エラー文言の弱点
分かったクセは2つあります。1つ目は、日本語を含むテキストでも、エンコードとデコードが往復で一致したこと。2つ目は、失敗したときの文言が「テキストをBase64に変換する場合は「エンコード」を選択してください」と続く形になっていて、変換方向の選び間違いには気づきやすいことです。
弱点ははっきり出ました。URL セーフ Base64 をデコードできないことと、そのときのエラー文言が原因を伝えないことです。「この入力はBase64形式ではありません」という一文は、壊れた文字列を入れたときと同じで、「-」や「_」が含まれているせいだとは読み取れません。JWT や OAuth まわりの値は URL セーフ形式で流通することがあるため、貼り付けてエラーになったら、「-」を「+」に、「_」を「/」に戻した文字列で試し直すのが早い切り分けになります(戻して通るかどうかは、実際に入れて確かめてください)。
今回試したのは4パターンで、この範囲では処理が固まる、結果の一部が欠けるといった破綻は起きませんでした。ただしこれは4パターンで見えた範囲であり、どんな入力でも同じ結果になる保証ではありません。
Base64 に向かない用途と、貼り付ける前に見る点
1つ目の失敗は、Base64 を「暗号化」と誤解することです。Base64 は単なるエンコード(変換)であり、暗号化ではありません。誰でも簡単にデコードできるため、機密情報をBase64だけで保護してはいけません。
2つ目は、URL 用途の Base64 と通常の Base64 の違いです。URL 内では「+」「/」「=」が問題になるため、URL Safe Base64(base64url)が使われます。用途に応じて使い分けてください。実測でも、URL セーフ形式の文字列は本ツールでデコードできませんでした。
3つ目は、改行の扱いです。MIME 規格では Base64 文字列に改行を入れる仕様がありますが、API用途では改行なしが期待されることが多いです。出力結果の改行有無を確認してください。
向かないのは、パスワードや API キーを隠す目的で使うこと、社外向けの説明で「暗号化した」と表現すること、そして URL セーフ形式が前提のやり取りに本ツールの出力をそのまま流すことです。前の2つは Base64 の性質上できません。最後の1つは、実測で形式の違いが表に出た点です。
コマンドの base64 やライブラリとの使い分け
コマンドラインの base64 コマンドや、プログラミング言語の標準ライブラリでも変換可能ですが、ブラウザですぐ確認したい場合に手間です。本ツールはブラウザ内で完結し、サーバー送信なしで瞬時にエンコード・デコードできます。機密性の高いトークンや認証情報を扱う場合も、外部サーバーに送信されないため安全です。会員登録もログインも不要です。
一方で、URL セーフ形式を扱う、大きなファイルを丸ごと変換する、変換を自動で何度も繰り返す、といった作業はライブラリやコマンド側が向きます。本ツールが向くのは、手元にある1つの文字列の中身を今すぐ見たい、短い文字列を1回だけ変換したい、という場面です。実測の範囲では、その用途では往復して元の文字列に戻りました。
変換した Base64 文字列を渡す前に確認する3点
1つ目は、往復で元に戻るかを自分のデータで1回試すことです。今回は日本語の1文で戻りましたが、確かめる作業自体は1分で終わります。
2つ目は、コピーの範囲です。出力の末尾に付く「=」まで選択できているか、途中に改行が混ざっていないかを見ます。実測の出力も末尾が「=」でした。
3つ目は、エラーが出たときの切り分けです。「この入力はBase64形式ではありません」という同じ文言が、壊れた文字列のときにも URL セーフ形式のときにも出ました。文字列の中に「-」や「_」があるなら、壊れているのではなく形式が違う可能性を先に疑ってください。
この3点は、4パターンを実際に変換して分かった内容から作っています。最終的な判断は、渡す相手のシステムがどの形式を求めているかで決めてください。