JWT 인코더 (생성 및 서명)

헤더와 페이로드 JSON으로부터 HS256, HS384, HS512 중 하나로 HMAC 서명된 JWT(JSON Web Token)를 브라우저 안에서 생성합니다. 비밀 키를 포함한 입력 내용은 서버로 전송되지 않습니다.

마지막 업데이트: 2026-09-20

지원하는 HMAC 서명 알고리즘 목록

알고리즘	해시 함수	서명 길이	설명
HS256	SHA-256	256비트 (32바이트)	가장 널리 쓰이는 기본 HMAC 서명 방식으로, OAuth 2.0 및 OpenID Connect의 ID 토큰 등 많은 구현에서 표준으로 채택하고 있다.
HS384	SHA-384	384비트 (48바이트)	HS256보다 긴 서명으로 보안 여유를 높이고 싶을 때 사용하는 중간 단계의 선택지.
HS512	SHA-512	512비트 (64바이트)	가장 긴 서명 길이를 가지며, 충분히 긴 무작위 비밀 키와 함께 사용하는 경우가 많다.

JWT를 만들고 서명하기

이 도구는 헤더와 페이로드의 JSON에서 JWT를 그 자리에서 조립하며, HS256·HS384·HS512 가운데 하나로 HMAC 서명을 붙입니다. 비밀 키를 포함해 넣은 모든 것이 브라우저 안에서만 다뤄지며 서버로 보내지는 일은 없습니다.

**여기서 가장 자주 오해되는 점은, 서명이 위조를 알아채기 위한 장치이지 암호화가 아니라는 것입니다.** JWT의 헤더와 페이로드는 Base64URL로 부호화되어 있을 뿐이어서 **토큰을 손에 넣은 사람이라면 누구나 그 내용을 그대로 읽을 수 있습니다.** 비밀번호나 개인정보를 페이로드에 넣어서는 안 되는 까닭이 바로 이것입니다. 또 하나의 요점은 키의 성격으로, HS 계열은 **서명하는 쪽과 검증하는 쪽이 같은 비밀 키를 나눠 갖는** 방식입니다. 검증을 다른 곳에 맡기고 싶다면 비밀 키를 건네지 않아도 되는 RS256이나 ES256 같은 공개 키 방식을 고르게 됩니다.

만드는 순서

헤더의 JSON을 넣습니다 `{"alg":"HS256","typ":"JWT"}` 꼴입니다. 고른 알고리즘과 맞춰 주십시오.
페이로드의 JSON을 넣습니다 `sub`·`iat`·`exp` 등 필요한 클레임을 적습니다. **숨기고 싶은 값은 넣지 마십시오.**
서명 알고리즘을 고릅니다 HS256·HS384·HS512 가운데 고를 수 있으며, 숫자는 해시의 비트 길이입니다.
비밀 키를 넣어 토큰을 받습니다 점으로 이어진 세 부분의 문자열이 나옵니다.

더 잘 활용하기 위한 팁

생성된 JWT는 브라우저 내 Web Crypto API만으로 서명되며, 비밀 키를 포함한 입력 내용은 toolbase.cc 서버로 전송되지 않습니다.
서명 알고리즘(HS256/HS384/HS512)을 변경하면 헤더 JSON의 alg 필드가 자동으로 갱신됩니다. kid 등 다른 클레임을 추가하려면 헤더를 직접 편집하세요.
이 도구는 HMAC(대칭 키) 방식만 지원합니다. RS256, ES256과 같은 공개 키 방식의 서명이 필요하다면 Node.js 등 서버 사이드 라이브러리를 이용하세요.
헤더나 페이로드를 수정한 뒤에는 반드시 "JWT 생성"을 다시 눌러야 합니다. 누르기 전까지는 이전 입력 내용으로 생성된 오래된 JWT가 그대로 표시됩니다.
생성한 JWT의 내용을 바로 확인하고 싶다면 자매 도구인 JWT 디코더에 붙여넣어 헤더와 페이로드를 검증할 수 있습니다.

이럴 때 쓸 수 있습니다

API의 동작을 시험할 때

**원하는 클레임을 담은 토큰을 바로 찍어 낼 수 있어 인가 규칙의 갈래를 빠르게 훑을 수 있습니다.**

만료의 처리를 검증할 때

`exp`를 지난 시각으로 둔 토큰을 만들어 만료된 토큰이 제대로 막히는지 확인할 수 있습니다.

테스트용 토큰을 마련할 때

내용이 정해진 토큰을 만들어 자동 테스트의 픽스처로 삼을 수 있습니다.

