JWT Decoder

JWT デコーダー / エンコーダー

JSON Web Tokenをデコードしてヘッダー・ペイロード・署名を確認したり、HS256/384/512で新しいトークンに署名したりできます。HMAC署名はローカルで検証。すべてブラウザ内で完結します。

JWT デコーダー / エンコーダー — TL;DR

JSON Web Tokenをデコードしてヘッダー・ペイロード・署名を確認したり、HS256/384/512で新しいトークンに署名したりできます。HMAC署名はローカルで検証。すべてブラウザ内で完結します。

いいえ。ツール全体がこのページ内のJavaScriptで動作します。トークンを貼り付けるとデコードはブラウザ内で行われ、バイトがタブから出ることはありません。DevTools → Networkを開いて確認してみてください。デコードや検証中にリクエストは送信されません。そのため、本番環境のトークンや顧客のトークンを貼り付けても安全です。

シークレット（HMAC）または秘密鍵（RSA/ECDSA）を持つ誰かによってトークンが署名されたことを証明します。ペイロードを暗号化するわけではありません。ヘッダーとペイロードはbase64urlでエンコードされたJSONにすぎず、トークンを持つ人なら誰でも読めます。署名は改ざんを防ぐためのもので、ペイロードを1バイトでも変更すると署名は一致しなくなります。

JWTにはユーザーID、メール、スコープ、場合によってはセッションCookie相当の情報が含まれることが多く、まさに見知らぬ人のサーバーに貼り付けてはいけないデータです。iKitのデコーダーはすでにブラウザのタブに読み込まれているJavaScriptとして動作します。DevTools → Networkで確認可能で、デコードや検証の間にfetch、XHR、beaconは一切発生しません。

ヘッダー

ペイロード

署名

標準クレーム


            


            

                
HMAC署名を検証

                
HS256/384/512のトークンの場合、署名用シークレットを入力するとローカルで署名を検証できます。RS256/ES256（RSA/ECDSA）の場合は、サーバーサイドのライブラリをご利用ください。公開鍵検証にはここでは扱わないPEMファイルが必要です。

                

                    

                        
                        
                    

                    
                    
                

            


            

                
                
            

        


        
        

        
    


    
    

        

            
iKit JWTデコーダーが選ばれる理由

            
JWTをデバッグする最速の方法。アップロード不要、サインアップ不要、あなたとトークンの間に第三者は介在しません。

        

        

                                        

                    

                        
                            
                        
                    

                    
3つのペイン、1回の貼り付け

                    
JWTを貼り付けるだけで、デコードされたヘッダー・ペイロード・署名を並べて確認できます。標準クレーム（iss、sub、aud、exp、iat）にはタイムスタンプとラベルが付きます。

                

                            

                    

                        
                            
                        
                    

                    
ローカルでのHMAC検証

                    
HS256/384/512のトークンでは、シークレットを入力するとブラウザのWeb Crypto APIを使って署名を検証します。シークレットがタブの外に出ることはありません。

                

                            

                    

                        
                            
                        
                    

                    
自分でトークンに署名

                    
エンコードモードに切り替えて、ヘッダーとペイロードをJSONとして編集し、アルゴリズムを選んでシークレットを入力すれば、署名済みトークンを瞬時に取得できます。

                

                            

                    

                        
                            
                        
                    

                    
プライバシー重視の設計

                    
JWTのペイロードにはユーザーIDやメール、スコープが含まれることがあります。決してサーバー側ツールに貼り付けないでください。iKitのデコーダーはブラウザ内のJavaScriptとして動作します。DevTools → Networkで確認できます。

                

                            

                    

                        
                            
                        
                    

                    
有効期限の可視化

                    
exp、nbf、iatなどの標準クレームを人間が読める日付で表示し、「期限切れ」または「有効」のバッジを明示するので、トークンが今も有効かひと目で分かります。

                

                            

                    

                        
                            
                        
                    

                    
オープンな標準、オープンなコード

                    
ブラウザネイティブのWeb Crypto APIとJSONパーサー上に構築されており、OpenSSL、libjwt、joseと同じアルゴリズムを使用します。動作は最新のJWTライブラリと一致します。

                

                    

    

    

    

        
JWTデコードの仕組み

        
JWTは、ドットで区切られた3つのbase64urlエンコード済みJSONセグメントです。それだけです。

    


    
    
                                
  1. 
                
    1
    
                
    
                    
    2つのドットで分割する
    
                    
    JWTは aaa.bbb.ccc のような形式です。2つのドットで分割すると、エンコードされたヘッダー・ペイロード・署名が得られます。3つの部分にならない場合、そのトークンは不正です。
    
                
    
            
    2. 
                                
  2. 
                
    2
    
                
    
                    
    各部分をBase64URLデコード
    
                    
    ヘッダーとペイロードはbase64urlでエンコードされたUTF-8のJSONです。Base64URLはBase64の +//= の代わりに -/_ を使い、パディングがありません。文字を元に戻してから atob を行い、得られた文字列をJSON.parseします。
    
                
    
            
    3. 
                                
  3. 
                
    3
    
                
    
                    
    構造化して表示する
    
                    
    ヘッダーはアルゴリズム（alg: HS256、RS256など）と種別を示します。ペイロードにはクレームが含まれます。標準のもの（iss、sub、aud、exp、iat、nbf、jti）に加え、任意のカスタムフィールドも入ります。それぞれをラベル付きのセクションで表示します。
    
                
    
            
    4. 
                                
  4. 
                
    4
    
                
    
                    
    検証（HMACのみ）
    
                    
    HS256/384/512では、入力されたシークレットを使って header.payload のHMACを再計算し、3番目のセグメントの署名と比較します。HMAC(SHA-256, secret, signing_input) をbase64urlエンコードしたものと同じです。一致すれば署名は有効です。
    
                
    
            
    5. 
            






    

        
