JWT 디코더

JWT 디코딩 방법

1. 토큰을 입력 칸에 붙여 넣습니다. Authorization 헤더 값을 통째로 복사했다면 앞의 Bearer 는 자동으로 지워집니다. 예시 토큰을 누르면 샘플이 채워져 화면 구성을 먼저 볼 수 있습니다.
2. 헤더와 페이로드가 들여쓰기된 JSON으로 나란히 표시되고, 각각 복사 버튼이 있습니다.
3. 아래 표에는 서명 알고리즘과 찾아낸 표준 클레임이 정리됩니다. 시각은 내 시간대의 읽기 쉬운 날짜로 바뀌고, ‘2시간 전 만료됨’, ‘유효함, 5일 후 만료’, ‘아직 유효하지 않음’ 같은 설명이 붙습니다.

문제가 있으면 상태 줄이 원인을 알려 줍니다. 점으로 나뉜 부분이 없거나, 어떤 부분이 올바른 Base64url이 아니거나, 올바른 JSON이 아니거나, 토큰에 서명 부분이 없는 경우입니다.

토큰의 구조

JSON 웹 토큰(RFC 7519)은 Base64url 문자열 세 개를 점으로 이은 것입니다: header.payload.signature. Base64url은 일반 Base64에서 +와 / 대신 -와 _를 쓰고 = 패딩을 뺀 것으로, 토큰을 URL이나 HTTP 헤더에 그대로 넣을 수 있게 해 줍니다. 아래는 HS256과 비밀 키 demo-secret으로 서명한 완전한 토큰입니다.

세 부분을 점으로 이어 위 칸에 붙여 넣어 보세요. 2026년 1월 1일 00:00 UTC(한국 시간 오전 9시)에 발급되어 한 시간 뒤에 만료되었다고 나옵니다. 거의 모든 JWT는 eyJ로 시작하는데, {" 뒤에 영문자가 오면 Base64로 이렇게 바뀌기 때문입니다. 로그 파일에서 JWT를 알아보는 간단한 방법입니다.

자주 보는 클레임

• iss(발급자) – 토큰을 만든 곳. 흔히 인증 서버의 URL입니다.
• sub(주체) – 토큰의 대상. 보통 사용자 ID입니다.
• aud(대상자) – 토큰을 받아들여야 할 서비스. 문자열일 수도, 목록일 수도 있습니다.
• exp, nbf, iat – 만료, 유효 시작, 발급 시각으로, 1970년부터의 초 단위 값입니다. 유닉스 타임스탬프 변환기에서 원하는 단위로 볼 수 있습니다.
• jti – 토큰마다 붙는 고유 ID. 재사용 공격을 막거나 토큰 하나만 폐기할 때 씁니다.

name, email, role, scope 같은 나머지 값은 애플리케이션이 정한 것이라 페이로드 보기에만 나옵니다. 헤더의 kid는 서명에 쓴 키의 이름으로, 서버가 여러 공개 키 가운데 알맞은 키를 고를 수 있게 해 줍니다.

디코딩은 검증이 아닙니다

이 페이지는 토큰을 읽을 뿐, 진짜인지 확인하지는 않습니다. 헤더와 페이로드는 인코딩만 되어 있으므로 누구나 "role":"admin"이라고 적힌 토큰을 만들 수 있습니다. 이를 막는 것은 서명뿐이고, 서명을 확인하려면 HMAC 비밀 키나 발급자의 공개 키가 필요하며 이 키는 토큰을 받는 서버에 있어야 합니다. 서버는 다음을 지켜야 합니다.

1. 헤더에 적힌 알고리즘이 아니라 서버가 미리 정해 둔 알고리즘으로 서명을 검증하고, ‘서명 없음’을 뜻하는 "alg":"none"은 거부합니다.
2. exp와 nbf를 서버 자신의 시계와 비교하되, 시계 오차를 감안해 약간의 여유를 둡니다.
3. iss와 aud가 신뢰하는 값인지 확인합니다.

이 과정은 직접 짠 코드보다 꾸준히 관리되는 JWT 라이브러리에 맡기세요. 이런 디코더는 디버깅용이지, 누구를 들여보낼지 결정하는 도구가 아닙니다.

서명 알고리즘

• HS256 / HS384 / HS512 – 공유 비밀 키를 쓰는 HMAC. 검증할 수 있는 쪽은 토큰을 만들 수도 있으므로 비밀 키는 신뢰할 수 있는 서버에만 두어야 합니다.
• RS256, PS256 – RSA 서명. 발급자는 개인 키로 서명하고, 누구나 공개 키로 검증할 수 있습니다.
• ES256 – P-256 곡선의 ECDSA. RSA보다 키와 서명이 작습니다.
• EdDSA – Ed25519 서명. 새로운 시스템에서 점점 많이 쓰입니다.

디버깅 팁

• 갑자기 ‘안 되는’ 토큰은 대개 그냥 만료된 것입니다. 먼저 exp를 현재 시각과 비교하세요.
• 로그인 직후인데 ‘아직 유효하지 않음’이 나온다면 발급 서버와 수신 서버의 시계가 어긋나 있는 경우가 많습니다.
• 새로 받은 토큰인데 401 오류가 난다면 대상자가 틀린 경우가 많습니다. aud를 호출하려는 API와 비교해 보세요.
• 한 부분의 원래 바이트를 보고 싶다면 URL-safe 모드를 켠 Base64 디코더로도 확인할 수 있습니다.

자주 묻는 질문

실제 토큰을 여기에 붙여 넣어도 안전한가요?

디코딩은 모두 이 페이지의 JavaScript 안에서 이루어지고 토큰은 업로드되지 않습니다. 그래도 살아 있는 토큰은 만료될 때까지 통하는 자격 증명이므로, 가능하면 만료된 토큰이나 테스트용 토큰을 쓰고, 실제 토큰을 이슈 트래커나 채팅에 올리지 마세요.

페이로드에 민감한 데이터를 넣어도 되나요?

안 됩니다. 이 페이지에서 보듯 토큰을 가진 사람은 누구나 읽을 수 있습니다. 내용 자체를 숨겨야 한다면 암호화된 토큰(JWE)을 쓰세요. JWE는 세 부분이 아니라 다섯 부분으로 이루어지며, 키 없이는 디코딩할 수 없습니다.

‘토큰에 서명 부분이 없습니다’라고 나오는 이유는?

입력이 두 부분뿐이기 때문입니다. 복사하다가 토큰이 잘렸거나 서명 없는 토큰일 때 이렇게 되며, 서명 없는 토큰은 서버가 거부해야 합니다.

만료 전에 토큰을 무효로 만들려면?

서명된 JWT는 발급한 뒤에는 바꿀 수 없습니다. 중간 로그아웃이 필요한 시스템은 토큰의 수명을 짧게 하고, 서버에 jti 차단 목록을 두거나 서명 키를 교체합니다.