CodeKitHub
인코딩 도구

JWT 디코더

마지막 업데이트:

JWT(JSON Web Token)를 붙여넣으면 헤더와 페이로드가 즉시 디코딩되어 보기 좋게 정리됩니다 — 만료 여부까지 함께 표시됩니다. 모든 처리는 브라우저 안에서 이루어지며 토큰은 어디로도 전송되지 않고, 서명 검증은 수행하지 않습니다(이 도구는 디코딩만 할 뿐 토큰이 진짜인지는 확인하지 않습니다).

Header

Payload

모든 디코딩은 브라우저에서 로컬로 처리되며, 서명 검증은 하지 않고, 토큰은 어디로도 전송되지 않습니다.

이 도구는 무엇인가요?

JWT(JSON Web Token)는 두 당사자 간에 클레임을 전달하는 데 쓰이는 압축된 URL-safe 문자열로, 가장 흔하게는 로그인 이후 인증 토큰으로 사용됩니다. 점(.)으로 구분된 세 부분으로 이루어져 있습니다: 헤더(알고리즘과 토큰 타입), 페이로드(실제 클레임 — 사용자 ID, 권한, 만료 시간 등), 서명(서버가 토큰이 변조되지 않았는지 검증하는 데 사용).

헤더와 페이로드는 단순히 Base64URL로 인코딩된 JSON일 뿐 암호화된 것이 아니므로, 비밀 키 없이도 누구나 디코딩해서 읽을 수 있습니다. 검증에 비밀 키가 필요한 것은 서명뿐입니다. 이 도구가 하는 일이 정확히 그것입니다 — 읽을 수 있는 부분을 디코딩해 정리된 JSON으로 보여줄 뿐, 서명 검증은 시도하지 않습니다.

JWT는 RFC 7519에서 표준화되어 있으며, 서명 계층(JWS)은 별도로 RFC 7515에 정의되어 있습니다 — exp, iat, sub, aud 같은 등록된 클레임의 정확한 목록이 필요할 때 참고하기 좋습니다.

왜 사용해야 할까요?

  • 헤더와 페이로드를 즉시 읽을 수 있는 JSON 형태로 정리 — 문자열을 직접 나누고 Base64를 손으로 디코딩할 필요가 없습니다.
  • 자동 만료 확인: 페이로드에 "exp" 클레임이 있으면 사람이 읽을 수 있는 날짜로 변환하고 만료 여부를 표시합니다.
  • 헤더와 페이로드를 각각 원클릭으로 복사할 수 있습니다.
  • 100% 클라이언트 사이드 — 토큰이 로컬에서만 디코딩되고 전송되지 않아, 운영 환경 토큰이라도 안전하게 사용할 수 있습니다.
  • 서명 검증은 수행하지도, 수행한다고 주장하지도 않습니다 — 이 도구는 디버깅·검사용이지 검증 도구가 아닙니다.

사용 방법

  1. JWT 전체 문자열(점으로 구분된 세 부분 모두 포함)을 입력창에 붙여넣으세요.
  2. 입력하는 즉시 헤더와 페이로드가 자동으로 디코딩됩니다.
  3. 토큰에 "exp" 클레임이 있다면 만료 정보 줄을 확인하세요 — 정확한 날짜와 만료 여부가 표시됩니다.
  4. 각 박스 아래 "Copy" 버튼을 눌러 해당 부분을 JSON으로 복사할 수 있습니다.

예시

입력

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6IkpvaG4gRG9lIiwiZXhwIjoxNzAwMDAwMDAwfQ.dQw4w9WgXcQ

결과

Header: {"alg": "HS256"}
Payload: {"sub": "1234", "name": "John Doe", "exp": 1700000000}

서명(세 번째 부분)은 절대 디코딩되거나 검사되지 않습니다 — 이는 서버 측에서 진위를 확인하는 데 쓰이는 불투명한 해시값입니다.

실전 활용 팁

  • "invalid token" 오류 디버깅: 먼저 페이로드를 디코딩해 "exp" 클레임을 확인하세요 — 만료된 토큰이 가장 흔한 원인인데, 오류 메시지만 봐서는 항상 명확하지 않습니다.
  • 타사 API 토큰의 실제 내용 확인: 많은 API가 겉보기엔 알 수 없는 문자열의 JWT를 액세스 토큰으로 반환합니다 — 여기서 디코딩해 내 연동이 실제로 어떤 스코프, 사용자 ID, 만료 시간을 받고 있는지 확인할 수 있습니다.
  • JWT는 암호화된 것이 아니라는 점을 항상 기억하세요: 개발 중 디코딩된 페이로드에서 이메일이나 내부 ID 같은 민감한 데이터가 보인다면, 그 데이터는 클라이언트가 읽지 못하도록 서버 쪽으로 옮겨야 한다는 신호입니다.

페이로드에서 자주 보이는 클레임

클레임의미
subSubject — 보통 이 토큰이 나타내는 사용자 ID
exp만료 시각(유닉스 타임스탬프) — 이 시각 이후로는 토큰이 무효
iat발급 시각 — 토큰이 생성된 시점
iss발급자 — 어떤 서비스/서버가 토큰을 발급했는지
aud대상 — 이 토큰이 사용되도록 의도된 서비스
role / roles / scope커스텀 클레임 — 사용자에게 부여된 권한이나 역할(JWT 표준에는 없지만 매우 흔하게 사용됨)

자주 묻는 질문

이 도구가 JWT 서명도 검증하나요?

아니요. 서명을 검증하려면 토큰을 서명할 때 사용된 비밀 키나 공개 키가 필요한데, 이는 발급 서버만 가지고 있습니다. 이 도구는 사람이 읽을 수 있는 부분인 헤더와 페이로드만 디코딩하므로, 별도의 키 없이도 클레임과 만료 시간을 확인할 수 있습니다.

실제 운영 환경의 JWT를 여기에 붙여넣어도 안전한가요?

디코딩은 전적으로 브라우저 안에서 자바스크립트로 처리되며, 토큰은 저희를 포함한 어떤 서버로도 전송되지 않습니다. 다만 토큰은 비밀번호처럼 다루는 것이 좋습니다 — 신뢰하지 않는 도구에는 붙여넣지 말고, 민감한 클레임이 포함된 디코딩 결과 스크린샷은 공유하지 않는 것이 안전합니다.

왜 비밀번호 없이도 누구나 내 JWT 페이로드를 읽을 수 있나요?

그것이 원래 설계입니다 — JWT의 헤더와 페이로드는 Base64URL로 인코딩된 것이지 암호화된 것이 아닙니다. 인코딩은 보안 수단이 아니라 JSON을 URL로 안전하게 전송하기 위한 형식 변환일 뿐입니다. 비밀번호나 카드번호 같은 민감 정보는 절대 JWT 페이로드에 직접 넣지 말고, 토큰을 가진 사람은 누구나 내용을 읽을 수 있다고 가정해야 합니다.

"exp" 클레임은 무엇이고 왜 중요한가요?

"exp"는 토큰의 만료 시각을 유닉스 타임스탬프(1970년 이후 경과 초)로 나타낸 것입니다. 서버는 이 시각이 지나면 JWT를 거부하고 클라이언트에게 재인증을 요구합니다. 이 도구는 이를 읽기 쉬운 날짜로 변환하고 이미 만료됐는지 표시해 주므로, "세션이 왜 갑자기 로그아웃됐지" 같은 문제를 디버깅할 때 유용합니다.

토큰에서 JSON 파싱 오류가 뜨는데 왜 그런가요?

문자열이 올바른 JWT 형식(점으로 구분된 정확히 세 부분)이 아니거나, 복사 과정에서 일부가 잘리거나 변형됐을 가능성이 큽니다. 흔한 원인은 토큰이 실수로 여러 줄에 나뉘어 복사됐거나 끝부분이 누락된 경우입니다.

관련 도구