JWTデバッグでよくある作業

        
JWTデコーダーが必要になる現実的な場面です。

    


    

                    

                
認証プロバイダーから受け取ったトークンを確認する

                
Auth0、Firebase、Keycloak、AWS Cognitoはいずれもログイン後にJWTを返します。access_tokenを貼り付けると、アプリが実際に受け取っているクレームを確認できます。ユーザーIDは何か、スコープは何か、有効期限はいつか。

            

                    

                
401 Unauthorizedをデバッグする

                
APIがリクエストを拒否していますか？トークンをデコードして確認しましょう。期限切れ（exp が過去）になっていませんか？オーディエンスクレーム（aud）はAPIが期待する値ですか？発行者（iss）は正しいテナントですか？

            

                    

                
Webhook署名の検証

                
Stripe、GitHub Apps、SlackはJWTとして署名されたWebhookペイロードを送信します。受信したらデコードモードに貼り付け、共有シークレットと合わせて検証することで、本当にそれらから送られたリクエストであることを確認できます。

            

                    

                
テスト用トークンの生成

                
結合テスト用に新しい署名済みJWTが必要ですか？エンコードモードに切り替え、ペイロードを編集し（カスタムのユーザーIDや有効期限）、HS256とテスト用シークレットを選べば、ミリ秒単位でトークンを生成できます。バックエンドへの往復は不要です。

            

            






    

        
JWTをローカルでデコードすることが重要な理由

        
JWTにはユーザーID、メール、スコープ、場合によってはセッションCookie相当の情報が含まれることが多く、まさに見知らぬ人のサーバーに貼り付けてはいけないデータです。iKitのデコーダーはすでにブラウザのタブに読み込まれているJavaScriptとして動作します。DevTools → Networkで確認可能で、デコードや検証の間にfetch、XHR、beaconは一切発生しません。

        
    
                            
  • 
                    
                    デコードや検証の間、ネットワークリクエストはゼロ。DevToolsで確認可能です。
                
    • 
                            
  • 
                    
                    検証のために入力したシークレットはブラウザのメモリ内に留まり、クリアまたは更新時に消去されます。
                
    • 
                            
  • 
                    
                    本番トークン、顧客のアクセストークン、Webhookシークレットでも安全に使えます。
                
    • 
                    

    






    

        
関連ガイド

        
iKit ブログの詳しいチュートリアルとツール比較。

    


    





    
    

        

            
よくある質問

        

        

                            

                    
                        安全ですか？JWTがアップロードされることはありませんか？
                        
                    
                    
いいえ。ツール全体がこのページ内のJavaScriptで動作します。トークンを貼り付けるとデコードはブラウザ内で行われ、バイトがタブから出ることはありません。DevTools → Networkを開いて確認してみてください。デコードや検証中にリクエストは送信されません。そのため、本番環境のトークンや顧客のトークンを貼り付けても安全です。

                

                            

                    
                        JWTの署名は実際に何を検証しているのですか？
                        
                    
                    
シークレット（HMAC）または秘密鍵（RSA/ECDSA）を持つ誰かによってトークンが署名されたことを証明します。ペイロードを暗号化するわけではありません。ヘッダーとペイロードはbase64urlでエンコードされたJSONにすぎず、トークンを持つ人なら誰でも読めます。署名は改ざんを防ぐためのもので、ペイロードを1バイトでも変更すると署名は一致しなくなります。

                

                            

                    
                        デコードされたペイロードは正常に見えるのに、検証が失敗するのはなぜですか？
                        
                    
                    
よくある原因は3つあります。(1) シークレットの間違い。JWTのシークレットは大文字小文字を区別し、空白の不一致でも検証は失敗します。(2) アルゴリズムの不一致。ヘッダーがHS256でも、元はHS512で署名されていた、というケース。(3) 署名後にトークンが改変された。1バイトでも変わると署名は壊れます。header.algが期待どおりか確認してください。

                

                            

                    
                        RS256やES256など、公開鍵アルゴリズムには対応していますか？
                        
                    
                    
iKitは現在、HMAC検証（HS256/384/512）のみに対応しています。RS256とES256は公開鍵暗号を用いるため、検証には発行者のPEM形式の公開鍵が必要で、UIがより複雑になります。現時点でもデコード自体は可能で（ヘッダー・ペイロード・署名は正しく表示されます）、検証ボタンを押すとサポート外であることが表示されます。RSA/ECDSAの検証は今後対応予定です。

                

                            

                    
                        jwt.ioとはどう違いますか？
                        
                    
                    
発想は同じですが、デフォルトの設計が異なります。iKitのデコーダーは完全にブラウザ内で動作します（jwt.ioも同様ですが、iKitのコードはview-sourceで確認でき、当ドメインにはサードパーティのトラッカーがありません）。expクレームに対する明確な「期限切れ／有効」バッジ、構造化されたクレームの表示（iat / nbf / iss / sub / aud / jtiを読みやすい行で表示）、デコード結果一括コピーボタンを備えており、バグレポートに貼り付ける完全な構造化出力を取得できます。