Skip to content

JWT 인코더 (JWT Encoder)

무료 온라인 JWT 생성기·인코더. 헤더와 페이로드를 구성하고 HS256, RS256, ES256으로 즉시 서명. 100% 브라우저 기반 — 비밀 키와 개인 키가 기기를 떠나지 않음.

트래킹 없음 브라우저 실행 무료
페이로드 (클레임)
등록된 클레임 삽입:
비밀
브라우저에서 로컬로 서명됨 — 비밀과 개인 키가 기기를 떠나지 않습니다.
RFC 7515/7518 서명 동작을 따르며 출력을 독립적인 공개 키 검증자로 교차 검증 — Go Tools 보안 팀 · Jun 11, 2026

JWT 인코더란 무엇인가요?

JWT 인코더는 헤더와 클레임 페이로드로부터 JSON Web Token을 구성하고 암호학적으로 서명합니다. RFC 7519에 정의된 JWT는 점으로 연결된 세 개의 Base64URL 인코딩된 부분입니다: header.payload.signature. 헤더는 서명 알고리즘을 지정하고, 페이로드는 클레임(토큰이 누구에 대한 것인지, 무엇을 할 수 있는지, 언제 만료되는지)을 담으며, 서명은 비밀이나 개인 키로 헤더와 페이로드에 대해 계산된 암호학적 증거로 수신자가 변조를 탐지할 수 있게 해줍니다.

"JSON Web Token(JWT)은 HTTP Authorization 헤더나 URI 쿼리 매개변수처럼 공간이 제한된 환경을 위한 간결한 클레임 표현 형식입니다." — RFC 7519, Section 1

인코딩은 디코딩의 역방향입니다. JWT 디코더는 기존 토큰의 클레임을 읽고, 인코더는 사용자가 제공한 클레임을 받아 완전히 새로운 서명된 토큰을 만듭니다. 서명 단계가 바로 진짜 JWT와 임의의 Base64를 구분 짓는 지점입니다 — 유효한 서명 없이는 어떤 검증자도 토큰을 받아들이지 않습니다. 이 도구는 브라우저의 네이티브 Web Crypto API를 사용해 HMAC(HS), RSA(RS, PS), ECDSA(ES) 계열로 서명하므로, 전체 작업이 의존성 없이, 네트워크 호출 없이 기기에서 일어납니다.

개발자는 JWT 인코더를 끊임없이 찾습니다. 보호된 API 엔드포인트를 점검할 토큰을 발급하거나, 버그를 디버깅하기 위해 OAuth 서버가 발급하는 정확한 클레임 형태를 재현하거나, 통합 테스트용 픽스처를 만들거나, curl 명령에 바로 쓸 수 있는 Bearer 토큰을 팀원에게 건네줄 때입니다. 페이로드는 인코딩된 것이지 암호화된 것이 아니므로 JWT는 네트워크 상에서 전달하기에는 안전하지만 비밀을 담아서는 안 됩니다 — 토큰을 가진 누구나 모든 클레임을 읽을 수 있고, 오직 서명만이 그것을 바꾸지 못하게 막습니다.

JWT 작업은 다른 개발 도구와 자연스럽게 어울립니다. 서명한 뒤 토큰을 디코딩해 클레임을 확인하거나, exp와 iat를 Unix 시간과 사람이 읽는 날짜 사이에서 변환하거나, HS256의 HMAC이 기반으로 하는 해시 함수가 필요할 때 SHA-256 해시를 계산할 수 있습니다. 모든 JWT 세그먼트가 Base64URL로 인코딩되므로 토큰을 수동으로 살펴볼 때 Base64 도구가 유용합니다. 인코딩을 더 깊이 살펴보려면 Base64 기초 가이드를 참고하세요.

