JWT 디코더는 JSON Web Token을 세 부분으로 나누고 색으로 구분해 보여 줍니다. 헤더는 빨강, 페이로드는 보라, 서명은 청록으로 표시되어 각 구간이 어디서 시작하는지 한눈에 보입니다. 그 아래에는 헤더와 페이로드가 포맷된 JSON으로, iss, sub, aud, jti, iat, nbf, exp 클레임 표가, 그리고 토큰이 얼마나 남았는지(1분 30초 후 만료) 또는 얼마 전에 만료되었는지를 알려 주는 큰 상태 줄이 나옵니다.
JWT는 점으로 이은 Base64URL 구간 세 개입니다. 앞의 두 구간은 평범한 JSON이어서 토큰을 가진 사람은 누구나 읽을 수 있고, 세 번째 구간은 발급자의 키로만 만들고 검증할 수 있는 서명입니다. 그래서 디코딩에는 비밀 값이 필요 없고 이 도구도 요구하지 않습니다. 서명 검증도 하지 않습니다. 디코딩된 결과는 토큰이 무엇을 주장하는지일 뿐, 그 주장을 믿어도 되는지는 알려 주지 않습니다.
토큰은 브라우저 탭 안에서 디코딩되며 이 도구가 서버로 전송하지 않고, 공유 링크에도 담기지 않습니다. 그렇다고 유효한 토큰을 붙여넣어도 안전해지는 것은 아닙니다. 아직 유효한 토큰은 본 사람이 그대로 쓸 수 있으므로, 만료된 토큰이나 테스트·스테이징 환경의 토큰을 쓰세요.
사용 방법
토큰 붙여넣기
쿠키, 요청, 로그, 테스트 데이터에서 점으로 이어진 세 구간 문자열을 복사해 붙여넣습니다. 앞에
Bearer나Authorization: Bearer가 있거나, 따옴표로 감싸져 있거나, 여러 줄로 나뉘어 있어도 자동으로 정리됩니다. 한도는 64KiB입니다.색으로 구분된 토큰 확인
입력하는 즉시 디코딩됩니다. 헤더, 페이로드, 서명이 서로 다른 색으로 표시되어 일부가 잘린 복사본이나 빠진 구간을 쉽게 알아볼 수 있습니다.
상태와 점검 결과 확인
상태 패널에
… 후 만료,… 전에 만료됨,… 후부터 유효가 1초마다 갱신되어 나옵니다. 아래 점검 목록은 서명 없는 토큰(alg가none), 빈 서명,alg누락, 밀리초로 적힌 시각 클레임, 키 위치를 가리키는 헤더를 알려 줍니다.클레임 읽기
클레임 표에 모든 클레임이 의미와 함께 나열됩니다.
iat,nbf,exp는 사용 중인 시간대의 날짜로 나오고 그 아래에 ISO 형식의 UTC 시각이 붙습니다. 각 카드의 복사 버튼으로 헤더나 페이로드 JSON을 복사할 수 있습니다.
작동 원리
JWT의 구조 (RFC 7519, RFC 7515)
서명된 JWT는 JWS 컴팩트 직렬화 형식인 BASE64URL(헤더) . BASE64URL(페이로드) . BASE64URL(서명)입니다. 헤더와 페이로드는 JSON 객체여야 하므로 배열이나 일반 문자열로 디코딩되는 구간은 어느 구간인지 알려 주는 메시지와 함께 거부됩니다. Base64URL은 RFC 4648 5절의 패딩 없는 URL 안전 알파벳이고 안의 텍스트는 UTF-8이라서 한글이나 악센트 문자로 된 이름도 제대로 표시됩니다.
구간이 다섯 개인 토큰은 서명된 JWT가 아니라 암호화된 토큰(JWE, RFC 7516)입니다. 키 없이는 페이로드를 읽을 수 없으며, 디코더는 막연한 오류 대신 그 사실을 알려 줍니다.
eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjMifQ . <서명 바이트>
헤더 페이로드 서명등록 클레임과 NumericDate
RFC 7519 4.1절이 등록 클레임을 정의합니다. 시각 클레임은 NumericDate 값으로, 1970-01-01T00:00:00Z 이후의 초 단위 정수이며 밀리초가 아닙니다. 13자리 숫자는 대부분 밀리초 타임스탬프를 잘못 넣은 경우이며 디코더가 경고합니다.
| 클레임 | 의미 | 값 형식 |
|---|---|---|
iss | 토큰 발급자 | 문자열 또는 URI |
sub | 대상(보통 사용자 ID) | 문자열 |
exp | 만료. 이 시각 이후에는 받아들이면 안 됨 | NumericDate(초) |
aud | 토큰을 받을 대상 | 문자열 또는 문자열 배열 |
nbf | 이 시각 이전에는 유효하지 않음 | NumericDate(초) |
iat | 토큰 발급 시각 | NumericDate(초) |
jti | 토큰 고유 ID | 문자열 |
디코딩은 검증이 아니며, 점검 항목의 의미
검증은 앞의 두 구간에 대해 발급자의 비밀 키나 공개 키로 서명을 다시 계산해 세 번째 구간과 비교한 다음, exp, nbf, iss, aud를 애플리케이션이 기대하는 값과 대조하는 과정입니다. 이 페이지는 그 어느 것도 하지 않습니다. 대신 검증을 불가능하게 하거나 위험하게 만드는 신호를 표시합니다. alg가 none인 토큰은 RFC 7519 6절의 보호되지 않은 JWT이며, 서버는 이를 신원 증명으로 받아들이면 안 됩니다. 토큰이 점으로 끝나면 서명이 비어 있다는 뜻이고, none 토큰이 이런 모양입니다.
헤더 매개변수 jku, jwk, x5u는 검증 키를 어디서 가져올지를 토큰이 직접 지정하게 합니다. 검증하는 쪽은 토큰이 정한 키 위치를 절대 신뢰하면 안 되므로 디코더가 이를 표시합니다. 만료 판정에서 exp는 포함하지 않는 경계입니다. exp가 가리키는 초가 되면 토큰은 이미 만료된 것입니다.
실제 예시
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjQxMDI0NDQ4MDB9.signature헤더: { "alg": "HS256", "typ": "JWT" }
페이로드: { "sub": "123", "role": "admin", "exp": 4102444800 }
exp: 2100-01-01T00:00:00.000Zexp 4102444800은 2100-01-01T00:00:00Z이므로 상태 줄이 그 날짜까지 남은 시간을 셉니다. 세 번째 구간 signature는 실제 서명이 아니며 검사하지도 않습니다.
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjIwMjYtMTAifQ.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJzdWIiOiJ1LTEwNDIiLCJhdWQiOlsiYXBpIiwid2ViIl0sIm5hbWUiOiLquYDrr7zspIAiLCJpYXQiOjE3MzU2ODk2MDAsIm5iZiI6MTczNTY4OTYwMCwiZXhwIjoxNzM1NjkzMjAwLCJzY29wZSI6InJlYWQ6b3JkZXJzIn0.c2lnbmF0dXJl헤더: { "alg": "RS256", "typ": "JWT", "kid": "2026-10" }
페이로드: { "iss": "https://auth.example.com", "sub": "u-1042", "aud": ["api", "web"], "name": "김민준", "iat": 1735689600, "nbf": 1735689600, "exp": 1735693200, "scope": "read:orders" }
iat 2025-01-01T00:00:00.000Z
nbf 2025-01-01T00:00:00.000Z
exp 2025-01-01T01:00:00.000Zexp는 iat보다 한 시간 뒤이므로 토큰 수명은 3,600초입니다. 그 시각은 이미 지났기 때문에 상태 줄은 … 전에 만료됨으로 표시되고 점검 목록에 만료 경고가 나옵니다.
Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMifQ.signature헤더: { "alg": "HS256" }
페이로드: { "sub": "123" }
점검: exp 클레임 없음Bearer 접두어는 자동으로 제거됩니다. 이 토큰에는 exp가 없어 상태 줄이 만료되지 않는 토큰이라고 알려 주며, 실제 토큰이라면 눈여겨볼 부분입니다.
eyJhbGciOiJub25lIn0.eyJzdWIiOiIxIn0.헤더: { "alg": "none" }
페이로드: { "sub": "1" }
점검: alg가 none, 서명이 비어 있음, exp 클레임 없음토큰이 점으로 끝나 서명이 비어 있습니다. 내용을 살펴볼 수 있도록 디코딩은 하되, 서버가 왜 이를 거부해야 하는지 설명하는 위험 경고 두 개가 나옵니다.
exp가 90초 뒤
exp가 3,725초 뒤
exp가 7,500초 전1분 30초 후 만료
1시간 2분 5초 후 만료
2시간 5분 전에 만료됨의미 있는 큰 단위만 보여 줍니다. 하루가 넘으면 가장 큰 두 단위만 표시하고, 페이지가 열려 있는 동안 1초마다 갱신됩니다.
자주 하는 실수
디코딩된 토큰이 믿을 수 있는 토큰은 아님
누구든
"role": "admin"이라고 적은 페이로드를 만들 수 있습니다. 올바른 키로 서버에서 서명을 검증해야만 발급자가 만든 토큰임이 증명됩니다. 이 도구는 서명을 검증하지 않습니다.초 단위이지 밀리초가 아님
exp와iat는 초 단위입니다. 날짜가 5만 년대처럼 나온다면 버그가 있는 코드가 밀리초로 값을 만든 것입니다. 디코더가 밀리초 경고를 표시하며, 검증기는 이 토큰을 수천 년간 유효한 것으로 취급할 수 있습니다.카운트다운은 내 컴퓨터의 시계를 기준으로 함
상태는
exp를 기기의 현재 시각과 비교합니다. 시계가 틀리면 판정도 틀리고, 서버는 보통 1분 안팎의 시계 오차를 허용하지만 이 화면은 허용하지 않습니다.유효한 토큰 붙여넣기
디코딩은 로컬에서 이루어지고 토큰이 링크에 담기지도 않지만, 아직 유효한 베어러 토큰은 가진 사람에게 접근 권한을 줍니다. 직접 통제하지 않는 페이지에는 운영 토큰을 붙여넣지 말고, 티켓이나 채팅에 공유한 토큰은 폐기하고 재발급하세요.
암호화된 토큰은 구조가 다름
JWE는 구간이 다섯 개이고 페이로드가 암호화되어 있어 여기서는 디코딩되지 않으며, 암호화된 토큰이라고 알려 줍니다. Base64URL JSON이 아닌 구간은 헤더인지 페이로드인지 구간 이름과 함께 표시됩니다.
자주 묻는 질문
이 디코더가 서명도 검증하나요?
아니요. 헤더와 페이로드를 디코딩할 뿐입니다. 검증에는 발급자의 비밀 키나 공개 키가 필요하며, 서버에서 검증된 라이브러리로 해야 합니다.
JWT가 어딘가로 전송되나요?
토큰은 브라우저 안에서 디코딩되며 이 도구가 서버로 전송하지 않고 공유 링크에도 담지 않습니다. 유효한 토큰은 자격 증명이므로 실제 사용 중인 토큰은 붙여넣지 않는 편이 안전합니다.
JWT 페이로드를 누구나 읽을 수 있는 이유는 무엇인가요?
페이로드는 암호화가 아니라 Base64URL로 인코딩되어 있습니다. JWT의 서명은 변조를 막기 위한 것이지 내용을 숨기기 위한 것이 아니므로 클레임에 비밀 값을 넣으면 안 됩니다.
exp, iat, nbf는 각각 무엇인가요?
exp는 이 시각 이후 토큰을 거부해야 하는 만료 시각, nbf는 이 시각 이전에는 받아들이면 안 되는 시각, iat는 발급 시각입니다. 모두 유닉스 에포크 이후의 초 단위이며, 도구는 각각을 사용 중인 시간대와 UTC 날짜로 보여 줍니다.
alg none에 경고가 뜨는 이유는 무엇인가요?
none은 토큰에 서명이 없다는 뜻이라 누구나 원하는 클레임으로 토큰을 위조할 수 있습니다. 실제로 이를 받아들인 서버에서 여러 취약점이 나왔습니다. 일부러 서명 없는 토큰을 요청한 경우가 아니라면 서버는 거부해야 합니다.
토큰이 잘못되었다고 나오는 이유는 무엇인가요?
구간 일부가 잘린 복사본이거나, 토큰 안에 불필요한 문자가 섞였거나, JSON 객체가 아닌 구간이 있거나, 점으로 나뉜 부분이 두 개뿐인 경우가 흔합니다. 앞의 Bearer 나 따옴표는 자동으로 처리됩니다.
더 깊이 읽기
- 10분 읽기JWT 구조와 안전한 디코딩: 헤더, 페이로드, 서명, 그리고 디코딩이 증명하지 못하는 것JSON Web Token은 점으로 이은 Base64URL 문자열 세 개입니다. 읽는 데는 몇 초면 되지만, 믿으려면 검증된 서명과 몇 가지 클레임 검사가 필요합니다.
- 7분 읽기Base64란 무엇인가: 비트 단위 인코딩 원리, 패딩, Base64URL, data: URI까지Base64는 바이트를 6비트 조각으로 다시 자르는 고정된 규칙으로, 바이너리를 텍스트 전용 통로에 실어 보내기 위한 것입니다. 비트 배치를 한 번 보고 나면 패딩, 크기 증가, URL 안전 변형이 모두 거기서 따라 나옵니다.
마지막 업데이트: