JWT 디코더

JWT(JSON Web Token)를 디코딩하여 Header, Payload, Signature를 확인합니다. 토큰의 만료 시간과 클레임 정보를 쉽게 확인할 수 있습니다.

표준 클레임 (Registered Claims)

iss - 발급자 (Issuer)
sub - 주제 (Subject)
aud - 대상 (Audience)
exp - 만료 시간 (Expiration)
nbf - 유효 시작 시간 (Not Before)
iat - 발급 시간 (Issued At)
jti - 토큰 ID (JWT ID)

JWT 디코더 안내

JWT(JSON Web Token)란?

JWT는 JSON 형식의 데이터를 안전하게 전송하기 위한 개방형 표준(RFC 7519)입니다. 웹 애플리케이션에서 사용자 인증, 권한 부여, 정보 교환에 널리 사용됩니다. JWT는 Header(알고리즘 정보), Payload(실제 데이터), Signature(서명) 세 부분으로 구성되고, 각 부분이 점(.)으로 연결된 문자열입니다. 서버는 비밀키로 서명을 검증해서 토큰이 변조되지 않았는지 확인합니다. API 개발이나 디버깅 과정에서 토큰의 내용을 빠르게 확인해야 하는 상황이 자주 발생하는데, 이 도구를 사용하면 복잡한 Base64 디코딩 없이 Header와 Payload를 한눈에 파악할 수 있습니다. 토큰의 만료 상태까지 자동으로 확인해주기 때문에 인증 관련 문제를 진단하는 데 걸리는 시간을 크게 줄여줍니다.

내부 동작

JWT 디코더는 입력된 토큰 문자열을 점(.) 기준으로 세 부분으로 분리합니다. Header와 Payload는 각각 Base64URL 인코딩되어 있으므로, 표준 Base64로 변환한 뒤 atob() 함수로 디코딩하고 JSON.parse()로 파싱합니다. Base64URL은 표준 Base64와 달리 +를 -로, /를 _로 치환하고 패딩(=)을 생략한 형식입니다. 세 번째 부분인 Signature는 Header에 명시된 알고리즘과 비밀키를 사용해 생성된 해시값입니다. 서명 검증 시 이 도구는 Web Crypto API를 활용해 HMAC-SHA256/384/512 알고리즘으로 서명을 재계산하고, 원본 서명과 바이트 단위로 비교합니다. Payload에 포함된 exp, iat, nbf 같은 시간 관련 클레임은 Unix Timestamp에서 사람이 읽을 수 있는 날짜 형식으로 자동 변환되며, 현재 시각과 비교해 토큰의 유효 상태를 판별합니다.

사용 방법

  1. JWT 토큰 입력란에 검사할 토큰 문자열을 넣습니다. 입력란 오른쪽 위의 붙여넣기 버튼을 누르면 클립보드 내용이 바로 들어갑니다.
  2. 디코딩 버튼을 클릭합니다. 형식이 잘못된 토큰이면 입력란 아래에 오류 메시지가 표시됩니다.
  3. 맨 위의 토큰 상태 배너에서 유효, 만료, 아직 유효하지 않음 중 어느 상태인지 먼저 확인합니다. 만료된 토큰이라면 얼마나 지났는지도 함께 표시됩니다.
  4. 토큰 구조 영역에서 점(.)으로 나뉜 세 부분이 색상별로 구분되어 보이고, 그 아래 Header(노란색), Payload(파란색), Signature(분홍색) 카드에서 각 부분의 내용을 정리된 JSON으로 읽을 수 있습니다. 각 카드의 복사 버튼으로 개별 복사도 가능합니다.
  5. 클레임 상세 영역에서는 exp, iat 같은 시간 클레임이 사람이 읽을 수 있는 날짜로 변환되어 나옵니다.
  6. HS256 계열 토큰의 서명을 확인하고 싶다면 Signature 카드의 비밀키(Secret Key) 입력란에 키를 넣고 검증 버튼을 누릅니다. 검증 결과가 바로 아래에 표시됩니다.

개발 현장에서 이렇게 씁니다

401 오류 원인 추적: API가 갑자기 401 Unauthorized를 반환할 때 가장 흔한 원인은 토큰 만료입니다. 요청 헤더에서 토큰을 복사해 여기에 붙여 넣으면 exp 클레임이 날짜로 변환되어 만료 여부가 즉시 보입니다. 만료가 아니라면 aud나 iss 값이 서버 설정과 다르지는 않은지, 토큰이 아예 다른 환경(개발/운영)에서 발급된 것은 아닌지 클레임을 하나씩 대조해 볼 수 있습니다.

