ByteCompress

Base64デコーダー

Base64エンコードされた文字列を元のプレーンテキストまたはバイナリ表現にデコードします。標準RFC 4648およびURLセーフBase64アルファベットの両方をサポートし、JWTトークンを含みます。

0 chars
FreeClient-sideNo signup

Base64文字列は設計上不透明です - SGVsbG8sIFdvcmxkIQ==はデコードされるまでHello, World!とは無関係です。RFC 4648で定義されているBase64は、3バイトの入力を4文字の出力としてエンコードし、約33%のオーバーヘッドを追加します。このデコーダーは、ブラウザのネイティブatob()およびTextDecoder APIを使用してそれを逆転させます。標準のBase64とJWTやOAuthトークンで使用されるURLセーフバリアント（-と_が+と/の代わりに使用される）をサポートしています。何もサーバーにアップロードされることはありません。

Base64をデコードする方法

  1. Base64エンコードされた文字列を入力フィールドに貼り付けます。
  2. データが元々エンコードされた方法に合わせて、標準またはURLセーフモードを選択します。
  3. デコードされたプレーンテキストが出力パネルにすぐに表示されます。
  4. コピーをクリックして結果をコピーします。

Base64デコードの仕組み

デコードプロセス

デコードはエンコードを正確に逆にします。各Base64文字はアルファベットテーブルを使用して6ビット値にマッピングされます。4つの連続した文字（24ビット）が3バイトを再構築します。ブラウザのatob()関数は標準のBase64をネイティブに処理します。URLセーフBase64の場合、-と_はデコードの前に+と/に戻されます。得られたUTF-8バイトシーケンスは、TextDecoderを使用してUnicode文字列にデコードされます。

不足しているパディングの処理

標準のBase64では、文字列の長さを4の倍数にするために=パディングが必要です。JWTとOAuthトークンはサイズを減らすためにパディングを削除します。このデコーダーは、文字列の長さに基づいて必要なパディングを自動的に計算して追加します。文字列の長さが4で割った余りが2の場合は=が1つ必要で、3の場合は=が2つ必要です。

例

入力（標準Base64）

SGVsbG8sIFdvcmxkIQ==

出力

Hello, World!

一般的な使用例

  • JWTトークンの検査 - ライブラリなしでクレームを読むためにヘッダーとペイロードセクションをデコードします
  • HTTP Basic Auth - Authorization: Basic dXNlcjpwYXNzヘッダーをデコードして埋め込まれた資格情報を確認します
  • データURIの検査 - data:image/png;base64,... URIのBase64部分をデコードします
  • APIレスポンスのデバッグ - 一部のAPIはJSONレスポンスでバイナリコンテンツをBase64エンコードします

ベストプラクティス

  • 正しいモード（標準対URLセーフ）を選択してください - 間違ったモードを使用すると出力が乱れます
  • JWTトークンの場合、ヘッダー（最初の部分）とペイロード（2番目の部分）だけをデコードしてください；3番目の部分は暗号学的署名であり、エンコードされたテキストではありません
  • 出力が読めない文字の場合、元のデータはバイナリ（画像、PDFなど）であり、テキストではありません
  • Base64デコードはセキュリティチェックではありません - 誰でもデコードできます

テキストをBase64に再エンコードするには、Base64エンコーダーを使用してください。URLエンコードされたデータには、URLデコーダーを使用してください。JWTを完全に検査するには、最初の2つのドットで区切られた部分をURLセーフモードを選択して別々にデコードしてください。

よくある質問

このツールでJWTトークンをどうやってデコードしますか？

JWTは、ドットで区切られた3つの部分から構成されます：header.payload.signature。ヘッダー（最初の部分）またはペイロード（2番目の部分）をコピーし、URLセーフモードを選択してデコーダーに貼り付けてください。出力はアルゴリズム（ヘッダー）またはクレーム（ペイロード）を含むJSONオブジェクトです。署名をデコードしないでください - それは暗号学的ハッシュであり、Base64エンコードされたJSON文字列ではありません。

デコードされた出力に奇妙な文字が表示されるのはなぜですか？

これは3つのことのいずれかを意味します：(1) 元のデータがテキストではなくバイナリ（画像、PDF、zip）であった；(2) モードを間違えて選択した - 標準とURLセーフの間で切り替えてみてください；(3) 元のテキストがUTF-8以外の文字セットを使用してエンコードされていた。まずモードを切り替えてみてください。出力がまだ読めない場合、元のデータはおそらくバイナリでした。

デコードが機能するためにパディング文字（==）は必要ですか？

標準のBase64では、文字列の長さを4の倍数にするためにパディングが必要です。このデコーダーは、JWTやOAuthトークンの末尾の=文字を削除するために重要な不足しているパディングを自動的に追加します。文字列をそのまま貼り付けると、デコーダーが自動的にパディングを処理します。

ここでデコードするとき、私の敏感なデータは安全ですか？

はい。デコードは、ネイティブのatob()およびTextDecoder APIを使用して完全にブラウザ内で実行されます。貼り付けたトークン、資格情報、およびプライベートデータは、サーバーに送信されることはなく、ログに記録されることもなく、保存されることもありません。デコード中にブラウザのネットワークタブを開くと、外部リクエストがゼロであることがわかります。

標準とURLセーフBase64の違いは何ですか？

標準のBase64（RFC 4648 §4）は+と/を使用します。URLセーフBase64（RFC 4648 §5）は、URL、ファイル名、およびHTTPヘッダーでの競合を避けるために、それらを-とに置き換えます。JWT、OAuthトークン、およびPKCEコード検証子はすべてURLセーフBase64を使用します。文字列に-またはが含まれている場合は、URLセーフモードを選択してください。