JWT의 구조를 익힐 때

입력을 바꿔 가며 만들어 보면 어느 부분이 토큰의 어디에 놓이는지 눈으로 따라갈 수 있습니다.

JWT 용어

헤더: 알고리즘과 종류를 밝히는 첫 부분입니다. `alg`와 `typ`을 지닙니다.
페이로드: 클레임을 담은 두 번째 부분입니다. **Base64URL로 부호화되어 있을 뿐 암호화되어 있지는 않습니다.**
서명: 세 번째 부분으로, 헤더와 페이로드에서 키를 써서 계산합니다. **위조를 알아채기 위한 것이며 내용을 감추는 구실은 하지 않습니다.**
클레임: 페이로드에 담기는 각 항목입니다. 표준으로는 `sub`(주체)·`iat`(발행 시각)·`exp`(만료) 등이 있습니다.
HMAC: 공유 키를 쓰는 메시지 인증 방식입니다. **서명하는 쪽과 검증하는 쪽이 같은 키를 지녀야 합니다.**
Base64URL: URL에 담을 수 있도록 기호를 바꾼 Base64입니다. `+`와 `/`를 `-`와 `_`로 바꾸고 끝의 채움도 뺍니다.

자주 묻는 질문

아니요, 권장하지 않습니다. 서명 처리 자체는 브라우저 내에서 안전하게 이루어지지만, 비밀 키를 브라우저 도구에 입력하는 행위 자체가 운영 환경의 보안 방침상 바람직하지 않습니다. 이 도구는 API 개발 중 동작 확인이나 학습 목적을 위한 것입니다.

HS256은 송신자와 수신자가 같은 비밀 키를 공유하는 대칭 키 방식이고, RS256은 개인 키로 서명하고 공개 키로 검증하는 공개 키(비대칭 키) 방식입니다. 이 도구는 HS256·HS384·HS512의 HMAC 방식만 지원하며, RS256·ES256과 같은 공개 키 방식은 지원하지 않습니다.

네, 헤더 JSON은 직접 편집할 수 있습니다. 다만 선택한 알고리즘(실제 서명 계산에 사용되는 값)과 alg 필드 값이 일치하지 않으면, 다른 구현에서 이 JWT를 검증할 때 오류가 발생할 수 있으므로 두 값을 항상 일치시켜야 합니다.

생성된 JWT 문자열을 자매 도구인 "JWT 디코더"에 붙여넣으면 헤더와 페이로드 내용을 즉시 확인할 수 있습니다. 다만 서명 자체의 유효성은 같은 비밀 키를 가진 서버 측 검증 로직으로만 확실하게 확인할 수 있습니다.

여담 ― JWT 서명이 "브라우저만으로" 완결될 수 있는 이유

JWT 서명 알고리즘은 크게, 송신자와 수신자가 같은 비밀 키를 공유하는 "대칭 키 방식(HMAC, 즉 HS256/HS384/HS512)"과 개인 키로 서명하고 공개 키로 검증하는 "공개 키 암호 방식(RS256·ES256 등)"으로 나뉩니다. 전자는 W3C가 표준화한 Web Crypto API(SubtleCrypto)의 crypto.subtle.sign()을 사용하면 외부 라이브러리 없이 브라우저만으로 계산을 완결할 수 있기 때문에, 이 도구는 의도적으로 HMAC 방식만 지원하도록 범위를 좁혔습니다.

HMAC 서명의 안전성은 헤더나 페이로드의 내용이 아니라 비밀 키를 추측하기 어려운 정도에 전적으로 달려 있습니다. RFC 7518(JSON Web Algorithms)은 HS256의 경우 256비트(32바이트) 이상의 키 길이를 권장하고 있으며, 짧은 단어나 사전에 나올 법한 문자열을 비밀 키로 사용하면 무차별 대입 공격으로 서명이 위조될 위험이 있습니다. 실제 운영 환경에서는 난수 생성기로 만든 충분히 긴 무작위 문자열을 비밀 키로 사용해야 합니다.

이 도구는 API 개발 중 동작 확인이나 Webhook 서명 검증 로직 테스트를 위한 개발자용 유틸리티입니다. 입력한 비밀 키는 브라우저 메모리 내에서만 처리되며 외부로 전송되지 않지만, 공유 단말기나 브라우저 확장 프로그램이 클립보드나 입력 내용을 수집할 위험이 전혀 없는 것은 아닙니다. 동작 확인 목적이라 하더라도 실제 운영 환경에서 사용 중인 비밀 키를 이런 도구에 입력하지 않는 것을 강력히 권장합니다.

모든 여담 보기