エンコード

Base64 エンコード / デコード

UTF-8 テキストを貼り付ければエンコードでき、Base64 文字列を貼り付ければデコードできます。標準 Base64 と Base64url の両方に対応しているため、多言語テキスト、JSON 断片、JWT セグメント、Basic Auth の値、URL パラメータ、ログ項目の確認に使えます。URL セーフモードはリンク、Cookie、token 値に向いており、デコード時にはよくある padding 欠落も扱います。エンコード、デコード、コピー、往復確認はすべてブラウザ内で行われるため、認証情報、token、社内ログがアップロードされることはありません。

  • 標準 Base64 と Base64url を切り替えられ、通常のテキスト、リンク用パラメータ、token 断片を扱いやすい
  • UTF-8 テキストを正しく扱い、日本語、中国語、Emoji、アクセント付き文字、JSON も安全に往復変換できます
  • デコード時に長さと文字種を検証し、無効な入力では曖昧な文字化けではなく明確なエラーを表示します
  • JWT セグメントや URL セーフな値でよくある padding 欠落を自動的に補ってデコードできます
  • 出力をそのまま入力へ戻し、逆方向に変換することで元の内容に戻るか確認できます
  • すべてのデータは現在のブラウザタブ内で処理されるため、認証情報、token、社内ログの確認にも使いやすい設計です
工具/Base64 エンコード / デコード
0 文字
入力待ち
結果がここに表示されます...
エンコード

概要

日常的な API デバッグや認証まわりの調査で必要になる Base64 変換、URL セーフな変種、padding 処理、往復確認を、ローカルで完結できるワークベンチです。

  1. 01

    UTF-8 テキストのエンコード

    多言語テキスト、JSON 断片、設定値、認証用文字列を標準 Base64 に変換できます。内容は UTF-8 バイトとして扱うため、日本語、中国語、Emoji、アクセント付き文字も安定して往復できます。

  2. 02

    Base64 をテキストへデコード

    API レスポンス、ログ、メッセージキュー、キャッシュ値、データベース項目に含まれる Base64 文字列を、読みやすいテキストへ戻せます。結果が有効な UTF-8 テキストでない場合は、判断しづらい文字化けを表示するのではなくエラーとして知らせます。

  3. 03

    Base64url モード

    URL セーフモードでは、リンク、Cookie、ファイル名、JWT 値に向いた Base64url 形式を使います。出力をこうした場所へ渡す場合は、このオプションを有効にしてください。

  4. 04

    padding 欠落への対応

    JWT セグメントや URL セーフ値では、末尾の padding が省略されることがよくあります。デコード時には Base64 のグループ規則に従ってよくあるケースを処理するため、手作業で = を足す手間を減らせます。

  5. 05

    リアルタイムの検証状態

    変換に成功すると、エンコード済みまたはデコード済みの状態を表示します。長さが不正、文字種が合わない、対応していない文字が含まれる場合は、出力パネルにすぐエラーを表示します。

  6. 06

    往復確認

    出力を入力へ戻し、モードを切り替えて逆方向に変換できます。自分のコードが文字種、padding、UTF-8、URL セーフ形式を同じように扱えているか確認するのに便利です。

  7. 07

    サンプル入力

    通常テキスト、JSON、URL セーフ値のサンプルを用意しています。実データを貼り付ける前に、現在のモードが期待どおりか確認できます。

  8. 08

    完全にローカルで処理

    エンコード、デコード、コピー、往復確認はすべて現在のブラウザタブ内で行われます。認証情報、JWT セグメント、Basic Auth の値、社内ログ、個人情報が端末の外へ出ることはありません。

使い方

変換方向を選び、入力を貼り付け、必要に応じて URL セーフモードを有効にすると、結果がリアルタイムに更新されます。

  1. 01

    変換モードでエンコードまたはデコードを選びます。

  2. 02

    入力欄にテキストまたは Base64 文字列を貼り付けます。エンコードは UTF-8 テキストを受け取り、デコードは標準 Base64 と Base64url を扱えます。

  3. 03

    値を URL、Cookie、JWT、または類似の token フィールドで使う場合は、URL セーフモードを有効にします。

  4. 04

    出力状態を確認します。有効な結果はすぐ表示され、無効な入力では分かりやすいエラーが出ます。

  5. 05

    結果をコピーするか、出力を入力に使うで入力欄へ戻し、モードを切り替えて元の内容に戻るか確認します。

詳細

変換方向は入力と出力を決めます。URL セーフモードは、その値を安全に通せる場所を決めます。

  • Basic Auth の値、JSON フィールド、設定断片、ログサンプル、Data URL の内容、Base64 テキストを要求するシステム向けにはエンコードを使います。
  • API レスポンス、ログ項目、キャッシュ値、メッセージ、Webhook データ、JWT セグメントの中身を確認したいときはデコードを使います。
  • URL クエリ、パス断片、Cookie、ファイル名、JWT に入る値には URL セーフモードを使います。
  • Basic Auth、メール MIME、Data URL、SMTP、多くのテキストプロトコルでは、通常は標準 Base64 を使います。
  • 入力がどちらの形式か分からない場合は、まず標準 Base64 を試し、失敗したら URL セーフモードを有効にして再試行してください。
  • このページはテキスト向けです。画像、PDF、圧縮ファイル、音声には、ファイルまたは画像に対応した Base64 ツールを使ってください。

活用シーン

Base64 は API、認証、メッセージ、キャッシュ、フロントエンドの埋め込みリソースによく現れます。同じ貼り付け → 変換 → コピーの流れで、日常的な確認作業の多くをカバーできます。

  1. JWT セグメントの確認

    JWT の header や claims セグメントを貼り付け、URL セーフモードを有効にすると、issuer、期限、scope、カスタムフィールドを確認できます。

  2. Basic Auth 値の作成

    username と password の組み合わせを標準 Base64 にエンコードし、Authorization header の Basic スキームの後ろに置く値を作れます。

  3. Data URL 用の内容

    小さなアイコン、インライン SVG、メールテンプレート、単一ファイルのプロトタイプで、HTML、CSS、JSON に埋め込む Base64 内容を準備できます。

  4. API フィールドのデバッグ

    REST、GraphQL、Webhook レスポンスに含まれる Base64 フィールドをデコードし、その値が cursor、署名材料、設定、通常テキストのどれなのか確認できます。

  5. メッセージとキャッシュの確認

    Redis、Kafka、SQS、データベースのバイナリ項目に保存されたテキストを、一時的なスクリプトを書かずに確認できます。

  6. OAuth と署名付きリクエストのデバッグ

    OAuth state、OIDC nonce、PKCE verifier、パートナー署名リクエストに含まれる Base64url 断片を確認し、双方が同じエンコード仕様を使っているか検証できます。

  7. コールバックパラメータの処理

    値をコールバック URL に入れる前に Base64url へエンコードすることで、標準 Base64 の文字がリンク解析で誤処理される問題を減らせます。

  8. メール MIME の確認

    生のメールソースから Base64 エンコードされた MIME パートを取り出し、本文、添付ファイルのメタデータ、テンプレート内容を確認できます。

  9. 往復テスト

    まずエンコードし、その出力を入力としてデコードして、元のテキストに戻るか確認します。padding や形式の不一致を素早く見つけられます。

  10. 言語間の契約確認

    同じテキストに対するバックエンドサービスとフロントエンドクライアントの Base64 出力を比較し、UTF-8、padding、URL セーフモードの取り決めが一致しているか確認できます。

関連情報

Base64 の結果をさらにリンクやフォーム本文に通す必要がある場合は、続けて URL エンコーダー・デコーダー でパーセントエンコードできます。Bearer token、SSO、セッション状態を調べる場合は、JWT インスペクター で JWT の header、claims、signature の関係を確認できます。画像を HTML、CSS、JSON に埋め込みたい場合は 画像 to Base64 を使ってください。すでに画像の Base64 文字列があり、プレビューしたりファイルへ戻したりしたい場合は Base64 to 画像 が便利です。

使い方のヒント

Base64 の問題は、アルゴリズムそのものよりも、形式、文字エンコーディング、通す場所のルールが曖昧なことから起きがちです。

  • コードを書く前に、標準 Base64 を使うのか Base64url を使うのか、padding を残すのか省略するのかを決めて記録してください。
  • URL、Cookie、ファイル名、JWT に入る値には Base64url を優先してください。
  • 言語間でテキストを共有する場合は、UTF-8 を明示的に取り決めてください。日本語、中国語、アクセント付き文字の破損を避けられます。
  • デコードに失敗したら、余分な空白、padding の欠落、または Base64 の形式選択ミスを最初に確認してください。
  • ログやメールから Base64 をコピーする場合は、改行やスペースを取り除くのが安全です。このツールは一般的な空白を扱えますが、ほかのパーサーも同じとは限りません。
  • Base64 をセキュリティ機能として扱わないでください。これはエンコードであり、秘匿性、認証、完全性保護は提供しません。
  • ライブラリ、言語、ランタイムを変更したときは、エンコードとデコードの往復テストを行い、結果を元のテキストと比較してください。
  • 大きなバイナリデータを Base64 にすると、サイズはおよそ 3 分の 1 増えます。ファイルアップロード、署名付き URL、バイナリストリームのほうが向いていることも多いです。

制限事項

Base64 は可逆的なエンコードであり、役割は明確です。制限を理解しておくと、セキュリティ対策やファイル処理として誤用するのを避けられます。

  • Base64 はエンコードであり、暗号化ではありません。誰でもデコードできるため、token、パスワード、個人情報を隠す目的で使わないでください。
  • このページはテキスト向けです。画像、PDF、圧縮ファイル、音声には、ファイルをバイトとして読めるツールを使ってください。
  • Base64 はデータサイズをおよそ 3 分の 1 増やします。大きなファイルではメモリ、帯域、クリップボードに負荷がかかります。
  • テキストは UTF-8 として扱います。GBK、Shift-JIS など古い文字コードのデータは、先にバイトレベルで変換する必要があります。
  • 数十 MB 規模の入力では、テキストエリアやクリップボード操作が遅くなることがあります。その規模ではストリーミング処理やファイル対応ツールのほうが適しています。
  • 標準 Base64 と Base64url をツールが黙って推測することはありません。データの出どころに合わせて URL セーフモードを明示的に選んでください。
  • デコードでは長さと文字種を厳密に検証します。1 文字でも不正な文字があれば、静かな破損を避けるため入力全体を失敗として扱います。

よくある質問

形式の違い、padding、Unicode、安全性、プライバシー、データの完全性について、実用的な質問をまとめました。

Base64 は暗号化ですか？

いいえ。Base64 はバイトを表示可能な文字として表すだけの仕組みです。鍵はなく、秘匿性もありません。誰でもデコードできます。秘密にしたい場合は暗号化を使い、改ざん検知が必要な場合は HMAC やデジタル署名を使ってください。

標準 Base64 と Base64url の違いは何ですか？

Base64url は URL、Cookie、ファイル名で扱いやすい文字を使い、末尾の padding を省略することもよくあります。標準 Base64 は Basic Auth、MIME、Data URL、テキストプロトコルでよく使われます。

一部のブラウザ API が日本語や Emoji で失敗するのはなぜですか？

古い方法の中には単一バイトの文字列しか受け付けないものがあり、日本語、中国語、Emoji、アクセント付き文字で失敗します。このツールは Base64 変換の前にテキストを UTF-8 バイトへ変換するため、多言語テキストを正しく扱えます。

デコード結果が文字化けするのはなぜですか？

入力がバイナリ内容である、元のテキストが UTF-8 ではない、または Base64 の形式を間違えている可能性があります。まず URL セーフモードを試し、それでもおかしい場合はファイルツールや文字コード変換ツールが必要かもしれません。

Base64 文字列の末尾に padding がないのはなぜですか？

URL セーフ値や JWT セグメントでは、末尾の padding を省略することがよくあります。このツールはデコード時によくある padding 欠落を処理するため、通常は手動で = を足す必要はありません。

このツールでファイルをエンコードできますか？

このページはテキスト入力だけを扱います。画像、PDF、その他のファイルは、ファイルをバイトとして読み込める画像 Base64 変換ツールやファイル対応ツールを使ってください。

入力したデータはブラウザの外へ送信されますか？

いいえ。エンコード、デコード、検証、コピー、出力を入力に使うはすべて現在のブラウザタブ内で実行されます。入力がサーバーへ送られることはありません。

JWT は Base64url を使っていますか？

はい。JWT の header、claims、signature の各セグメントは、padding なしの Base64url を使います。JWT セグメントを扱うときは URL セーフモードを有効にしてください。

デコードはできるのに URL に入れると失敗するのはなぜですか？

標準 Base64 の値をそのまま URL に入れている可能性があります。URL セーフモードは Base64url を生成するため、リンク解析に向いています。

Base64 の形式を自動判定できますか？

短い文字列では信頼できる判定ができません。多くの文字は標準 Base64 と Base64url の両方で有効だからです。デコードに失敗した場合は、URL セーフモードを切り替えて試してください。

どれくらい大きな入力まで扱えますか？

数 MB 程度なら通常は快適です。数十 MB になるとページやクリップボード操作が目に見えて遅くなるため、そのサイズではストリーミング処理やファイル対応ツールのほうが適しています。

Base64 はデータの完全性を守れますか？

いいえ。Base64 にはチェックサム、認証、署名の仕組みがありません。内容が変更されていないことを確認したい場合は、エンコード前に HMAC、デジタル署名、または別の完全性保護を適用してください。

関連ツール

関連する作業も続けられます。結果を URL 用にパーセントエンコードしたり、JWT セグメントを確認したり、画像 Base64 とスキャンコード系ツールを切り替えたりできます。