본문으로 건너뛰기

JWT 디코딩 및 서명 검증

JSON Web Token의 헤더와 클레임을 디코딩하고 만료 시간과 서명을 확인해요. 토큰은 브라우저 밖으로 나가지 않아요.

이 탭에서 디코딩하고 검증해요. 토큰과 키는 어디에도 전송되지 않아요.

토큰을 붙여넣으면 헤더, 클레임, 만료 정보가 여기에 표시돼요.
브라우저에서 실행 · 업로드 없음작동 방식

JWT 디코더 사용 방법

  1. 1

    토큰 붙여넣기

    Authorization 헤더, 쿠키, 앱 저장소에서 가져온 JWT를 붙여넣으세요. 앞의 "Bearer "는 무시돼요.

  2. 2

    클레임 확인

    헤더와 페이로드 표, 읽기 쉽게 바뀐 exp, iat, nbf 시간, 만료 배너를 확인하세요.

  3. 3

    키 입력

    HMAC 시크릿을 입력하거나 공개 키를 PEM, 인증서, JWK, JWKS로 붙여넣으세요.

  4. 4

    서명 검증

    서명 검증을 누르면 토큰이 그 키로 서명됐는지, 변경되지 않았는지 확인할 수 있어요.

제한 및 Pro

회원가입 없이 무료이고 토큰 개수 제한도 없어요. 서명 검증은 13가지 알고리즘(256, 384, 512비트의 HS, RS, PS, ES와 EdDSA)을 지원해요.

Pro는 광고를 없애 줘요. 디코딩과 검증 기능은 어떤 요금제에서나 같아요. Pro 보기

JWT 디코더 소개

JSON Web Token(JWT)은 점으로 이어진 세 개의 Base64URL 문자열이에요. 서명 알고리즘을 알려 주는 헤더, 클레임이 담긴 페이로드, 그리고 서명으로 이루어져 있어요. 토큰을 붙여넣으면 "Bearer " 접두사가 있어도 없어도 헤더와 페이로드를 읽기 쉬운 표나 보기 좋게 정리된 JSON으로 보여 주고, 토큰의 세 부분을 색으로 구분해요. iss, sub, aud, kid, scope 같은 표준 필드는 설명도 함께 보여 줘요.

시간 클레임도 알아서 변환해요. exp, iat, nbf, auth_time은 내 시간대 날짜, UTC, 상대 시간("2시간 후 만료", "3일 전 만료")으로 표시돼요. 토큰이 만료됐는지, 아직 유효하지 않은지, 만료가 없는지는 배너로 바로 알 수 있고, exp가 초가 아니라 밀리초로 보이면 경고도 해 줘요.

디코딩만으로는 누가 발급한 토큰인지 알 수 없어요. 그래서 브라우저에 내장된 WebCrypto로 서명을 검증해요. HS256, HS384, HS512는 공유 시크릿(일반 텍스트 또는 Base64)이 필요해요. 256, 384, 512비트의 RS, PS, ES 알고리즘과 Ed25519를 쓰는 EdDSA는 공개 키가 필요한데, PEM 공개 키, RSA PUBLIC KEY 블록, X.509 인증서, JWK 하나, 또는 JWKS 전체를 붙여넣을 수 있어요. JWKS는 토큰의 kid로 키를 골라요.

다섯 부분으로 된 JWE 토큰은 복호화할 수 없고, JWKS URL을 대신 불러오지도 않아요. 발급자의 jwks_uri를 직접 열어 JSON을 붙여넣어 주세요.

개인정보 보호

토큰은 가진 사람이 곧 권한을 갖는 자격 증명이라서 이 페이지도 그렇게 다뤄요. 디코딩과 서명 검증은 브라우저의 WebCrypto로 처리하고, 토큰, 시크릿, 키는 서버로 전송되거나 기록되거나 저장되지 않아요. 탭을 닫거나 새로고침하면 모두 사라져요.

기능

읽기 쉬운 시간

exp, iat, nbf를 내 시간대, UTC, "2시간 후", "3일 전"으로 보여 줘요.

실제 서명 검증

HMAC, RSA, RSA-PSS, ECDSA, Ed25519를 WebCrypto로 내 키 또는 JWKS와 대조해 검증해요.

토큰은 기기에만

업로드되지 않아서 운영 환경 토큰도 안전하게 살펴볼 수 있어요.

JWT 디코더: 자주 묻는 질문

운영 환경 토큰을 여기에 붙여넣어도 안전한가요?
토큰은 탭에서 실행되는 JavaScript로 디코딩하고 검증하며, 토큰이 담긴 요청은 전송되지 않아요. 브라우저의 네트워크 패널에서 직접 확인할 수 있어요. 그래도 유효한 토큰은 만료될 때까지 비밀번호처럼 쓸 수 있으니, 믿을 수 없는 사이트에는 붙여넣지 마세요. 스크린샷을 공유할 때는 만료됐거나 테스트용인 토큰을 쓰는 게 좋아요.
디코딩만으로는 왜 아무것도 증명되지 않나요?
헤더와 페이로드는 누구나 만들어서 Base64URL로 인코딩할 수 있고, 디코딩은 그 과정을 되돌릴 뿐이에요. 토큰을 발급자와 연결해 주는 것은 서명뿐이에요. 클레임을 믿기 전에 발급자의 공개 키나 공유 시크릿으로 검증하고, alg가 서버가 기대하는 값인지도 확인하세요. "none"이나 바뀐 알고리즘을 받아들이는 것은 대표적인 취약점이에요.
RS256 또는 ES256 토큰을 검증할 공개 키는 어디서 찾나요?
ID 공급자는 보통 키를 JWK Set으로 공개해요. 발급자의 /.well-known/openid-configuration에서 jwks_uri를 찾아 열고, 그 JSON을 여기에 붙여넣으세요. 토큰 헤더의 kid와 일치하는 키가 사용돼요. PEM 공개 키나 발급자의 X.509 인증서를 붙여넣어도 돼요.
exp, iat, nbf는 무슨 뜻인가요?
1970년 1월 1일 UTC부터 초 단위로 센 NumericDate 클레임이에요. exp는 토큰이 효력을 잃는 시각, iat는 발급된 시각, nbf는 토큰을 받아들일 수 있는 가장 이른 시각이에요. 서버는 보통 1~2분 정도의 시계 오차를 허용해요. 디코더는 각 값을 로컬 날짜, UTC 타임스탬프, 상대 시간으로 보여 줘요.
HMAC 시크릿이 맞는데 왜 검증에 실패하나요?
시크릿을 복사할 때 공백이 함께 들어갔거나, 토큰을 서명할 때 시크릿이 Base64로 인코딩돼 있었거나, 어떤 도구가 토큰을 다시 인코딩하면서 헤더나 페이로드의 바이트가 바뀐 경우가 흔해요. "시크릿이 Base64로 인코딩됨" 스위치를 켜 보세요. 앞의 두 부분이 조금이라도 바뀌면, JSON 키 순서만 달라져도 서명은 무효가 돼요.