JWT 디코더·인코더 — JSON Web Token 디코딩, 검증, 서명

JWT의 헤더와 페이로드를 디코딩하고, 만료 시간을 알기 쉽게 확인하고, HS·RS·PS·ES 서명을 검증하거나 새 토큰에 서명하세요. 브라우저 밖으로 나가는 것은 없습니다.

토큰

헤더

{
  "alg": "HS256",
  "typ": "JWT"
}

페이로드

{
  "sub": "user_42",
  "name": "Ada Lovelace",
  "role": "admin",
  "iat": 1757320000,
  "exp": 1788856000
}

클레임

sub	주체	user_42
name		Ada Lovelace
role		admin
iat	발급 시각	1757320000
exp	만료	1788856000

서명 검증 (HS256)비밀 키가 Base64 / Base64URL로 인코딩됨

예시 토큰은 비밀 키 demo-secret-do-not-use로 서명되어 있습니다.

디코딩은 서명을 확인하지 않습니다. JWT는 누구나 읽을 수 있고, 발급자를 증명하는 것은 서명뿐입니다. HS* 토큰에는 공유 비밀 키가, RS*, PS*, ES*, EdDSA에는 발급자의 공개 키(PEM, 인증서, JWK 또는 /.well-known/jwks.json의 JWKS, kid로 매칭)가 필요합니다. 운영 환경의 비밀 키나 개인 키는 이 페이지를 포함해 어떤 웹 페이지에도 붙여 넣지 말고 테스트 키를 사용하세요.

토큰과 키는 WebCrypto로 브라우저에서 처리되며 어디에도 전송되지 않습니다. 그래도 붙여 넣은 운영 환경 토큰이나 키는 자격 증명으로 취급하세요. 모든 무료 도구 보기.

문제를 발견하셨거나 개선할 점이 있나요? 모든 메시지를 읽고 빠르게 고칩니다.

이 무료 JWT 디코더는 JSON Web Token의 헤더, 페이로드, 클레임을 보여 주고, exp, iat, nbf를 읽기 쉬운 날짜로 바꿔 유효한지 만료되었는지 명확히 알려 줍니다. 서명 검증(비밀 키를 쓰는 HMAC, 또는 공개 키·인증서·JWK를 쓰는 RSA, RSA-PSS, ECDSA, Ed25519)도 하고, 테스트용 새 토큰에 서명하는 인코더도 있습니다. 모든 작업은 브라우저에서 이루어집니다. 이 점은 다른 도구보다 여기서 더 중요합니다. 붙여 넣은 토큰은 실제로 쓰이는 자격 증명인 경우가 많고, 저희 서버를 포함해 누구의 서버로도 보내져서는 안 되기 때문입니다.

JWT는 점으로 구분된 세 개의 Base64URL 부분으로 이루어집니다. 알고리즘을 지정하는 헤더, 클레임을 담은 페이로드, 그리고 서명입니다. 앞의 두 부분은 암호화가 아니라 인코딩만 되어 있어 누구나 읽을 수 있습니다. 토큰을 누가 발급했고 변조되지 않았는지를 증명하는 것은 서명입니다. 따라서 디코딩한다고 해서 믿을 수 있는 것은 아니며, 이 페이지는 그 차이를 분명히 보여 줍니다.

사용 방법

토큰을 붙여 넣으세요. Authorization 헤더의 앞부분 “Bearer ”가 있어도 괜찮습니다. 자동으로 제거됩니다.
상태 줄을 확인하세요: 얼마나 더 유효한지, 언제부터 만료되었는지, 아직 유효하지 않은지 알려 줍니다.
페이로드와 클레임 표를 확인하세요. 시간 클레임은 원래의 Unix 초 값과 함께 현지 날짜로 표시됩니다.
검증하려면 키를 입력한 뒤 검증을 누르세요. HS256/384/512는 공유 비밀 키를, RS, PS, ES, EdDSA 토큰은 발급자의 공개 키를 PEM, 인증서, JWK 또는 JWKS 전체로 입력합니다(키는 토큰의 kid로 선택됩니다).
토큰을 만들려면 인코딩 및 서명으로 전환하고, 알고리즘을 고르고, 헤더와 페이로드 JSON을 편집한 뒤, 비밀 키를 입력하거나 PKCS#8 개인 키를 붙여 넣으세요(테스트 키 쌍을 생성해도 됩니다). 서명한 다음 디코더에서 열어 검증하세요.
버그 리포트나 테스트 픽스처에 필요하면 페이로드나 헤더를 정리된 JSON으로 복사하세요.

자주 묻는 질문

실제 토큰을 여기에 붙여 넣어도 안전한가요?

토큰은 브라우저의 JavaScript로 디코딩되며 전송되지 않습니다. 인터넷 연결을 끊어도 페이지는 계속 작동합니다. 그렇더라도 운영 환경 토큰은 비밀번호처럼 다루세요. 신뢰하지 않는 페이지에는 붙여 넣지 말고, 가능하면 수명이 짧은 테스트 토큰을 쓰세요.

비밀 키 없이도 페이로드를 읽을 수 있는 이유는 무엇인가요?

JWT는 암호화가 아니라 서명되기 때문입니다. 페이로드는 누구나 디코딩할 수 있는 Base64URL 인코딩 JSON입니다. 비밀 키(또는 개인 키)는 서명을 만들거나 검증할 때만 필요합니다. 암호화 버전인 JWE를 쓰지 않는 한 JWT 페이로드에 민감한 데이터를 넣지 마세요. 이 도구는 JWE를 디코딩하지 않습니다.

