JWT 디코더
JSON Web Token을 붙여넣어 헤더와 페이로드를 읽고, 만료 시점을 확인하고, 모든 클레임을 이해하세요. 토큰은 브라우저 밖으로 나가지 않습니다.
브라우저에서 실행가입 불필요업로드 없음
디코딩은 검증이 아닙니다. JWT의 헤더와 페이로드는 base64url로 인코딩되어 있을 뿐이므로 누구나 읽을 수 있습니다. 이 도구는 토큰이 주장하는 내용을 보여줄 뿐, 토큰이 진짜임을 증명하지 않습니다. 서명은 반드시 서버에서 검증하세요.
헤더
페이로드
클레임 설명
서명 검증(선택, HS256/HS384/HS512)
입력한 시크릿으로 HMAC 서명을 확인합니다(브라우저의 Web Crypto API 사용). 시크릿은 이 페이지 밖으로 나가지 않습니다. RSA/ECDSA 토큰은 발급자의 공개 키가 필요하므로 여기서는 검증하지 않습니다.
JWT 디코더 사용 방법
- 인코딩된 토큰 입력란에 토큰을 붙여넣습니다. Authorization 헤더의 앞부분
Bearer는 무시됩니다. - 헤더와 페이로드가 즉시 디코딩되어 포맷된 JSON으로 표시됩니다.
- 클레임 설명 표를 확인합니다.
exp,iat,nbf는 “만료까지 남은 시간” / “만료된 지 지난 시간”과 함께 날짜로 변환됩니다. - 상태 표시줄에서 만료 문제를, 경고에서
alg: none같은 위험한 설정을 확인합니다. - 필요하면 공유 시크릿을 입력해 HS256, HS384, HS512 서명을 로컬에서 검증합니다.
JWT 안에는 무엇이 들어 있나요?
JSON Web Token(RFC 7519)은 세 개의 base64url 문자열을 점으로 이은 header.payload.signature 형태입니다. 헤더는 서명 알고리즘(alg)과 토큰 유형을 나타냅니다. 페이로드에는 사용자가 누구인지, 토큰이 언제 만료되는지 같은 클레임이 담깁니다. 서명은 앞의 두 부분을 시크릿이나 개인 키로 계산한 값입니다.
디코딩은 검증이 아닙니다
헤더와 페이로드는 암호화가 아니라 인코딩만 되어 있으므로 토큰을 가진 사람은 누구나 읽을 수 있습니다. 그래서 JWT 페이로드에 비밀번호나 비밀 정보를 넣으면 안 됩니다. 디코딩은 토큰이 무엇을 말하는지 알려 줄 뿐입니다. 서명 검증은 보통 API 서버에서 jose나 PyJWT 같은 라이브러리로 수행하며, 누가 발급했는지와 변조되지 않았음을 증명합니다. 서버는 exp, nbf, iss, aud도 확인하고 예상치 못한 알고리즘은 거부해야 합니다.
등록된 클레임 요약
| 클레임 | 의미 |
|---|---|
iss | 발급자: 토큰을 만들고 서명한 주체 |
sub | 주체: 보통 사용자 ID |
aud | 대상: 토큰을 사용할 API |
exp | 만료 시각(Unix epoch 기준 초) |
nbf | 이 시각 이전에는 유효하지 않음 |
iat | 발급 시각 |
jti | 고유 토큰 ID, 폐기 목록에 유용 |
“token expired” 오류 디버깅
API가 갓 발급된 것처럼 보이는 토큰을 거부한다면 exp와 nbf를 서버 시계와 비교하세요. 기기 간 약간의 시계 오차는 흔하므로 대부분의 라이브러리는 30~60초의 여유를 둡니다. exp가 초 단위인지도 확인하세요. 밀리초 값은 흔한 버그이며 만료 시점을 수천 년 뒤로 만들어 버립니다.
자주 묻는 질문
운영 환경의 JWT를 여기에 붙여넣어도 안전한가요?
이 도구가 JWT 서명을 검증하나요?
토큰이 만료된 것으로 표시되는 이유는 무엇인가요?
exp 클레임이 컴퓨터 시계 기준으로 과거이기 때문입니다. 새 토큰을 요청하거나 리프레시 토큰으로 갱신하세요. 시간이 이상해 보인다면 시계 오차나 밀리초로 기록된 exp 값이 아닌지 확인하세요.JWT, JWS, JWE는 어떻게 다른가요?
alg “none”이 위험한 이유는 무엇인가요?
alg: none을 거부하고, 예상하는 특정 알고리즘만 허용해야 합니다.