JWT 디코더는 JSON Web Token(JWT) 문자열을 붙여넣으면 그 안에 담긴 헤더(Header)와 페이로드(Payload)를 사람이 읽을 수 있는 JSON으로 풀어서 보여 주는 개발자 도구입니다. JWT는 점(.)으로 구분된 Base64Url 문자열이라 눈으로는 내용을 알 수 없는데, 이 도구를 쓰면 어떤 알고리즘으로 서명됐는지(alg), 누가 발급했고(iss) 누구를 위한 토큰인지(sub), 언제 만료되는지(exp) 등을 즉시 확인할 수 있습니다.
웹·모바일 앱의 로그인 인증, API 접근 토큰, OAuth·OpenID Connect의 ID 토큰 등에서 JWT는 사실상 표준으로 쓰입니다. 개발 중에는 '이 토큰이 만료됐나', '권한 클레임이 제대로 들어갔나', '발급자가 우리 서버가 맞나'를 자주 확인해야 하는데, 매번 서버 로그를 뒤지거나 코드로 디코드하기보다 토큰을 붙여넣어 바로 내용을 보는 편이 훨씬 빠릅니다.
이 도구는 서명을 검증하지 않고 내용만 디코딩하며, 모든 처리는 여러분의 브라우저 안에서만 이뤄집니다. 아래에서는 JWT의 3부분 구조, Base64Url 인코딩, 표준 클레임의 의미, 그리고 서명이 무엇을 보장하는지까지 개념을 정리했습니다.
사용 방법
- 확인하려는 JWT 문자열 전체를 입력창에 붙여넣습니다. 보통 'eyJ...'로 시작하는 긴 문자열이며, 요청 헤더의 Authorization: Bearer 뒤에 오는 값이 이에 해당합니다.
- 입력 즉시 토큰이 점(.)을 기준으로 나뉘어 헤더와 페이로드가 각각 JSON으로 디코딩되어 표시됩니다.
- 헤더의 alg(서명 알고리즘)·typ(토큰 유형), 페이로드의 표준 클레임(iss·sub·exp 등)과 사용자 정의 클레임을 확인합니다. exp·iat·nbf 같은 유닉스 타임스탬프는 읽기 쉬운 날짜로도 해석해 줍니다.
- 형식이 올바르지 않으면(점으로 구분된 구조가 아니거나 Base64Url이 깨진 경우) 오류 메시지가 표시되므로, 토큰이 잘리거나 공백이 섞이지 않았는지 확인하세요.
JWT의 3부분 구조
JWT는 점(.)으로 구분된 세 부분, 즉 Header.Payload.Signature 형태로 이뤄집니다. 각 부분은 원본 JSON(또는 서명 바이트)을 Base64Url로 인코딩한 문자열이며, 서로 다른 색으로 표기되곤 합니다. 예를 들어 xxxxx.yyyyy.zzzzz에서 첫 번째가 헤더, 두 번째가 페이로드, 세 번째가 서명입니다.
| 부분 | 인코딩 전 내용 | 역할 |
|---|---|---|
| Header (헤더) | JSON: 서명 알고리즘·토큰 유형 | 이 토큰을 어떻게 검증하는지 알려 준다 (alg, typ) |
| Payload (페이로드) | JSON: 클레임(claims) 집합 | 토큰이 담고 있는 실제 정보 (사용자 ID, 만료 시각 등) |
| Signature (서명) | 헤더·페이로드를 비밀키로 서명한 바이트 | 토큰이 위·변조되지 않았음을 보장한다 |
이 도구가 검증하는 것과 하지 않는 것
JWT 디코더는 헤더와 페이로드만 디코딩해 보여 줍니다. 세 번째 서명 부분은 표시하지 않으며, 서명이 유효한지(비밀키로 맞게 서명됐는지)도 검사하지 않습니다. 서명 검증은 비밀키 또는 공개키가 필요하기 때문에, 실제 인증에서는 반드시 서버 측에서 검증해야 합니다.
Base64Url 인코딩이란
JWT의 각 부분은 일반 Base64가 아니라 Base64Url로 인코딩됩니다. JWT는 URL 쿼리스트링이나 HTTP 헤더에 그대로 실려 다니는 경우가 많은데, 일반 Base64가 쓰는 +, /, = 문자는 URL에서 특수한 의미를 가져 문제가 됩니다. 그래서 Base64Url은 이 문자들을 URL에 안전한 형태로 바꿉니다.
- + 는 - (하이픈)로, / 는 _ (밑줄)로 치환합니다.
- 끝의 패딩 문자 = 는 생략합니다.
- 그 결과 JWT는 영문 대소문자·숫자·하이픈·밑줄만으로 이뤄져 URL·헤더에 안전하게 실립니다.
인코딩은 암호화가 아닙니다
Base64Url은 사람이 읽기 어렵게 보일 뿐, 누구나 되돌려(디코드) 원문을 볼 수 있는 인코딩입니다. 암호화가 아니므로 데이터를 숨기지 못합니다. 이 점이 다음 페이로드 관련 주의사항의 핵심입니다.
표준 클레임(Registered Claims)
페이로드에 담기는 정보 하나하나를 클레임(claim)이라고 부릅니다. RFC 7519는 상호 운용성을 위해 자주 쓰이는 표준 클레임 이름을 정의해 두었습니다. 모두 선택 사항이지만, 이름과 의미가 정해져 있어 여러 시스템이 같은 방식으로 해석합니다. 아래는 대표적인 표준 클레임입니다.
| 클레임 | 이름 | 의미 |
|---|---|---|
| iss | Issuer | 토큰 발급자 (인증 서버 식별자) |
| sub | Subject | 토큰의 주체 (보통 사용자 ID) |
| aud | Audience | 토큰의 대상 수신자 (이 토큰을 쓸 서비스) |
| exp | Expiration Time | 만료 시각 (이 시각 이후 토큰 무효, 유닉스 타임) |
| nbf | Not Before | 이 시각 이전에는 토큰이 유효하지 않음 |
| iat | Issued At | 토큰 발급 시각 (유닉스 타임) |
| jti | JWT ID | 토큰 고유 식별자 (재사용·중복 방지) |
exp·iat·nbf는 유닉스 타임스탬프
exp·iat·nbf 값은 1970년 1월 1일부터 흐른 초 단위 숫자(유닉스 타임)로 저장됩니다. 예를 들어 1700000000 같은 숫자가 그대로 들어가며, 이 도구는 이런 값을 읽기 쉬운 날짜·시각으로 함께 표시해 만료 여부를 바로 판단할 수 있게 합니다.
서명은 무엇을 보장하나
세 번째 부분인 서명은 헤더와 페이로드를 합친 값을 비밀키(HMAC 방식) 또는 개인키(RSA·ECDSA 같은 공개키 방식)로 서명한 결과입니다. 헤더의 alg 필드가 어떤 알고리즘을 썼는지 알려 줍니다. 서명의 목적은 '이 토큰이 발급된 뒤 내용이 바뀌지 않았음'과 '정당한 발급자가 만들었음'을 보증하는 것입니다.
누군가 페이로드의 사용자 권한을 몰래 admin으로 바꾸면 서명과 내용이 어긋나므로, 서버가 서명을 검증할 때 위조를 잡아냅니다. 다만 서명은 내용을 숨기지는 않는다는 점이 중요합니다.
- HMAC(HS256 등): 발급·검증에 같은 비밀키를 공유하는 대칭키 방식.
- RSA·ECDSA(RS256·ES256 등): 개인키로 서명하고 공개키로 검증하는 비대칭키 방식. 검증자에게 공개키만 주면 되므로 분산 환경에 적합.
- alg가 none 인 토큰은 서명이 없는 것으로, 이를 그대로 신뢰하면 심각한 보안 취약점이 됩니다.
자주 묻는 질문
- 이 도구는 서명이 유효한지도 확인해 주나요?
- 아니요. 이 도구는 헤더와 페이로드를 디코딩해 내용만 보여 주며, 서명이 올바른지는 검증하지 않습니다. 서명 검증에는 발급 서버의 비밀키 또는 공개키가 필요하기 때문입니다. 실제 인증 처리에서는 반드시 서버가 서명을 검증해야 하고, 이 도구는 토큰 내용을 사람이 눈으로 확인하는 용도로 쓰세요.
- 붙여넣은 토큰이 외부로 전송되나요?
- 아니요. 입력한 JWT는 여러분의 브라우저 안에서만 디코딩되며 서버로 전송되지 않습니다. 그렇더라도 실제 인증에 쓰이는 유효한 토큰은 탈취 위험이 있으므로, 만료됐거나 테스트용이 아닌 실서비스 토큰은 되도록 공용 PC 등에서 취급하지 않는 것이 안전합니다.
- JWT 페이로드에 비밀번호 같은 민감정보를 넣어도 되나요?
- 안 됩니다. 페이로드는 Base64Url로 인코딩됐을 뿐 암호화되지 않아, 토큰을 가진 사람은 누구나 디코드해 내용을 읽을 수 있습니다. 따라서 비밀번호·주민등록번호·카드번호 같은 민감정보는 절대 페이로드에 담지 마세요. 서명은 내용을 숨기는 것이 아니라 위·변조를 막는 장치일 뿐입니다.
- 토큰이 만료됐는지 어떻게 아나요?
- 페이로드의 exp(Expiration Time) 클레임을 확인하면 됩니다. exp는 유닉스 타임스탬프(초)로 저장되며, 이 도구는 이를 읽기 쉬운 날짜로 함께 표시합니다. 현재 시각이 exp를 지났다면 만료된 토큰입니다. 다만 최종적인 만료 판정과 거부는 토큰을 검증하는 서버가 수행합니다.
- 'Invalid' 또는 형식 오류가 나요.
- JWT는 점(.)으로 구분된 최소 2개(헤더·페이로드) 부분이 있어야 하고 각 부분이 올바른 Base64Url이어야 합니다. 복사할 때 토큰이 잘렸거나, 앞뒤에 공백·줄바꿈이 섞였거나, Bearer 같은 접두어가 함께 붙은 경우 오류가 납니다. 순수한 토큰 문자열만 남기고 다시 붙여넣어 보세요.
- JWT와 세션(session)은 어떻게 다른가요?
- 전통적인 세션은 서버가 세션 정보를 저장하고 클라이언트에는 세션 ID만 줍니다. 반면 JWT는 필요한 정보를 토큰 자체에 담아 클라이언트가 들고 다니므로, 서버가 상태를 저장하지 않아도(stateless) 검증만으로 인증할 수 있습니다. 대신 발급된 JWT는 만료 전에 강제로 폐기하기 어렵다는 단점이 있어, 만료 시간을 짧게 두고 리프레시 토큰을 함께 쓰는 방식이 흔합니다.