JWT Decoder

JWT 디코더 / 인코더

JWT를 디코딩하여 헤더, 페이로드, 서명을 한눈에 확인하거나 HS256/384/512로 새 토큰에 서명할 수 있어요. HMAC 서명은 로컬에서 검증되며, 100% 브라우저 안에서 실행됩니다.

JWT 디코더 / 인코더 — TL;DR

JWT를 디코딩하여 헤더, 페이로드, 서명을 한눈에 확인하거나 HS256/384/512로 새 토큰에 서명할 수 있어요. HMAC 서명은 로컬에서 검증되며, 100% 브라우저 안에서 실행됩니다.

아니요. 도구 전체가 이 페이지 안의 자바스크립트로 동작해요. 토큰을 붙여넣으면 디코딩은 브라우저에서 일어나고, 바이트는 탭 밖으로 나가지 않아요. DevTools → 네트워크를 열고 확인해 보세요 — 디코딩이나 검증 중에는 어떤 요청도 전송되지 않아요. 그래서 실제 고객용·운영 환경 토큰을 붙여넣어도 안전합니다.

서명은 토큰이 시크릿(HMAC) 또는 개인키(RSA/ECDSA)를 가진 누군가에 의해 서명되었음을 증명해요. 페이로드를 암호화하지는 않아요 — 헤더와 페이로드는 단순한 base64url 인코딩 JSON이라 토큰을 가진 사람은 누구나 읽을 수 있어요. 서명은 변조만 막아 줘요. 페이로드의 단 1바이트라도 바꾸면 서명이 더 이상 일치하지 않습니다.

JWT는 종종 사용자 ID, 이메일, 스코프, 때로는 세션 쿠키와 동등한 정보를 담아요 — 정확히 낯선 사람의 서버에 붙여넣으면 안 되는 데이터죠. iKit의 디코더는 이미 브라우저 탭에 로드된 자바스크립트로 동작해요. DevTools → 네트워크에서 검증할 수 있어요. 디코딩이나 검증 중에는 fetch도, XHR도, beacon도 없어요.

헤더

페이로드

서명

표준 클레임


            


            

                
HMAC 서명 검증

                
HS256/384/512 토큰의 경우, 서명에 사용한 시크릿을 입력하면 로컬에서 서명을 검증해요. RS256/ES256(RSA/ECDSA)은 서버 측 라이브러리를 사용해 주세요. 공개키 검증에는 PEM 파일이 필요한데, 여기서는 받지 않아요.

                

                    

                        
                        
                    

                    
                    
                

            


            

                
                
            

        


        
        

        
    


    
    

        

            
iKit JWT 디코더를 사용하는 이유

            
JWT를 디버깅하는 가장 빠른 방법 — 업로드도, 회원가입도, 토큰과 사용자 사이의 제삼자도 없어요.

        

        

                                        

                    

                        
                            
                        
                    

                    
세 패널, 한 번의 붙여넣기

                    
JWT를 붙여넣으면 디코딩된 헤더, 페이로드, 서명이 나란히 보여요. 표준 클레임(iss, sub, aud, exp, iat)은 타임스탬프와 라벨이 함께 표시됩니다.

                

                            

                    

                        
                            
                        
                    

                    
로컬 HMAC 검증

                    
HS256/384/512 토큰은 시크릿을 입력하면 브라우저의 Web Crypto API로 서명을 검증해요. 시크릿은 탭 밖으로 절대 나가지 않습니다.

                

                            

                    

                        
                            
                        
                    

                    
직접 토큰에 서명

                    
인코딩 모드로 전환해 헤더와 페이로드를 JSON으로 편집하고, 알고리즘을 선택한 뒤 시크릿을 입력하면 서명된 토큰을 즉시 받을 수 있어요.

                

                            

                    

                        
                            
                        
                    

                    
설계부터 프라이버시 우선

                    
JWT 페이로드에는 사용자 ID, 이메일, 때로는 스코프가 들어 있어요 — 절대 서버 도구에 붙여넣지 마세요. iKit의 디코더는 브라우저 안에서 자바스크립트로 동작하며, DevTools → 네트워크에서 직접 확인할 수 있어요.

                

                            

                    

                        
                            
                        
                    

                    
만료 인지

                    
exp, nbf, iat 같은 표준 클레임은 사람이 읽을 수 있는 날짜와 명확한 만료됨/유효 배지로 강조되어, 토큰이 여전히 쓸 만한지 한눈에 알 수 있어요.

                

                            

                    

                        
                            
                        
                    

                    
열린 표준, 열린 코드

                    
브라우저의 기본 Web Crypto API와 JSON 파서 위에 구축됐어요 — OpenSSL, libjwt, jose와 동일한 알고리즘이며, 모든 최신 JWT 라이브러리와 동작이 일치합니다.

                

                    

    

    

    

        
JWT 디코딩이 실제로 동작하는 방식

        
JWT는 점으로 구분된 세 개의 base64url 인코딩 JSON 세그먼트일 뿐이에요.

    


    
    
                                
  1. 
                
    1
    
                
    
                    
    두 개의 점으로 분리
    
                    
    JWT는 aaa.bbb.ccc 형태예요. 두 개의 점을 기준으로 분리하면 인코딩된 헤더, 페이로드, 서명이 나와요. 정확히 세 부분이 아니면 토큰이 잘못된 거예요.
    
                
    
            
    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을 다시 계산해 세 번째 세그먼트의 서명과 비교해요. HMAC(SHA-256, secret, signing_input)을 base64url로 인코딩한 것과 같아요. 일치하면 서명이 유효한 거예요.
    
                
    
            
    5. 
            






    

        