발급 로직 점검: 로그인 API를 새로 만들었을 때, 발급된 토큰에 역할(role)이나 권한 스코프 같은 커스텀 클레임이 의도대로 들어갔는지 확인하는 데 유용합니다. iat과 exp의 간격을 보면 토큰 수명이 설정값과 일치하는지도 검산할 수 있습니다.

주의할 점: 디코딩은 검증이 아닙니다. Payload가 보인다고 해서 그 토큰이 진짜라는 뜻은 아니며, 서명을 비밀키로 확인하기 전까지는 내용이 위조되지 않았다고 보장할 수 없습니다. 또한 운영(프로덕션) 서비스의 비밀키는 어떤 온라인 도구에도 입력하지 않는 것이 원칙입니다. 이 도구는 모든 처리를 브라우저 안에서 하지만, 검증 연습은 테스트용 키로 하는 습관을 권장합니다.

자주 묻는 질문

비밀키 없이도 내용이 다 보이는데, JWT는 안전한 건가요?

JWT의 Header와 Payload는 암호화가 아니라 Base64URL 인코딩일 뿐이라서 누구나 디코딩해 읽을 수 있습니다. JWT가 보장하는 것은 기밀성이 아니라 무결성, 즉 "내용이 변조되지 않았다"는 사실이며 이는 서명으로 확인합니다. 그래서 비밀번호나 주민등록번호 같은 민감 정보는 절대 Payload에 넣으면 안 됩니다.

서명은 왜 비밀키 없이 검증할 수 없나요?

서명은 Header와 Payload를 비밀키로 해시한 값입니다. 같은 키로 다시 계산해서 일치하는지 비교하는 것이 검증이므로, 키가 없으면 수학적으로 확인할 방법이 없습니다. 키 없이 "검증됐다"고 표시하는 도구가 있다면 형식 검사만 한 것이니 신뢰하면 안 됩니다.

exp가 지난 토큰인데도 디코딩이 되는 이유는요?

만료는 서버가 토큰을 수락할지 판단하는 기준일 뿐, 문자열 자체는 그대로 남아 있기 때문에 언제든 디코딩할 수 있습니다. 오히려 만료된 토큰을 열어 exp와 iat을 확인하는 것이 인증 오류 디버깅의 첫 단계입니다.

RS256으로 서명된 토큰은 여기서 검증이 안 되나요?

이 도구의 서명 검증은 대칭키 방식인 HMAC 계열(HS256, HS384, HS512)만 지원합니다. RS256처럼 공개키/개인키를 쓰는 비대칭 방식은 발급자의 공개키(JWKS)가 필요해서 별도의 검증 절차를 거쳐야 합니다. 디코딩 자체는 알고리즘과 무관하게 모두 가능합니다.

붙여 넣은 토큰이나 비밀키가 서버로 전송되지는 않나요?

전송되지 않습니다. 디코딩은 브라우저의 atob() 함수로, 서명 검증은 Web Crypto API로 전부 로컬에서 처리됩니다. 네트워크 탭을 열어 확인해 봐도 토큰 관련 요청이 발생하지 않습니다. 그럼에도 운영 환경의 비밀키는 입력하지 않는 것이 안전 수칙입니다.

iat이 미래 시각으로 나오거나 exp가 이상하게 계산됩니다.

시간 클레임은 밀리초가 아닌 초 단위 Unix Timestamp여야 합니다. 발급 코드에서 밀리초 값을 그대로 넣으면 수만 년 뒤의 날짜로 표시되는데, 실제로 자주 발생하는 실수입니다. 서버와 클라이언트의 시계가 어긋나 있어도 방금 발급한 토큰이 만료로 표시될 수 있습니다.

exp 클레임이 아예 없는 토큰은 어떻게 처리되나요?

exp는 필수 클레임이 아니므로 만료 시간 없이 발급된 토큰도 형식상 유효합니다. 이 경우 도구는 만료 판정 없이 내용만 표시합니다. 다만 만료되지 않는 액세스 토큰은 유출 시 영구적으로 악용될 수 있어 보안 관점에서는 피해야 할 설계이며, 실서비스라면 짧은 exp와 리프레시 토큰 조합을 권장합니다.

alg가 none인 토큰도 있던데 정상인가요?

"alg": "none"은 서명이 없는 토큰을 뜻하며, 실서비스에서 이를 수락하면 누구나 토큰을 위조할 수 있는 심각한 취약점이 됩니다. 디코딩 결과에서 alg 값이 none이거나 예상과 다른 알고리즘이라면 발급 로직과 서버의 알고리즘 허용 목록을 반드시 점검해야 합니다.

비슷한 도구 살펴보기

관련 가이드