사용법
- 입력칸에 JWT를 붙여넣으면 바로 해석됩니다. 앞에
Bearer 가 붙어 있어도 자동으로 떼어냅니다.
- 입력 아래에 토큰이 헤더·페이로드·서명 세 부분으로 색을 나눠 표시됩니다.
- header와 payload 패널에서 정리된 JSON을 확인하고 각각 copy로 복사합니다.
- claims 표에서
exp, iat, nbf 같은 시간 값이 한국 시간(KST)과 "n시간 후/전"으로 풀이되고, 만료 여부(VALID / EXPIRED)가 표시됩니다.
- 구조를 먼저 보고 싶다면 sample로 10분 전에 발급되어 50분 뒤 만료되는 예시 토큰을 만들어 볼 수 있습니다.
JWT란?
JWT(JSON Web Token)는 로그인 정보나 권한을 담아 주고받는 토큰 형식입니다. xxxxx.yyyyy.zzzzz처럼 점으로 구분된 세 부분으로 이루어집니다.
- Header — 서명 알고리즘(
alg)과 토큰 타입(typ).
- Payload — 사용자 ID, 권한, 만료 시각 같은 클레임(claim).
- Signature — 헤더와 페이로드를 비밀키로 서명한 값. 위·변조를 막는 부분입니다.
헤더와 페이로드는 암호화가 아니라 URL-safe Base64로 인코딩만 되어 있어서, 키가 없어도 누구나 내용을 읽을 수 있습니다. 이 도구는 그 두 부분을 디코딩해 보여줍니다.
디코딩 예시
점(.)으로 나눈 앞 두 조각을 Base64URL로 디코딩하면 그대로 JSON이 나와요. 세 번째 조각(서명)은 해석하지 않아요.
입력 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwibmFtZSI6InNtaXRoIiwiaWF0IjoxNzU5NjIyNDAwLCJleHAiOjE3NTk2MjYwMDB9.(서명)
header {"alg": "HS256", "typ": "JWT"}
payload {"sub": "1234", "name": "smith", "iat": 1759622400, "exp": 1759626000}
iat 2025-10-05 09:00:00 KST
exp 2025-10-05 10:00:00 KST
ttl 3600초 (1시간)
헤더가 늘 eyJ로 시작하는 이유는 {"를 Base64로 바꾸면 eyJ가 되기 때문이에요.
광고
표준 클레임과 시간 해석
| 클레임 | 의미 | 표시 방식 |
|---|
iss / sub / aud | 발급자 / 주체 / 대상 | 값 그대로 |
iat | 발급 시각 | KST + 상대 시간 |
nbf | 이 시각 이전엔 무효 | 미래면 NOT YET |
exp | 만료 시각 | VALID / EXPIRED |
ttl | exp − iat | 초 · 시간 |
시간 클레임은 1970-01-01 UTC 기준 초 단위 Unix 타임스탬프입니다. 예를 들어 "exp": 1759622400은 2025-10-05 09:00:00 KST를 뜻합니다.
이 도구는 서명을 검증하지 않습니다. 디코딩이 된다고 해서 진짜 토큰이라는 뜻은 아니니, 인증 판단은 반드시 서버에서 하세요. 점이 다섯 개 조각인 암호화 토큰(JWE)은 키 없이 해석할 수 없습니다. 실서비스 토큰은 디코딩 후 바로 지우는 습관을 들이세요.
자주 묻는 질문
JWT 만료 시간 확인하는 방법은?
토큰을 붙여넣으면 claims 표의 exp 행에 만료 시각(KST)과 남은 시간이 나옵니다. 이미 지났다면 EXPIRED 표시와 함께 상단 메시지도 경고로 바뀝니다.
토큰을 여기 붙여넣어도 유출되지 않나요?
디코딩은 전부 브라우저에서 처리되고 토큰을 서버로 전송하지 않습니다. 그래도 유효한 운영 토큰은 화면 공유나 캡처에 노출되지 않도록 주의하세요.
페이로드에 비밀번호를 넣어도 되나요?
안 됩니다. 페이로드는 누구나 읽을 수 있는 Base64 데이터입니다. 민감한 정보는 넣지 말고, 필요하면 식별자만 담은 뒤 서버에서 조회하세요.
"3부분이어야 해요" 오류가 나요
복사 과정에서 토큰이 잘렸거나 다른 문자열이 섞인 경우입니다. 쿠키·헤더 값을 통째로 복사했다면 앞뒤의 따옴표나 세미콜론을 지워 보세요.
관련 도구
이 도구와 함께 보면 좋은 글
개발자 · 2026. 11. 3.NestJS durable 프로바이더 언제 쓰나, 테넌트 메모리와 점검표NestJS durable 프로바이더는 테넌트가 적고 고정일 때만 써요. 12.3.2 로 재 보니 테넌트 트리 하나가 3.4~19.5KB, 비durable 클래스 하나만 섞여도 재사용이 풀렸어요. 허용 목록·퇴출·큐 작업 설정과 점검 순서를 정리했어요.개발자 · 2026. 10. 27.스프링 시큐리티 JWT 리소스 서버 설정 판단표, 401·403 확인 순서스프링 시큐리티 리소스 서버는 기본값으로 aud 를 보지 않고, 만료 뒤 60초를 더 통과시키고, 7.x 부터 typ 이 at+jwt 인 토큰을 거절해요. 키 설정 판단표, 토큰 수명별 폐기 노출 시간과 갱신 부하, 직접 잰 디코드 비용, 401·403 확인 순서를 정리했어요.개발자 · 2026. 10. 5.URL-safe Base64(Base64URL) 차이와 패딩 = 복원, Incorrect padding 해결표준 Base64의 +, /, = 는 URL에서 공백·경로·구분자로 오해돼 토큰이 가끔 깨져요. Base64URL은 -와 _를 쓰고 패딩을 뺀 변형이에요. JS·Python·Java 변환 코드, Incorrect padding 같은 실제 에러 해결법을 정리했습니다.개발자 · 2026. 10. 5.JWT 구조와 서명 원리 — 헤더·페이로드·서명, HS256과 RS256 차이eyJ로 시작하는 JWT는 헤더.페이로드.서명 세 부분이고, 앞의 둘은 누구나 읽을 수 있는 Base64URL이에요. Node 내장 crypto로 HS256 토큰을 직접 만들고 검증해 보고, HS256·RS256·ES256의 토큰 길이와 속도를 실측해 비교했습니다.개발자 · 2026. 10. 5.JWT 보안 체크리스트 — alg none, 알고리즘 혼동, 토큰 저장 위치JWT 사고는 규격이 아니라 쓰는 방식에서 나요. verify 옵션으로 막히는 alg none·알고리즘 혼동을 재현하고, 약한 비밀 키가 얼마나 빨리 풀리는지 계산했어요. 키 관리, 페이로드, 저장 위치까지 10개 항목으로 정리했습니다.개발자 · 2026. 10. 5.Base64는 암호화가 아니다 — 인코딩·암호화·해시 차이와 올바른 사용법Base64는 키 없이 누구나 1초 만에 되돌리는 인코딩이라 비밀을 지켜 주지 못해요. 인코딩·암호화·해시의 차이를 Node 코드로 직접 비교하고, 비밀번호와 민감 데이터를 실제로 어떻게 저장해야 하는지 정리했습니다.