JWT Decoder 작동 원리
JWT는 점으로 구분된 Header, Payload, Signature 세 부분으로 구성됩니다. 앞의 두 부분은 Base64URL 형식으로 인코딩된 UTF-8 JSON이므로 -와 _ 문자를 표준 Base64 문자로 바꾸고 패딩을 복원한 뒤 텍스트와 객체로 해석할 수 있습니다. payload의 iat와 exp가 숫자라면 Unix 초로 보고 로컬 시간으로 표시합니다. 세 번째 서명은 비밀키나 공개키와 알고리즘 검증이 필요하므로 이 도구는 절대 검증하지 않으며 단순 디코딩 결과만 보여줍니다.
이 페이지의 계산과 변환은 모두 현재 브라우저에서 실행됩니다. 원문과 결과를 ReadyTools 서버에 전송하거나 데이터베이스에 저장하지 않으며, 입력 내용은 localStorage에도 기록하지 않습니다. 다만 운영체제나 브라우저의 클립보드 기록, 확장 프로그램, 화면 공유 기능은 사이트 밖의 영역이므로 민감한 데이터는 테스트용으로 바꾸어 사용하는 편이 안전합니다.
JWT Decoder 사용 방법
입력 형식 확인
페이지에 표시된 입력 예시와 형식을 확인하고 분석하거나 변환할 데이터를 붙여 넣습니다. 오류 안내가 나오면 강조된 항목의 문법과 범위를 먼저 확인하세요.
브라우저에서 실행
실행 버튼을 누르면 외부 API 호출 없이 현재 탭에서 처리됩니다. 모바일에서는 완료 후 결과 카드로 자동 이동하며 키보드만으로도 모든 항목을 조작할 수 있습니다.
결과 검토·복사
결과의 구조와 주의사항을 확인한 뒤 복사 버튼을 사용합니다. 실제 프로젝트에 반영하기 전에는 대상 언어, 서비스와 데이터 규칙에 맞는지 다시 테스트하세요.
구체적인 상황으로 이해하는 활용 예시
다음 세 상황은 도구의 처리 과정과 결과 해석을 설명하기 위한 가상 예시입니다. 입력 조건을 바꾸면 결과도 달라지므로 자신의 조건과 비교해 확인하세요.
1. 만료 시각 숫자의 단위 확인
가상 Payload에 exp: 1704067200이 있다면 초 단위로 UTC 2024년 1월 1일 0시를 뜻합니다. 한국 시간대 기기에서는 오전 9시로 표시됩니다. 현재 시각과 비교한 만료 여부를 보여 주지만 서명을 확인하지 않으므로 exp가 미래라고 유효한 인증 토큰이라고 판단해서는 안 됩니다.
2. Header와 Payload의 역할 구분
가상 Header의 alg가 HS256이고 Payload의 sub가 "123"이라면 도구는 이 두 필드를 각각 JSON으로 보여 줍니다. 숫자처럼 보이는 "123"은 사용자 식별 문자열이며 사용자 계정의 존재를 확인한 결과가 아닙니다. 키나 서명을 검증하지 않은 디코딩 결과는 디버깅 자료로만 읽어야 합니다.
3. 점으로 나뉜 부분이 부족한 경우
a.b처럼 두 부분만 있는 입력은 도구가 기대하는 세 부분 구조와 달라 오류입니다. 세 부분이라고 모두 정상 JWT인 것도 아니며 Header와 Payload가 해석 가능한 Base64URL JSON인지 추가로 확인합니다. 회사 운영 토큰 대신 만료된 테스트 값을 사용하고 결과를 공유하기 전 식별 정보가 남아 있는지 점검하세요.
개발 환경에서 토큰의 issuer, audience, subject, scope와 만료 시각을 빠르게 확인할 때 사용할 수 있습니다. JWT payload는 암호화된 비밀 공간이 아니라 누구나 디코딩할 수 있는 데이터이므로 주민번호, 비밀번호와 불필요한 개인정보를 넣어서는 안 됩니다. 실제 인증 로직에서는 alg 허용 목록, 키 회전, iss·aud·exp·nbf 검증과 시계 오차 정책을 신뢰할 수 있는 서버 라이브러리로 처리해야 합니다.
주의사항
디코딩 성공은 토큰이 진짜이거나 안전하다는 뜻이 아닙니다. 서명 부분을 임의로 바꿔도 Header와 Payload는 표시될 수 있습니다. 운영 토큰은 클립보드 기록, 화면 캡처와 로그에 남기지 말고 가능하면 만료된 테스트 토큰을 사용하세요. 인증 결정은 서버의 검증된 JWT 라이브러리에서만 수행해야 합니다.