JWT 디코더
JWT 토큰의 헤더·내용을 디코딩하고 만료 시각도 보여줘요.
이럴 때 쓰세요
이렇게 사용하세요
결과가 예상과 다를 때
결과가 잘려 보여요
전체 결과는 복사 버튼으로 받을 수 있어요.
입력한 내용이 사라졌어요
이 기기에 자동 저장돼요. 브라우저 저장소를 지우면 함께 사라져요.
자주 하는 실수
- 헤더의 alg를 보고 복호화 방식을 정하지 마세요. 알고리즘 교체 공격이 가능한 구성들이 있어 서버는 허용 목록으로만 검증해야 합니다.
- 페이로드에 권한 정보를 담아도 보안이 된 건 아니에요. 서명 검증 없이 믿으면 값이 조작됩니다.
- 만료 시각은 UTC 기준 Unix 타임스탬프입니다. 한국 시각으로 읽을 때 9시간 차이를 잊지 마세요.
- 헤더와 페이로드는 복호화가 아니라 Base64URL 디코딩입니다. 암호문이 아니므로 개인정보를 담지 마세요.
계산 근거
JWT는 RFC 7519로 정의된 JOSE 형식의 토큰으로, 점으로 연결된 세 부분인 헤더·페이로드·서명으로 나뉩니다. 각 부분은 Base64URL 인코딩되어 있고, 헤더의 alg에 서명 알고리즘(RS256, HS256 등)이 들어갑니다.
실제로 계산해 보면
만료가 1,800,000,000이면 언제예요?
Unix 타임스탬프(UTC) 1,800,000,000은 2027년 1월 15일 08:00 UTC입니다. 한국 시각으로 같은 시각의 오후 5시예요.
eyJhbGciOiJIUzI1NiJ9를 디코딩하면?
Base64URL로 풀면 {"alg":"HS256"}이 나옵니다. 이게 JWT 헤더라는 뜻이며, 나머지 두 부분도 같은 방식으로 읽어요.
세 부분 중 서명만 비어 있으면?
마지막이 빈 문자열이면 서명이 없는 토큰입니다. 이때 헤더의 alg를 임의로 바꿔 보내면 토큰 위조를 뜻하기 쉬워서, 서버는 서명 검증을 강제해야 합니다.
더 궁금한 것
서명 검증을 왜 서버에서 하나요?
검증에 필요한 키를 클라이언트에 둘 수 없기 때문입니다. 브라우저에 키가 있으면 공격자도 같은 키로 위조 토큰을 만들 수 있어요. 서버는 서명을 확인한 뒤에만 권한을 반영해야 합니다.
헤더와 페이로드에 뭐를 담는 게 안전해요?
어느 쪽이든 서명되지 않는 한 조작이 가능합니다. 개인정보와 권한 정보는 서명된 서버 발급 토큰에 담고, 클라이언트에는 식별자만 넘기는 편이 안전해요.
exp가 없으면 어떻게 되나요?
만료 기한이 없는 토큰이 됩니다. 일부 라이브러리는 exp가 없으면 토큰을 거부하니 서버 설정에 맞춰 확인하고, 무기한 방치는 피해야 합니다.
알아둘 경계값
- 서명 부분은 화면에 표시되지 않아요. 점 3개 중 앞의 2개만 해석되고 마지막은 버려져요.
- 13자리 밀리초 값을 만료 시각란에 그대로 입력하면 만료일이 수만 년 후로 표시돼요. 초 단위인지 확인하세요.
- 헤더와 내용이 JSON 형식이 아니면 오류로 표시돼요. 압축되거나 암호화된 토큰은 읽히지 않아요.
- 토큰 앞뒤 공백은 자동 제거되지만 중간 줄바꿈은 오류가 나요. 복사할 때 줄이 나뉘었는지 확인하세요.
- 한글과 특수문자는 UTF-8 기준으로 풀어요. 잘못 인코딩된 토큰은 글자가 깨져 표시돼요.
- 붙여넣은 토큰은 어디에도 전송되지 않지만 화면에 그대로 남으니 공용 기기에서는 탭을 닫으세요.
결과를 믿기 전 확인 목록
- 토큰이 점 2개로 3부분 구조인지 확인하세요.
- 헤더의 서명 방식 표기와 서버 설정이 같은지 확인하세요.
- 내용의 만료 시각이 현재보다 미래인지 확인하세요.
- 만료 시각의 시간대 기준을 서버와 맞췄는지 확인하세요.
- 발급자와 사용처 표시가 예상과 같은지 확인하세요.
- 내용의 권한 표기가 실제 역할과 같은지 확인하세요.
- 서명 검증은 서버에서 별도로 했는지 확인하세요.
- 내용에 민감한 개인정보가 없는지 미리 확인하세요.
- 디버깅 후 테스트 토큰을 파기했는지 확인하세요.
자주 묻는 질문
서명 검증도 하나요?
아니요. 내용 확인용이며 서명 검증은 서버에서 하세요.
서명이 유효한지도 알려주나요?
아니요. 내용만 디코딩해요. 서명 검증은 서버에서 비밀키로 해야 하며, 이 도구로는 확인할 수 없어요.