// Sign a JWT in the browser with the Web Crypto API (HS256)
async function encodeJwt(payload, secret) {
  const b64url = (bytes) =>
    btoa(String.fromCharCode(...new Uint8Array(bytes)))
      .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
  const enc = (obj) =>
    b64url(new TextEncoder().encode(JSON.stringify(obj)));

  const header = { alg: 'HS256', typ: 'JWT' };
  const signingInput = `${enc(header)}.${enc(payload)}`;

  const key = await crypto.subtle.importKey(
    'raw', new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']);
  const sig = await crypto.subtle.sign(
    'HMAC', key, new TextEncoder().encode(signingInput));

  return `${signingInput}.${b64url(sig)}`;
}

const token = await encodeJwt({ sub: 'user_123', exp: 1999999999 }, 'my-secret');
// → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsImV4cCI6MTk5OTk5OTk5OX0....

주요 기능

JWT 즉시 생성 및 서명

페이로드를 편집하면 서명된 토큰이 실시간으로 갱신됩니다 — 헤더, 페이로드, 서명이 그 자리에서 계산됩니다. Generate 버튼도, 서버 왕복도 없습니다.

전체 알고리즘 지원

HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512로 서명합니다 — 모든 흔한 JWS 계열을 브라우저의 네이티브 Web Crypto API로 처리합니다.

키가 기기를 떠나지 않음

비밀과 PKCS8 개인 키는 전적으로 브라우저 안에서 사용됩니다. 어떤 것도 업로드, 로깅, 저장되지 않아 개발과 장애 대응에 안전합니다.

빠른 클레임 도우미

iss, sub, aud, iat, nbf, 한 시간짜리 exp를 클릭 한 번으로 삽입합니다 — 수동 Unix 타임스탬프도, 문법 실수도 없습니다.

색상 구분 출력

서명된 토큰이 헤더·페이로드·서명으로 구분되고 각기 다른 색으로 표시되어, 구조가 한눈에 분명하고 복사하기 쉽습니다.

의존성 없음

브라우저의 Web Crypto API와 JSON에만 기반합니다 — 외부 라이브러리도, 원격 측정도, 어떤 종류의 네트워크 호출도 없습니다.

예시

HS256 세션 토큰

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1715000000,
  "exp": 1999999999
}
secret: a-string-secret-at-least-256-bits-long
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNTAwMDAwMCwiZXhwIjoxOTk5OTk5OTk5fQ.<HMAC-SHA256 signature>

공유 비밀로 서명된 HMAC-SHA256 토큰으로, 무상태 세션 인증에서 가장 흔한 구성입니다. 같은 비밀을 가진 누구나 이를 검증할 수 있습니다.

RS256 액세스 토큰

{
  "iss": "https://auth.example.com",
  "aud": "api.example.com",
  "sub": "90087165",
  "scope": "read:user write:post",
  "iat": 1715000000,
  "exp": 1999999999
}
private key: -----BEGIN PRIVATE KEY----- (PKCS8)
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS5jb20iLCJhdWQiOiJhcGkuZXhhbXBsZS5jb20iLCJzdWIiOiI5MDA4NzE2NSIsInNjb3BlIjoicmVhZDp1c2VyIHdyaXRlOnBvc3QiLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OX0.<RSA signature>

RSA로 서명된 OAuth 스타일 액세스 토큰입니다. 토큰은 개인 키로 서명되고 짝이 되는 공개 키를 가진 누구나 검증할 수 있어, 검증자가 토큰을 발급할 수 없어야 할 때 이상적입니다.

ES256 컴팩트 토큰

{
  "sub": "device-42",
  "iat": 1715000000,
  "exp": 1999999999
}
private key: -----BEGIN PRIVATE KEY----- (P-256)
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZXZpY2UtNDIiLCJpYXQiOjE3MTUwMDAwMDAsImV4cCI6MTk5OTk5OTk5OX0.<ECDSA P-256 signature>

P-256 곡선의 ECDSA 토큰입니다. ES256 서명은 동등한 보안을 제공하면서도 RSA보다 훨씬 짧아 제약이 많은 환경에서도 토큰을 작게 유지합니다.

사용 방법

  1. 1

    페이로드 클레임 편집하기

    토큰에 필요한 클레임을 페이로드 에디터에 JSON으로 작성하세요. 빠른 클레임 칩으로 iss, sub, aud, iat, nbf, 한 시간짜리 exp를 타임스탬프 입력 없이 삽입할 수 있습니다.

  2. 2

    알고리즘 선택 후 키 입력하기

    서명 알고리즘을 고르세요. HS256/384/512는 비밀을 입력하고, RS·PS·ES 알고리즘은 PKCS8 PEM 개인 키를 붙여넣습니다. 입력하는 동안 토큰이 로컬에서 서명됩니다.

  3. 3

    서명된 JWT 복사하기

    서명된 토큰이 세그먼트별로 색상 구분되어 즉시 나타납니다. Copy를 눌러 Authorization 헤더, curl 명령, 테스트에 넣으세요. 키는 브라우저를 떠난 적이 없습니다.

Common Errors

약한 HMAC 비밀 사용

HS256 보안은 전적으로 비밀의 엔트로피에 달려 있습니다. 짧거나 추측 가능한 비밀은 공격자가 무차별 대입해 토큰을 위조하게 합니다. 최소 256비트의 무작위성을 사용하세요.

✗ 오류
secret: "password123"  // guessable, low entropy
✓ 정상
secret: base64(crypto.randomBytes(32))  // >=256 random bits