exp, iat, nbf는 무슨 뜻인가요?

초 단위 Unix 타임스탬프입니다. exp는 토큰이 만료되는 시각, iat는 발급된 시각, nbf(not before)는 토큰이 유효해지는 가장 이른 시각입니다. 검증하는 쪽은 exp 이후나 nbf 이전의 토큰을 거부해야 합니다. 여기의 상태 줄은 두 규칙을 모두 현재 시각에 적용합니다.

RS256이나 ES256 토큰은 어떻게 검증하나요?

개인 키가 아니라 발급자의 공개 키가 필요합니다. ID 공급자는 https://issuer/.well-known/jwks.json 같은 URL에 JWKS로 공개 키를 게시합니다(Auth0, Okta, Cognito, Azure AD, Google 모두 그렇습니다). JWKS 전체를 붙여 넣으면 토큰 헤더의 kid와 일치하는 키가 사용되며, JWK 하나, PEM 공개 키(BEGIN PUBLIC KEY), X.509 인증서를 붙여 넣어도 됩니다. 이 페이지는 직접 아무것도 가져오지 않으므로 브라우저에서 JWKS를 복사해 오세요.

여기서 JWT를 만들고 서명할 수 있나요?

네. 인코딩 및 서명은 헤더와 페이로드 JSON을 받아 HS256/384/512와 비밀 키로, 또는 RS, PS, ES, EdDSA와 PKCS#8 PEM 형식(BEGIN PRIVATE KEY)의 개인 키로 서명합니다. 예전 형식인 BEGIN RSA PRIVATE KEY 파일은 PKCS#1이므로 openssl pkcs8 -topk8 -nocrypt -in key.pem으로 변환하세요. 테스트 키만 쓰세요. 운영 환경 서명 키를 웹 페이지에 붙여 넣었다면 유출된 것으로 간주해야 합니다.

“alg: none”은 무슨 뜻이고 왜 경고하나요?

토큰에 서명이 없다고 선언하는 것입니다. 과거 일부 라이브러리는 이런 토큰을 유효하다고 받아들여 공격자가 어떤 페이로드든 위조할 수 있었습니다. 제대로 설정된 검증기는 alg none을 바로 거부합니다. 실제 시스템에서 이것을 발견했다면 단순한 호기심거리가 아니라 보안 취약점입니다.

JWT의 구조

헤더: {"alg":"HS256","typ":"JWT"}는 어떤 알고리즘으로 토큰에 서명했는지 검증기에 알려 줍니다. 페이로드: 클레임, 즉 발급자가 넣기로 한 내용과 검증기가 이해하는 등록 클레임(iss, sub, aud, exp, nbf, iat, jti)을 담은 JSON 객체입니다. 서명: base64url(header).base64url(payload)에 대한 HMAC 또는 디지털 서명입니다. 페이로드의 한 글자만 바꿔도 서명이 더 이상 일치하지 않으며, 바로 그것이 핵심입니다.

흔한 JWT 실수

• 서명을 검증하지 않고 페이로드를 믿거나, 서버가 기대하는 알고리즘이 아니라 토큰에 적힌 알고리즘으로 검증하는 것(알고리즘 혼동).

• 수명이 긴 액세스 토큰. exp는 짧게(몇 분에서 한 시간) 두고, 긴 세션에는 리프레시 토큰을 쓰세요.

• 페이로드에 개인 정보나 비밀 데이터를 넣는 것. 토큰을 가진 사람은 누구나 읽을 수 있습니다.

• XSS 위험이 조금이라도 있는 사이트에서 토큰을 localStorage에 저장하는 것. 브라우저 세션에는 httpOnly 쿠키가 더 안전합니다.

• aud와 iss 확인을 빠뜨리는 것. 한 서비스용으로 발급된 토큰을 다른 서비스에 재사용할 수 있게 됩니다.

• 너무 짧거나 사람이 정한 HMAC 비밀 키. HS256에는 최소 256비트(무작위 32바이트)가 필요하며, 추측 가능한 비밀 키는 토큰 하나만으로도 오프라인 무차별 대입으로 알아낼 수 있습니다.

어떤 서명 알고리즘을 골라야 할까요?

• HS256 (HMAC-SHA256): 하나의 공유 비밀 키로 서명과 검증을 모두 합니다. 간단하고 빠르지만, 검증하는 모든 서비스가 토큰을 발급할 수도 있습니다. 백엔드 하나 안에서는 괜찮습니다.

• RS256 (SHA-256을 쓰는 RSA PKCS#1 v1.5): 가장 널리 지원되는 비대칭 방식입니다. 발급자가 개인 키를 보관하고, 나머지는 공개 키로 검증합니다. 2048비트 키에서 서명은 256바이트입니다.

• PS256 (RSA-PSS): RS256과 같은 키에 더 현대적인 패딩 방식을 씁니다. 모든 사용처가 지원할 때 쓰세요.

• ES256 (ECDSA P-256): 비슷한 보안 수준에 훨씬 작은 키와 64바이트 서명을 씁니다. 최신 시스템에서 흔하고 일부(Apple, WebAuthn 관련 API)에서는 필수입니다.

• EdDSA (Ed25519): 빠르고 결정적인 서명이며 라이브러리 지원이 늘고 있습니다. 브라우저 지원은 다른 알고리즘보다 늦게 도입되었습니다.