win-j 로고
개인 기술 블로그

Developer Utility

JWT 생성기

Header, Payload, Secret 값을 입력해 HS256 방식의 JWT 토큰을 생성하고, 토큰의 Header, Payload, Signature 구성을 한눈에 확인할 수 있습니다.

JWT 생성 Header와 Payload JSON을 입력해 테스트용 JWT 토큰을 생성할 수 있습니다.
HS256 지원 개발 테스트에 자주 사용하는 HMAC SHA-256 서명 방식을 지원합니다.
구조 확인 생성된 토큰을 Header, Payload, Signature 영역으로 분리해 확인할 수 있습니다.
Algorithm HS256
Header 대기
Payload 대기
Secret 대기

JWT 입력 정보

Header JSON, Payload JSON, Secret Key를 입력한 뒤 JWT를 생성하세요.

보안 안내

이 페이지는 개발 테스트용 HS256 서명 도구입니다. 운영 Secret Key·관리자 토큰을 입력하지 말고, Payload는 암호화되지 않아 누구나 읽을 수 있다는 점을 확인하세요.

Header 대기
Payload 대기
Secret 대기

RFC 7518 기준에 따라 HS256 키는 최소 32바이트가 필요합니다. 운영 비밀키는 서버의 안전한 키 관리 환경에서 생성·보관하세요.

자주 쓰는 Payload Claim
  • sub: 사용자 또는 대상 식별자
  • name: 사용자 이름 또는 표시명
  • iat: 토큰 발급 시간
  • exp: 토큰 만료 시간
주의

JWT Payload는 쉽게 디코딩될 수 있으므로 비밀번호, 주민번호, API Key 같은 민감한 값은 넣지 않는 것이 좋습니다.

생성 결과

생성된 JWT 토큰과 Header, Payload, Signature 구성을 확인할 수 있습니다.

대기 중 
JWT 생성 결과가 여기에 표시됩니다.
Header 
-
Payload 
-
Signature 
-
사용 가이드

HS256 JWT를 서명·암호화·검증 관점에서 구분해 사용하는 법

JWT는 점으로 구분된 header, payload와 signature를 전달하는 형식이며, 이 도구가 만드는 HS256 토큰의 payload는 암호화되지 않습니다. 서명이 맞는다는 사실만으로 발급자·수신자·만료·권한이 모두 안전하다는 뜻은 아니므로 학습과 개발용 초안으로만 사용해야 합니다.

작성 · 검토
win-j
최종 검토
2026-10-01

이런 분께 유용합니다

  • JWT 구조와 HS256 서명을 학습하는 개발자
  • 테스트 API용 토큰 초안을 만드는 개발자
  • JWT 검증 항목을 점검하는 백엔드 운영자

대표 활용 상황

  • header·payload·signature 구조를 확인할 때
  • 개발 환경에서 HS256 테스트 토큰을 만들 때
  • exp·nbf·iat NumericDate 형식을 비교할 때

처음부터 결과 확인까지

  1. 1

    header는 JSON 객체로 작성하고 알고리즘은 HS256으로 고정합니다.

  2. 2

    payload에는 공개돼도 되는 테스트 값만 넣고 비밀번호·개인정보·운영 키는 넣지 않습니다.

  3. 3

    이 도구에서는 exp, nbf, iat를 정수형 Unix 초 단위로 입력합니다. RFC의 NumericDate 전체 범위보다 엄격한 입력 조건입니다.

  4. 4

    최소 32바이트 이상의 무작위 비밀키를 사용하고 운영 환경의 키를 입력하지 않습니다.

  5. 5

    토큰을 생성해 세 구간과 서명 결과를 확인합니다.

  6. 6

    실제 서버에서는 허용 알고리즘을 고정하고 발급자, 수신자, 만료와 권한을 별도로 검증합니다.

사용 예시 1

개발용 세션 토큰

입력
alg HS256, sub test-user, exp 정수, 32바이트 이상 임의 키
결과
header.payload.signature 형태의 서명 토큰

payload는 Base64url 디코딩으로 읽을 수 있으므로 민감한 값을 담지 않습니다.

사용 예시 2

잘못된 짧은 키

입력
짧은 단어를 secret으로 입력
결과
32바이트 이상을 요구하는 오류

RFC 7518의 HS256 키 크기 요구를 개발 단계에서 놓치지 않도록 생성이 중단됩니다.

계산·처리 기준

Header와 Payload JSON을 UTF-8 및 Base64url로 인코딩하고 Web Crypto HMAC SHA-256으로 서명합니다. 비밀키는 화면에 입력된 문자열의 UTF-8 바이트를 그대로 사용합니다. 랜덤 키 버튼은 32바이트 난수를 64자리 16진수 문자열로 표시하며, 서명할 때 이 문자열을 다시 바이너리로 해석하지 않습니다. HS256 외 알고리즘, crit 확장과 b64:false는 지원하지 않습니다.

알아둘 한계

  • HS256만 지원하며 RSA·ECDSA·암호화 JWE는 생성하지 않습니다.
  • 서버의 실제 issuer, audience, nonce, 권한 정책이나 토큰 폐기 상태를 검증하지 않습니다.
  • 브라우저에서 만든 토큰은 학습·로컬 테스트용이며 운영 인증 체계를 대신할 수 없습니다.
  • 클립보드·다운로드 파일·브라우저 확장 프로그램을 통한 노출 위험은 사용자가 관리해야 합니다.
  • Header는 최대 20,000자, Payload는 최대 100,000자, 비밀키는 UTF-8 32~4,096바이트입니다. exp가 과거인지 검사하지 않으므로 생성 성공이 현재 유효한 토큰을 뜻하지 않습니다.
개인정보 처리

JSON과 비밀키는 브라우저에서 처리하지만 운영 비밀키를 입력하지 마세요. payload는 암호화되지 않아 토큰을 얻은 누구나 내용을 읽을 수 있고, 복사하거나 내려받은 토큰은 기기와 클립보드에 남을 수 있습니다.

함께 쓰면 좋은 도구

  • Hash 생성기

    일반 해시와 키를 쓰는 HMAC 서명의 차이를 함께 이해합니다.

  • UUID 비교·생성기

    테스트용 식별자를 생성하고 UUID 구조를 비교합니다.

자주 묻는 질문

JWT payload는 비밀인가요?

아닙니다. 일반적인 서명 JWT의 header와 payload는 인코딩될 뿐 암호화되지 않아 토큰을 가진 사람이 읽을 수 있습니다.

서명이 맞으면 바로 로그인시켜도 되나요?

아닙니다. 허용 알고리즘을 고정하고 exp, nbf, issuer, audience와 애플리케이션 권한을 서버 정책에 맞게 검증해야 합니다.

HS256 키는 왜 32바이트 이상이어야 하나요?

HS256의 기반 해시 출력이 256비트이며 RFC 7518은 그보다 짧지 않은 키를 요구합니다. 사람이 정한 짧은 문장 대신 암호학적으로 무작위인 키를 사용하세요.

운영 secret을 넣어도 서버로 전송되지 않으니 괜찮나요?

권장하지 않습니다. 브라우저 확장, 클립보드, 화면 기록과 다운로드 파일 등 다른 노출 경로가 있으므로 운영 키는 전용 비밀 관리 환경에서만 다루세요.

랜덤 키는 16진수로 해석해서 사용하나요?

아닙니다. 표시된 64자리 문자열을 UTF-8 키로 사용합니다. 서버에서도 같은 문자열을 UTF-8로 처리해야 동일한 서명을 계산할 수 있습니다.