exp 클레임 누락

exp가 없는 토큰은 절대 만료되지 않습니다. 유출되면 자연스러운 폐기 시점이 없어집니다. 항상 토큰 유형에 맞는 만료를 설정하세요.

✗ 오류
{ "sub": "user_123", "role": "admin" }  // no exp
✓ 정상
{ "sub": "user_123", "role": "admin", "exp": 1715003600 }

PKCS8 대신 PKCS1 키 붙여넣기

Web Crypto API는 PKCS8 개인 키만 가져올 수 있습니다. 전통적인 RSA PKCS1 키는 가져오기에 실패하므로 먼저 변환하세요.

✗ 오류
-----BEGIN RSA PRIVATE KEY-----  // PKCS1, not supported
✓ 정상
openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem

주요 사용 사례

API 테스트용 토큰 생성
HS256 Bearer 토큰을 몇 초 만에 생성해 curl, Postman, 통합 테스트에서 보호된 엔드포인트를 점검하세요.
OAuth 및 OIDC 토큰 재현
인가 서버가 발급하는 것과 같은 RS256 또는 ES256 토큰을 만들어 클레임과 audience 불일치를 디버깅하세요.
테스트 픽스처 생성
전체 인증 서버를 띄우지 않고도 단위·통합 테스트용 결정론적 서명 토큰을 생성하세요.
인가 실패 디버깅
고객의 토큰 형태 — 발급자, audience, scope, 만료 — 를 재현해 백엔드가 거부하는 이유를 찾으세요.
검증자 검사
알려진 키로 토큰을 서명해 검증 미들웨어가 유효한 토큰은 받아들이고 변조된 토큰은 거부하는지 확인하세요.
인증 플로우 프로토타이핑
새 로그인, 마이크로서비스, 서비스 간 호출을 연결하는 동안 팀원에게 바로 쓸 수 있는 토큰을 건네주세요.

기술 세부 사항

RFC 7519 / 7515 / 7518 준수
RFC 7519(JWT), RFC 7515(JWS), RFC 7518(JWA)을 따르는 JWS 토큰을 생성하며, 헤더에 등록된 알고리즘 식별자를 담습니다.
네이티브 Web Crypto 서명
HMAC, RSASSA-PKCS1-v1_5, RSA-PSS, ECDSA에 대해 crypto.subtle로 서명합니다. ECDSA 서명은 JWS 요구 사항대로 원시 r||s 형식으로 출력됩니다.
Base64URL, 의존성 없음
헤더와 페이로드는 URL-안전 알파벳(RFC 4648)으로 패딩 없이 Base64URL 인코딩됩니다. 외부 라이브러리도, 네트워크 호출도, 원격 측정도 없습니다.

모범 사례

항상 만료 설정하기
exp 클레임을 포함해 유출된 토큰이 더 이상 유효하지 않게 하세요. 짧은 수명은 피해 범위를 줄입니다 — 액세스 토큰은 며칠이 아니라 몇 분 단위로.
페이로드에 비밀 넣지 않기
JWT 페이로드는 토큰을 가진 누구나 읽을 수 있습니다. 식별자와 scope는 넣되, 비밀번호, API 키, 전체 PII는 절대 넣지 마세요.
운영 환경에서는 서버 측 서명
이 도구는 테스트와 디버깅용으로 사용하세요. 실제 시스템에서는 유지 관리되는 라이브러리와 시크릿 매니저의 키로 서버에서 토큰을 서명하세요.

자주 묻는 질문

