Base64 / URL / JWT エンコーダー・デコーダー

Base64 や URL をエンコード・デコードし、JWT のヘッダーとペイロードをブラウザで確認できます。

テキストまたは JWT

出力

使用する前に結果を確認してください。 このツールは現状のまま無保証で提供されており、結果が不完全または誤っている場合があります。利用規約

JWT のデコードでは署名を検証しないため、デコードできたことはトークンが本物で有効である証明にはなりません。URL デコードでは "+" を空白に変換しません。Base64 はエンコードであり、暗号化ではありません。

使い方

「テキストまたは JWT」欄に入力を貼り付けるか入力します。エンコードするテキスト、デコードする Base64 文字列やパーセントエンコードされた文字列、または確認したい JWT を入れられます。
テキストと Base64 を相互に変換するには「Base64 エンコード」または「Base64 デコード」を、パーセントエンコードを付けたり外したりするには「URL エンコード」または「URL デコード」をクリックします。結果またはエラーメッセージは「出力」欄に表示されます。
トークンを確認するには、Bearer の接頭辞があってもなくてもそのまま貼り付け、「JWT デコード」をクリックします。ヘッダーとペイロードがインデント付きの JSON で表示され、ペイロードに iat、nbf、exp クレームがあれば「JWT の時刻クレーム」に一覧表示されます。数値の場合は UTC と現地時刻に変換されます。
「結果をコピー」をクリックすると出力をコピーできます。エンコードを元に戻すには、エンコードされたテキストを「テキストまたは JWT」欄に貼り付け、対応するデコードのボタンをクリックします。ただし、デコードしてから再びエンコードしても、元とまったく同じになるとは限りません。URL セーフな Base64 やパディングのない Base64 は標準のアルファベットに戻り、必要に応じて = のパディングが付きます。また、「URL デコード」で残った + は「URL エンコード」で %2B になります。

よくある質問

貼り付けたテキストやトークンはどこかに送信されますか？

いいえ。エンコードとデコードはブラウザ内の JavaScript で行われ、入力した内容は LeedyBox に送信されません。JWT はログイン用の認証情報としてよく使われ、有効期限が切れるか無効化されるまでは、手に入れた人が誰でも使える場合があります。有効なトークンはパスワードと同じように扱い、スクリーンショットやチャットで共有しないでください。

「Base64 デコード」で有効な UTF-8 テキストではないと表示されるのはなぜですか？

「Base64 デコード」はデコードしたバイト列を UTF-8 テキストとして表示し、有効な UTF-8 でない場合はこのエラーで止まります。PNG や JPEG の画像、ほとんどの PDF、圧縮データのほか、Latin-1 や Shift_JIS など別のエンコーディングで保存されたテキストも多くの場合これに当たります。このツールにはデコードしたバイト列をファイルとして保存する機能がないため、テキストを含む Base64 に使ってください。data:image/png;base64,... のようなデータ URI は、コロン、セミコロン、カンマが Base64 の文字ではないため、無効な Base64 として扱われます。

URL セーフな Base64 やパディングのない値も扱えますか？

デコード時は扱えます。「Base64 デコード」は標準の文字（+ と /）と URL セーフな文字（- と _）の両方を受け付け、= のパディングの有無を問わず、空白や改行は無視します。「Base64 エンコード」はパディング付きの標準の文字で出力するため、JWT で使われる URL セーフな形式にするには + を - に、/ を _ に置き換え、末尾の = を削除してください。テキストは入力したとおりに UTF-8 でエンコードされるため、末尾に空白や改行があると結果が変わります。また、入力欄内の改行は LF としてエンコードされます。

「URL エンコード」で URL 全体をエンコードしてもよいですか？

通常はおすすめしません。「URL エンコード」は JavaScript の encodeURIComponent と同じように動作し、A–Z、a–z、0–9 と - _ . ! ~ * ' ( ) 以外のすべての文字をパーセントエンコードするため、URL の構造を作る / ? & = : # もエンコードされます。クエリパラメーターの値 1 つなど、URL の一部分に使ってください。空白は %20 になり、ASCII 以外の文字は UTF-8 のバイト列としてエンコードされるので、たとえば é は %C3%A9 になります。

プラス記号が空白に変換されないのはなぜですか？また「URL デコード」がエラーになるのはどんなときですか？

「URL デコード」は JavaScript の decodeURIComponent と同じように動作し、%XX のエスケープシーケンスをデコードして、+ はそのまま残します。一般的な URL の構文（RFC 3986）では、+ は空白を表さないためです。一方、多くのクエリ文字列で使われる HTML フォームのデータ（application/x-www-form-urlencoded）では空白が + で表されるため、そのようなデータはデコードする前に + をすべて空白に置き換えてください。この形式では本来のプラス記号は %2B と書かれるので、置き換えた後も正しくデコードされます。50% off のように % の後に 16進数 2 桁が続かない場合や、%E2%82 のようにエスケープされたバイトが有効な UTF-8 でない場合にエラーになります。

「JWT デコード」ではどんなトークンを読めますか？

署名付き JWT（JWS）で使われる header.payload.signature の 3 部構成のコンパクト形式のトークンを読めます。署名部分が空の署名なしトークンも含みます。署名部分は検証しないため、デコードできてもトークンが本物である証明にはなりません。暗号化されたトークン（JWE）は 5 つの部分からなり、鍵がなければペイロードを読めないため、形式エラーになります。ヘッダーやペイロードを Base64 から JSON にデコードできない場合や、ペイロードが JSON オブジェクトではなく文字列や数値などの単純な値である場合は、「JWT 解析エラー」のメッセージが表示されます。ヘッダーやペイロードに 9,007,199,254,740,991 より大きい整数があると、ブラウザが JSON を解析するときに丸められることがあるため、長い数値の ID は末尾の桁が違って表示される場合があります。

exp、nbf、iat の時刻はどのように表示され、トークンはいつ期限切れと表示されますか？

値は JWT の標準（RFC 7519）の定義どおり秒単位の Unix 時刻として読み取られ、UTC と現地時刻で表示されます。「期限切れ」と「まだ有効ではありません」は、「JWT デコード」をクリックした時点の端末の時計と exp、nbf を比べた結果です。時計のずれは考慮しないため、時計が合っていなければ状態も正しく表示されません。サーバーによっては、多くの場合数分以内のわずかな猶予を認めているため、exp や nbf の時刻の前後では、ここに表示される状態とサーバーの判断が異なることがあります。"1700000000" のように文字列で書かれた時刻は、「有効な数値の Unix タイムスタンプではありません」と表示されます。