로그인이 자꾸 풀린다는 제보를 받으면 가장 먼저 확인할 것은 토큰의 exp 클레임입니다. JWT는 겉보기엔 알 수 없는 문자열이지만 실은 마침표로 구분된 세 부분(헤더·페이로드·서명)이고, 앞의 두 부분은 Base64URL로 인코딩되어 있을 뿐 암호화되어 있지 않습니다. 즉 누구든 열어서 내용을 읽을 수 있습니다.
이 도구는 토큰을 붙여넣으면 헤더와 페이로드를 읽기 좋은 JSON으로 풀어 주고, iat·nbf·exp 를 사람이 읽는 날짜로 바꿔 지금 유효한 토큰인지, 만료까지 얼마나 남았는지 계산해 보여 줍니다. HMAC 시크릿을 알고 있다면 브라우저의 Web Crypto API로 HS256/384/512 서명 검증까지 그 자리에서 할 수 있습니다.
사용 방법
- 토큰 붙여넣기 — 입력창에 JWT를 붙여넣습니다.
Bearer접두사가 붙어 있어도 자동으로 제거하므로 Authorization 헤더 값을 그대로 복사해도 됩니다. 형식이 맞으면 알고리즘·타입·만료 상태 배지가 즉시 나타납니다. - 만료 상태 확인 — 발급 시각(iat), 유효 시작(nbf), 만료 시각(exp) 카드에서 각각의 시각과 남은 시간을 확인합니다. 만료까지 1시간 미만이면 주황색, 이미 만료되었으면 빨간색으로 표시됩니다.
- 페이로드와 클레임 검토 — 헤더·페이로드 패널에서 전체 JSON을 확인하고, 아래 표준 클레임 표에서
iss·sub·aud·jti같은 등록 클레임의 의미와 값을 함께 봅니다. 각 패널의 복사 버튼으로 JSON만 따로 가져갈 수 있습니다. - 필요하면 서명 검증 — 서명 패널에 HMAC 시크릿을 입력하면 즉시 검증 결과가 표시됩니다. 시크릿은 브라우저 메모리에만 존재하며 전송되지 않습니다. 샘플 토큰의 시크릿은
your-256-bit-secret입니다.
자주 묻는 질문
JWT를 붙여넣어도 안전한가요?
이 도구는 100% 브라우저에서 동작하므로 토큰이 네트워크로 나가지 않습니다.
다만 일반론으로 말하면, 운영 환경의 유효한 액세스 토큰은 어떤 온라인 도구에도 붙여넣지 않는 것이 원칙입니다. 토큰 자체가 인증 수단이라 유출되면 그대로 계정 탈취로 이어집니다. 디버깅이 필요하다면 만료된 토큰이나 테스트 계정으로 발급한 토큰을 쓰고, 실수로 운영 토큰을 노출했다면 즉시 해당 세션을 무효화하고 서명 키를 교체하세요.
페이로드에 비밀번호나 개인정보를 넣어도 되나요?
안 됩니다. JWT의 페이로드는 암호화가 아니라 인코딩일 뿐입니다.
Base64URL은 누구나 되돌릴 수 있는 변환이므로, 토큰을 손에 넣은 사람은 페이로드 전체를 그대로 읽습니다. 서명은 '내용이 위조되지 않았음'만 보장하지 '내용을 숨김'을 보장하지 않습니다. 주민등록번호, 전화번호, 이메일 주소 같은 개인정보나 권한 판단에 쓰이지 않는 민감 데이터는 페이로드에서 빼고, 내부 식별자(sub)만 담은 뒤 나머지는 서버에서 조회하는 구조를 권합니다.
서명 검증이 '지원하지 않음'으로 나옵니다.
브라우저에서의 검증은 대칭키 방식인 HS256·HS384·HS512만 지원합니다.
RS256·ES256처럼 비대칭키를 쓰는 토큰은 검증에 공개키(JWK 또는 PEM)가 필요하고, 보통 발급 서버의 /.well-known/jwks.json 에서 받아와야 합니다. 이 도구는 외부 요청을 하지 않는 것을 원칙으로 하므로 해당 알고리즘의 검증은 제공하지 않습니다. 헤더·페이로드 디코딩과 만료 검사는 알고리즘과 무관하게 모두 동작합니다.
`alg: none` 토큰은 무엇인가요?
서명이 없는 토큰을 뜻하며, JWT 역사상 가장 유명한 취약점의 원인입니다.
공격자가 헤더의 alg 를 none 으로 바꾸고 서명 부분을 비우면, 검증 로직이 헤더 값을 그대로 믿는 구현에서는 위조 토큰이 통과해 버립니다. 서버는 반드시 기대하는 알고리즘을 코드에 고정하고 토큰 헤더의 alg 를 신뢰하지 않아야 합니다. 이 도구에서 alg: none 배지가 보이면 그 토큰을 만든 시스템을 점검할 필요가 있습니다.
알아두면 좋은 개념
JWT의 세 조각
JWT는 header.payload.signature 구조입니다. 헤더에는 서명 알고리즘(alg)과 타입(typ), 키 식별자(kid)가 들어갑니다. 페이로드에는 클레임이라 부르는 키-값 쌍이 담기고, 서명은 header.payload 문자열을 비밀키로 서명한 값입니다.
세 조각 모두 Base64URL로 인코딩됩니다. 일반 Base64와 달리 + 와 / 대신 - 와 _ 를 쓰고 끝의 = 패딩을 생략하는데, URL이나 HTTP 헤더에 그대로 실을 수 있게 하기 위해서입니다.
exp, iat, nbf — 시간 클레임 세 가지
iat(issued at)는 발급 시각, exp(expiration)는 만료 시각, nbf(not before)는 이 시각 전에는 유효하지 않다는 뜻입니다. 셋 다 1970년 1월 1일부터의 초 단위 Unix 타임스탬프입니다. JavaScript의 Date.now() 는 밀리초를 돌려주므로 1000으로 나눠 비교해야 하며, 이 단위 혼동이 실무에서 흔한 버그의 원인입니다.
서버 간 시계가 몇 초씩 어긋날 수 있으므로 검증 라이브러리들은 보통 clockTolerance 옵션으로 30초 내외의 허용 오차를 둡니다. 만료 직후 요청이 간헐적으로 실패한다면 이 설정을 먼저 확인하세요.
액세스 토큰과 리프레시 토큰
JWT는 한 번 발급하면 만료 전까지 서버에서 무효화하기 어렵습니다. 상태를 저장하지 않는다는 것이 장점인 동시에 약점입니다. 그래서 실무에서는 수명이 짧은 액세스 토큰(5~30분)과 수명이 긴 리프레시 토큰(며칠~몇 주)을 함께 씁니다.
액세스 토큰이 유출되어도 피해가 짧은 시간에 그치고, 리프레시 토큰은 서버 DB에 저장해 두어 로그아웃이나 계정 정지 시 즉시 폐기할 수 있습니다. 이 도구에서 exp 가 몇 달 뒤로 찍힌 액세스 토큰을 발견했다면 수명 정책을 다시 검토해 보는 것이 좋습니다.