JWT는 어떻게 온라인에서 생성하나요?
위 입력란에서 페이로드 JSON을 편집하고, 서명 알고리즘을 선택한 뒤(HS256이 기본값이며 비밀만 필요합니다), 비밀을 입력하거나 PKCS8 PEM 개인 키를 붙여넣으세요. 서명된 토큰이 즉시 나타나며, 헤더·페이로드·서명 세그먼트가 색상으로 구분되어 한 번의 클릭으로 전체를 복사할 수 있습니다. 서명은 네이티브 Web Crypto API를 사용해 전적으로 브라우저에서 실행됩니다 — 기다릴 Generate 버튼도, 서버 요청도 없으므로 개발 중 실제 키로 토큰을 서명해도 안전합니다.
JWT 생성기란 무엇인가요?
JWT 생성기는 헤더와 클레임 페이로드로부터 JSON Web Token을 구성하고 암호학적으로 서명하여, Bearer 토큰으로 사용할 수 있는 header.payload.signature 문자열을 만드는 도구입니다. JWT 디코더의 역방향입니다. 기존 토큰을 읽는 대신, 비밀(HS256)이나 개인 키(RS256/ES256)로 서명된 새 토큰을 생성합니다. 이 생성기는 전적으로 브라우저에서 실행되므로 토큰이 즉시 만들어지고 서명 키가 기기를 떠나지 않습니다.
이 JWT 생성기는 무료이고 사용해도 안전한가요?
네 — 완전히 무료이며, 가입도, 광고도, 추적도 없습니다. 모든 서명이 Web Crypto API를 통해 브라우저에서 로컬로 이루어지기 때문에 안전합니다. 페이로드, 비밀, 개인 키는 절대 업로드되거나 로깅되거나 저장되지 않으며, 이 도구는 어떤 네트워크 요청도 하지 않습니다. 그래서 민감한 키를 다룰 때도 적합하지만, 일회용 테스트 키를 사용하는 것이 언제나 가장 안전한 습관입니다.
여기에 제 비밀이나 개인 키를 입력해도 안전한가요?
네. 서명은 브라우저에서 로컬로 이루어집니다. 비밀과 개인 키는 서버로 전송되거나, 로깅되거나, 저장되거나, 분석에 사용되지 않습니다. 쿠키도 없고 추적도 없습니다. JWT 서명 키는 유효한 자격 증명을 발급할 수 있기 때문에 이 점이 중요합니다 — 이를 원격 도구에 붙여넣는 것은 인증 시스템의 열쇠를 넘기는 것과 같습니다. 모든 것이 클라이언트 측에서 실행되므로 이 인코더는 운영 환경 키에도 안전하게 사용할 수 있지만, 그래도 가능하면 일회용 또는 테스트 키를 사용하는 것이 좋습니다.
HS256과 RS256의 차이는 무엇인가요?
HS256(HMAC-SHA256)은 하나의 공유 비밀로 서명과 검증을 모두 수행합니다. 간단하고 빠르지만, 토큰을 검증할 수 있는 모든 당사자가 토큰을 만들 수도 있으므로 비밀은 신뢰할 수 있는 서버에만 보관해야 합니다. RS256(RSA-SHA256)은 키 쌍을 사용합니다. 개인 키로 서명하고 다른 쪽은 공개 키로 검증합니다. 이렇게 하면 토큰을 위조할 수 있는 권한을 누구에게도 주지 않으면서 공개 키를 클라이언트 앱, 파트너 서비스, JWKS 엔드포인트에 자유롭게 배포할 수 있습니다. 대칭형 단일 소유 시스템에는 HS256을, 검증자가 토큰을 발급할 수 없어야 할 때는 RS256이나 ES256을 사용하세요.
이 JWT 인코더는 어떤 알고리즘을 지원하나요?
HS256, HS384, HS512(공유 비밀 기반 HMAC), RS256, RS384, RS512(RSA PKCS#1 v1.5), PS256, PS384, PS512(RSA-PSS), ES256, ES384, ES512(P-256, P-384, P-521 곡선의 ECDSA)로 서명합니다. 이들 모두 브라우저의 네이티브 Web Crypto API로 생성되므로, 서드파티 라이브러리가 없고 어떤 것도 기기 밖으로 나가지 않습니다. HMAC 알고리즘은 텍스트 또는 Base64 비밀을 받고, RSA와 ECDSA 계열은 PKCS8 PEM 개인 키를 받습니다.
exp(만료) 클레임은 어떻게 설정하나요?
페이로드에 초 단위 Unix 타임스탬프로 exp 클레임을 추가하세요 — 예를 들어 "exp": 1999999999입니다. 가장 빠른 방법은 페이로드 아래의 exp +1h 칩으로, 지금으로부터 한 시간 뒤의 만료를 삽입합니다. iat(발급 시각)와 nbf(not-before)도 같은 방식으로 추가할 수 있습니다. exp는 밀리초가 아니라 단위이며, 검증자가 자신의 시계와 비교하므로 너무 이른 거부를 피하려면 서버 시간을 동기화하세요. 사람이 읽는 날짜를 Unix 타임스탬프로 변환하려면 Unix 타임스탬프 변환기를 사용하세요.
RS256이나 ES256용 PKCS8 PEM 개인 키는 어떻게 얻나요?
RSA의 경우: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private.pem. ECDSA P-256의 경우: openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ec-private.pem. 두 명령 모두 -----BEGIN PRIVATE KEY-----로 시작하는 PKCS8 PEM 블록을 출력하며, 이는 이 도구가 기대하는 것과 정확히 일치합니다. 헤더와 푸터 줄을 포함해 블록 전체를 붙여넣으세요. 토큰 검증에 쓰이는 짝 공개 키는 openssl pkey -in private.pem -pubout으로 도출할 수 있습니다.
방금 생성한 토큰은 어떻게 검증하나요?
JWT 디코더에 붙여넣어 헤더와 페이로드가 예상대로 디코딩되는지 확인하세요. 서명을 검증하려면 올바른 키로 서버나 SDK를 사용하세요. Node.js에서는 jwt.verify(token, secretOrPublicKey, { algorithms: ['HS256'] }), Python에서는 PyJWT.decode(token, key, algorithms=['RS256']), Go에서는 jwt.Parse(token, keyFunc)입니다. 운영 환경에서는 절대 빈 알고리즘 목록이나 verify_signature=False로 검증하지 말고, 항상 기대하는 정확한 알고리즘을 고정하세요.
페이로드에는 무엇을 넣어야 하나요?
간결하게 유지하세요. RFC 7519의 등록된 클레임은 iss(발급자), sub(주체 — 보통 사용자 ID), aud(수신자), exp(만료), nbf(not before), iat(발급 시각), jti(토큰 ID)입니다. 이와 함께 role, scope, email 같은 애플리케이션 클레임을 추가할 수 있습니다. 페이로드에 비밀을 넣지 마세요 — JWT는 인코딩된 것이지 암호화된 것이 아니므로 토큰을 가진 누구나 모든 클레임을 읽을 수 있습니다. 토큰이 Authorization 헤더와 쿠키에 들어가도록 약 4 KB 미만으로 유지하세요.
JWT는 암호화되어 있나요?
아니요. 표준 서명 JWT(JWS)는 Base64URL로 인코딩된 것이지 암호화된 것이 아닙니다. 서명은 토큰이 변조되지 않았고 키를 가진 사람이 발급했음을 증명하지만, 헤더와 페이로드는 토큰을 가진 누구나 완전히 읽을 수 있습니다. 페이로드 자체를 기밀로 유지해야 한다면, 다른 형식인 JWE(암호화된 JWT)가 필요합니다. 이 도구는 인증과 인가 플로우의 대부분에 쓰이는 서명된 JWS 토큰을 생성합니다.
왜 제 RS256 또는 ES256 서명이 실패하나요?
가장 흔한 원인은 다음과 같습니다. (1) 키가 PKCS8 형식이 아닌 경우 — 전통적인 -----BEGIN RSA PRIVATE KEY-----(PKCS1) 키를 openssl pkcs8 -topk8 -nocrypt -in old.pem -out pkcs8.pem으로 변환하세요. (2) 곡선이 알고리즘과 맞지 않는 경우 — ES256은 P-256 키가, ES384는 P-384가, ES512는 P-521이 필요합니다. (3) 개인 키 대신 공개 키나 인증서를 붙여넣은 경우. (4) 키가 암호로 보호되어 있어 Web Crypto API가 직접 가져올 수 없는 경우. openssl pkey로 먼저 복호화한 뒤 암호화되지 않은 PKCS8 블록을 붙여넣으세요.
이 도구는 alg:none 서명 없는 토큰을 지원하나요?
아니요, 의도적으로 지원하지 않습니다. alg:none 토큰은 서명이 없어 누구나 위조할 수 있으며, 이는 대표적인 JWT 인증 우회 취약점의 근원입니다. 인코더의 본래 목적이 서명된 토큰을 만드는 것이므로 이 도구는 실제 서명 알고리즘만 제공합니다. 보안 연구를 위해 alg:none을 살펴보고 있다면, 헤더와 페이로드를 Base64URL로 인코딩하고 서명 세그먼트를 비워 직접 구성할 수 있습니다 — 토큰은 여전히 후행 점으로 끝납니다(header.payload.) — 하지만 운영 환경에서는 그런 토큰을 절대 수용해서는 안 됩니다.
코드로 JWT를 생성할 수도 있나요?
네. Node.js에서는 jsonwebtoken.sign(payload, secret, { algorithm: 'HS256', expiresIn: '1h' }). Python에서는 PyJWT로 jwt.encode(payload, key, algorithm='RS256'). Go에서는 jwt.NewWithClaims(jwt.SigningMethodES256, claims).SignedString(privateKey). 이 도구는 빠른 테스트, curl 요청, 픽스처용 토큰을 만드는 가장 빠른 방법입니다 — 다만 애플리케이션 코드에서는 토큰을 서버 측에서, 유지 관리되는 라이브러리와 시크릿 매니저에서 로드한 키로 생성해야 하며, 절대 하드코딩하지 마세요.