흔한 JWT 디버깅 작업

        
JWT 디코더가 필요해지는 실제 상황들이에요.

    


    

                    

                
인증 제공자가 발급한 토큰 살펴보기

                
Auth0, Firebase, Keycloak, AWS Cognito는 모두 로그인 후 JWT를 반환해요. access_token을 붙여넣어 앱이 실제로 어떤 클레임을 받고 있는지 확인해 보세요 — 사용자 ID는 무엇인지, 어떤 스코프인지, 언제 만료되는지요.

            

                    

                
401 Unauthorized 디버깅

                
API가 요청을 거부하나요? 토큰을 디코딩해 확인해 보세요. 만료되었나요(exp가 과거)? audience 클레임(aud)이 API가 기대하는 값인가요? issuer(iss)가 올바른 테넌트인가요?

            

                    

                
웹훅 서명 검증

                
Stripe, GitHub Apps, Slack은 JWT로 서명된 웹훅 페이로드를 보내요. 받은 뒤 디코딩 모드에 페이로드와 공유 시크릿을 함께 입력해 요청이 정말 그들에게서 왔는지 확인할 수 있어요.

            

                    

                
테스트 토큰 생성

                
통합 테스트용으로 갓 서명된 JWT가 필요한가요? 인코딩 모드로 전환해 페이로드(맞춤 사용자 ID, 맞춤 만료)를 편집하고, HS256과 테스트 시크릿을 선택하면 밀리초 안에 토큰을 받을 수 있어요. 백엔드 왕복이 필요 없어요.

            

            






    

        
로컬 JWT 디코딩이 중요한 이유

        
JWT는 종종 사용자 ID, 이메일, 스코프, 때로는 세션 쿠키와 동등한 정보를 담아요 — 정확히 낯선 사람의 서버에 붙여넣으면 안 되는 데이터죠. iKit의 디코더는 이미 브라우저 탭에 로드된 자바스크립트로 동작해요. DevTools → 네트워크에서 검증할 수 있어요. 디코딩이나 검증 중에는 fetch도, XHR도, beacon도 없어요.

        
    
                            
  • 
                    
                    디코딩이나 검증 중 네트워크 요청이 0건 — DevTools에서 검증 가능해요.
                
    • 
                            
  • 
                    
                    검증을 위해 입력한 시크릿은 브라우저 메모리에만 머물고, 지우기/새로고침 시 삭제돼요.
                
    • 
                            
  • 
                    
                    운영 토큰, 고객 액세스 토큰, 웹훅 시크릿에도 안전해요.
                
    • 
                    

    






    

        
관련 가이드

        
iKit 블로그의 심층 튜토리얼과 도구 비교.

    


    





    
    

        

            
자주 묻는 질문

        

        

                            

                    
                        안전한가요? 제 JWT가 업로드되나요?
                        
                    
                    
아니요. 도구 전체가 이 페이지 안의 자바스크립트로 동작해요. 토큰을 붙여넣으면 디코딩은 브라우저에서 일어나고, 바이트는 탭 밖으로 나가지 않아요. DevTools → 네트워크를 열고 확인해 보세요 — 디코딩이나 검증 중에는 어떤 요청도 전송되지 않아요. 그래서 실제 고객용·운영 환경 토큰을 붙여넣어도 안전합니다.

                

                            

                    
                        JWT 서명은 실제로 무엇을 검증하나요?
                        
                    
                    
서명은 토큰이 시크릿(HMAC) 또는 개인키(RSA/ECDSA)를 가진 누군가에 의해 서명되었음을 증명해요. 페이로드를 암호화하지는 않아요 — 헤더와 페이로드는 단순한 base64url 인코딩 JSON이라 토큰을 가진 사람은 누구나 읽을 수 있어요. 서명은 변조만 막아 줘요. 페이로드의 단 1바이트라도 바꾸면 서명이 더 이상 일치하지 않습니다.

                

                            

                    
                        디코딩된 페이로드는 멀쩡해 보이는데 검증이 실패해요. 왜죠?
                        
                    
                    
흔한 원인이 세 가지 있어요. (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를 읽기 좋은 행으로), 그리고 디코딩된 전체를 한 번에 복사하는 버튼을 제공해 버그 리포트에 바로 붙여넣을 수 있어요.