JWT 디코더

JWT 토큰의 헤더·페이로드를 디코드하고 만료시각을 확인합니다.

Header

Payload

서명(signature)은 비밀키 없이는 검증할 수 없어 디코드만 합니다. 민감한 토큰은 입력하지 마세요(모든 처리는 브라우저에서만 이뤄집니다).

API가 401을 돌려주는데 원인을 모르겠을 때, 가장 먼저 확인할 것은 토큰이 만료되지 않았는지입니다. 그런데 JWT는 점(.)으로 나뉜 긴 문자열이라 눈으로는 아무것도 읽을 수 없습니다.

이 도구는 토큰을 붙여넣으면 그 안에 담긴 헤더와 페이로드를 JSON으로 풀어 보여주고, 만료 시각을 사람이 읽는 날짜로 알려 줍니다.

어떻게 계산되나요

JWT의 구조

JWT(JSON Web Token)는 점으로 구분된 세 덩어리로 이루어집니다.

헤더.페이로드.서명
xxxxx.yyyyy.zzzzz

부분	담긴 내용
헤더(Header)	서명 알고리즘(`alg`), 토큰 유형(`typ`)
페이로드(Payload)	사용자 식별자, 권한, 발급·만료 시각 등
서명(Signature)	앞의 두 부분이 위조되지 않았음을 보증하는 값

앞의 두 부분은 암호화가 아니라 Base64URL 인코딩입니다. 즉 누구나 열어 읽을 수 있습니다. 그래서 페이로드에 비밀번호나 주민번호 같은 민감정보를 넣으면 안 됩니다.

사용 방법

입력창에 xxxxx.yyyyy.zzzzz 형태의 토큰 전체를 붙여넣으면 헤더와 페이로드가 각각 JSON으로 표시되고, 만료 관련 값이 날짜로 함께 해석됩니다. 요청 헤더에서 복사했다면 앞의 Bearer 부분은 빼고 토큰만 넣으세요.

자주 보는 표준 클레임

exp — 만료 시각(초 단위 Unix 타임스탬프). 이 시각이 지나면 서버가 토큰을 거부합니다
iat — 발급 시각
sub — 토큰이 가리키는 대상(보통 사용자 ID)
iss / aud — 발급자 / 대상 서비스

중요한 한계: 이 도구는 내용을 풀어 보여줄 뿐 서명을 검증하지 않습니다. 서명 검증에는 비밀키가 필요하고, 그 검증은 반드시 서버에서 이루어져야 합니다. 디코드가 잘 된다고 해서 유효한 토큰이라는 뜻은 아닙니다. 토큰은 그 자체가 로그인 자격이므로, 운영 중인 실제 토큰을 다룰 때는 취급에 주의하세요.

용어 정리

JWT: JSON Web Token. 인증 정보를 담아 주고받는 표준 토큰 형식(RFC 7519).
클레임(Claim): 페이로드 안에 담긴 정보 한 조각. exp, iat, sub 등이 표준 클레임입니다.
Base64URL: URL에 넣어도 안전하도록 변형한 Base64 인코딩. 암호화가 아니라 단순 인코딩입니다.
exp: 만료 시각. 초 단위 Unix 타임스탬프로 저장되며, 이 시각이 지난 토큰은 거부됩니다.
Bearer 토큰: Authorization 헤더에 `Bearer <토큰>` 형태로 실어 보내는 인증 방식.
리프레시 토큰: 짧은 수명의 액세스 토큰을 새로 발급받기 위해 따로 보관하는 장수명 토큰.

자주 묻는 질문

JWT를 아무나 열어볼 수 있으면 위험한 것 아닌가요?

열어보는 것 자체는 설계상 가능한 일입니다. JWT가 지키는 것은 비밀 유지가 아니라 위·변조 방지이기 때문입니다. 내용을 바꾸면 서명이 맞지 않아 서버가 거부합니다. 따라서 남이 보면 곤란한 정보는 처음부터 페이로드에 넣지 않는 것이 원칙입니다.

이 도구가 토큰이 유효한지도 확인해 주나요?

아니요. 헤더와 페이로드를 풀어서 보여주고 만료 시각을 해석할 뿐, 서명 검증은 하지 않습니다. 서명 검증에는 발급 서버의 비밀키가 필요하며 반드시 서버 쪽에서 수행해야 합니다.

exp가 지났는데 왜 API가 계속 동작하나요?

서버가 만료를 검사하지 않도록 구현됐거나, 실제로는 다른 토큰을 쓰고 있을 수 있습니다. 서버와 클라이언트의 시스템 시각이 어긋나 있는 경우도 있습니다. 만료 검증은 서버에서 반드시 수행해야 하는 항목입니다.

"Invalid token" 오류가 나는데 디코드는 잘 됩니다.

디코드는 서명과 무관하게 되기 때문에 정상적인 상황입니다. 비밀키가 바뀌었거나, 알고리즘 설정이 다르거나, 토큰을 복사할 때 앞뒤 공백·줄바꿈이 섞였을 가능성을 확인해 보세요.

JWT를 어디에 저장하는 것이 안전한가요?

정답이 하나로 정해져 있지는 않습니다. 브라우저 저장소에 두면 스크립트 공격에, 쿠키에 두면 요청 위조에 각각 노출될 수 있어 서비스 구조에 맞는 대비가 필요합니다. 만료 시간을 짧게 두고 리프레시 토큰을 분리하는 방식이 널리 쓰입니다.