JWT Encoder

HS256, HS384, HS512로 JSON 웹 토큰 생성 및 서명

헤더

로컬에서 실행 · 시크릿 붙여넣기 안전

페이로드

로컬에서 실행 · 시크릿 붙여넣기 안전

비밀 키

로컬에서 실행 · 시크릿 붙여넣기 안전

인코딩된 JWT

Output will appear here…

비밀 키는 브라우저를 벗어나지 않습니다. 모든 서명은 클라이언트 측에서 수행됩니다.

이것도 써보세요:JWT 디코더

JWT 인코딩이란?

JWT 인코딩은 JSON Web Token을 생성하는 프로세스입니다——암호화 키로 서명된 클레임 집합을 담은 컴팩트하고 URL 안전한 문자열입니다. 결과는 RFC 7519로 정의된 3부 토큰(헤더.페이로드.서명)으로, 서버는 세션 상태를 유지하지 않고 검증할 수 있습니다. 온라인 JWT 인코딩을 사용하면 테스트 및 개발을 위해 브라우저에서 직접 토큰을 생성하고 서명할 수 있습니다.

헤더는 서명 알고리즘(예: HS256) 및 토큰 유형을 선언합니다. 페이로드는 클레임을 포함합니다——주체(sub), 만료 시간(exp), 애플리케이션이 필요로 하는 사용자 정의 데이터 등 키-값 쌍입니다. 두 부분 모두 JSON으로 직렬화된 다음 base64url로 인코딩됩니다. 서명은 비밀 키를 사용하여 인코딩된 헤더와 페이로드 위에서 계산되어 3개 세그먼트를 바인딩합니다.

세션 쿠키와 달리 JWT는 자체 포함되어 있습니다. 검증자는 데이터베이스를 쿼리하거나 외부 서비스를 호출할 필요가 없습니다. 이로 인해 JWT 기반 인증은 REST API, 마이크로서비스, 단일 페이지 애플리케이션에서 인기가 있으며, 상태 비저장 권한 부여는 지연 시간을 줄이고 수평 확장을 단순화합니다.

JWT 인코더를 사용하는 이유는?

JWT를 수동으로 생성하려면 base64url 인코딩, JSON 직렬화, HMAC 계산이 필요합니다. 이 도구는 3가지 단계를 즉시 처리하므로 올바른 클레임에 집중할 수 있습니다.

즉시 토큰 생성
헤더, 페이로드, 비밀 키를 편집하십시오——서명된 JWT가 실시간으로 업데이트됩니다. 빌드 단계, 라이브러리 설치, 보일러플레이트 코드 없음.
🔒
다중 HMAC 알고리즘
한 번의 클릭으로 HS256, HS384, HS512 사이를 전환합니다. 헤더가 자동으로 업데이트되고 서명이 즉시 재계산됩니다.
🛡️
개인정보보호 우선 처리
모든 서명은 Web Crypto API를 사용하여 브라우저에서 발생합니다. 비밀 키 및 페이로드 데이터는 머신을 떠나지 않습니다——서버 없음, 로그 없음, 위험 없음.
📋
원클릭 클레임 도우미
한 번의 버튼 클릭으로 iat, exp+1h 또는 exp+24h 타임스탬프를 추가합니다. Unix 타임스탬프를 수동으로 계산하거나 현재 에포크 시간을 찾을 필요가 없습니다.

JWT 인코더 사용 사례

프론트엔드 인증 테스트
특정 클레임 및 만료 시간으로 토큰을 생성하여 백엔드 인증 서버를 실행하지 않고 로그인 흐름, 토큰 새로고침 로직, 보호된 경로 가드를 테스트합니다.
백엔드 API 개발
사용자 정의 sub, aud, scope 클레임으로 테스트 토큰을 만들어 로컬 개발 중에 권한 부여 미들웨어, 역할 기반 접근 제어, 권한 검사를 연습합니다.
DevOps 및 CI/CD 파이프라인
배포 스크립트, 통합 테스트, 또는 서비스 간 통신을 위한 단기 토큰을 생성합니다(전체 OAuth 흐름은 불필요한 복잡성을 추가합니다).
QA 및 수동 테스트
엣지 케이스 클레임으로 토큰을 구성합니다——만료된 토큰, 누락된 필드, 잘못된 대상——API가 올바른 HTTP 401 또는 403 응답을 반환하는지 확인합니다.
보안 감사
서로 다른 알고리즘과 비밀 길이로 서명된 토큰을 생성하여 검증 로직이 약한 또는 일치하지 않는 서명을 올바르게 거부하는지 검증합니다.
학습 및 프로토타이핑
JWT를 새로 접하는 학생과 개발자는 헤더 필드, 클레임 구조, 서명 알고리즘을 실험하여 토큰의 각 부분이 어떻게 작동하는지 이해할 수 있습니다.

HS256 vs HS384 vs HS512: HMAC 알고리즘 비교

3개 알고리즘 모두 공유 비밀을 사용하여 HMAC(해시 기반 메시지 인증 코드)를 사용합니다. 차이점은 기본 해시 함수에 있으며, 이는 서명 길이와 보안 여유도에 영향을 미칩니다. 대부분의 애플리케이션의 경우 HS256은 충분한 보안을 제공합니다. 규정 준수 요구 사항(예: FIPS-140)이 더 강력한 해시를 요구하거나 토큰이 높은 가치의 권한 부여 결정을 수행할 때 HS384 또는 HS512를 선택합니다.

알고리즘해시서명속도일반적 사용
HS256SHA-25632 BFastestGeneral purpose, default for most libraries
HS384SHA-38448 BFastHigher security margin, FIPS-140 compliant
HS512SHA-51264 BFastMaximum HMAC security, large payloads

표준 JWT 클레임 참조

RFC 7519는 7개의 등록된 클레임을 정의합니다. 어느 것도 필수는 아니지만 올바르게 사용하면 상호 운용성과 보안이 향상됩니다. exp 클레임은 특히 중요합니다——만료 없는 토큰은 비밀이 로테이션되지 않으면 무기한 유효합니다.

클레임이름설명예제
issIssuerWho issued the token"auth.example.com"
subSubjectWho the token represents"user-123"
audAudienceIntended recipient service"api.example.com"
expExpirationUnix timestamp — token invalid after this time1717203600
nbfNot BeforeUnix timestamp — token invalid before this time1717200000
iatIssued AtUnix timestamp when the token was created1717200000
jtiJWT IDUnique token identifier for revocation tracking"a1b2c3d4"

코드의 JWT 인코딩

이 예제들은 프로그래밍 방식으로 JWT를 생성하고 서명하는 방법을 보여줍니다. 각 스니펫은 유효한 HS256 서명 토큰을 생성합니다. 프로덕션 시스템의 경우 항상 exp 클레임을 설정하고 최소 256비트의 암호적으로 안전한 비밀을 사용합니다.

JavaScript (Web Crypto API)
async function signJWT(payload, secret, alg = 'HS256') {
  const header = { alg, typ: 'JWT' }
  const enc = new TextEncoder()

  // Base64url encode header and payload
  const b64url = (obj) =>
    btoa(JSON.stringify(obj)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  const h = b64url(header)
  const p = b64url(payload)

  // Sign with HMAC-SHA256
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(`${h}.${p}`))
  const s = btoa(String.fromCharCode(...new Uint8Array(sig)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  return `${h}.${p}.${s}`
}

// Usage
const token = await signJWT(
  { sub: 'user-123', name: 'Alice', iat: Math.floor(Date.now() / 1000) },
  'your-256-bit-secret'
)
// → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."
Python (PyJWT)
import jwt
import time

payload = {
    "sub": "user-123",
    "name": "Alice",
    "iat": int(time.time()),
    "exp": int(time.time()) + 3600,  # expires in 1 hour
}

# Sign with HS256 (default)
token = jwt.encode(payload, "your-256-bit-secret", algorithm="HS256")
# → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."

# Verify and decode
decoded = jwt.decode(token, "your-256-bit-secret", algorithms=["HS256"])
# → {"sub": "user-123", "name": "Alice", "iat": 1717200000, "exp": 1717203600}
Node.js (jsonwebtoken)
const jwt = require('jsonwebtoken')

const payload = {
  sub: 'user-123',
  name: 'Alice',
  role: 'admin',
}

// Sign — iat is added automatically
const token = jwt.sign(payload, 'your-256-bit-secret', {
  algorithm: 'HS256',
  expiresIn: '1h',    // sets exp claim
  issuer: 'auth.example.com',  // sets iss claim
})

// Verify
const decoded = jwt.verify(token, 'your-256-bit-secret')
// → { sub: 'user-123', name: 'Alice', role: 'admin', iat: ..., exp: ... }
Go (golang-jwt)
package main

import (
    "fmt"
    "time"
    "github.com/golang-jwt/jwt/v5"
)

func main() {
    claims := jwt.MapClaims{
        "sub":  "user-123",
        "name": "Alice",
        "iat":  time.Now().Unix(),
        "exp":  time.Now().Add(time.Hour).Unix(),
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    signed, _ := token.SignedString([]byte("your-256-bit-secret"))
    fmt.Println(signed)
    // → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOi...
}

자주 묻는 질문

JWT 인코딩과 JWT 디코딩의 차이점은?
JWT 인코딩은 헤더, 페이로드, 비밀 키로부터 서명된 토큰을 생성합니다. JWT 디코딩은 프로세스를 역으로 수행합니다——base64url로 인코딩된 헤더와 페이로드를 다시 JSON으로 읽습니다. 디코딩에는 비밀이 필요하지 않습니다. 인코딩은 항상 필요합니다(서명을 계산해야 하기 때문).
JWT 비밀 키는 얼마나 길어야 하나?
HS256의 경우 최소 256비트(32바이트) 비밀을 사용합니다. HS384의 경우 최소 384비트(48바이트). HS512의 경우 최소 512비트(64바이트). 더 짧은 비밀은 기술적으로 대부분의 라이브러리에서 수용되지만 HMAC 서명의 유효 보안을 감소시킵니다. 사람이 선택한 암호가 아닌 암호적으로 안전한 난수 생성기로 비밀을 생성합니다.
실제 비밀 키로 이 도구를 사용하는 것이 안전한가?
이 도구는 Web Crypto API를 사용하여 브라우저에서 모든 것을 처리합니다——서버로 데이터가 전송되지 않습니다. 그래도 일반적인 보안 관행으로 프로덕션 비밀을 웹 도구에 붙여넣기를 피하십시오. 프로덕션 키 관리의 경우 환경 변수 또는 HashiCorp Vault 또는 AWS Secrets Manager와 같은 비밀 관리자를 사용합니다.
내 애플리케이션에 HS256 또는 RS256을 사용해야 하나?
동일한 서비스가 토큰을 생성하고 확인할 때 HS256을 사용합니다——더 빠르고 간단합니다. 제3자 서비스가 토큰을 생성하지 않고 확인해야 할 때 RS256(비대칭)을 사용합니다. RS256은 OAuth 2.0 공급자, OpenID Connect, 멀티테넌트 SaaS 아키텍처에서 일반적입니다.
JWT가 생성 직후에 만료되는 이유는?
exp 클레임은 밀리초가 아닌 초 단위의 Unix 타임스탬프를 사용합니다. exp를 Date.now()(밀리초를 반환)로 설정하면 토큰이 미래의 수천 년 후에 만료되는 것으로 보입니다——또는 초가 예상되는 곳에서 밀리초 값을 실수로 사용하면 라이브러리는 이미 만료된 것으로 해석할 수 있습니다. JavaScript에서는 항상 Math.floor(Date.now() / 1000)을 사용하거나 Python에서는 int(time.time())을 사용합니다.
JWT 페이로드에 민감한 데이터를 넣을 수 있나?
할 수 있지만 해서는 안 됩니다. JWT 페이로드는 base64url로 인코딩되지만 암호화되지 않습니다——토큰을 가진 누구나 클레임을 읽을 수 있습니다. 암호, 신용 카드 번호, 개인 데이터를 페이로드에 저장하지 않습니다. 민감한 정보를 포함해야 하는 경우 RFC 7516에 정의된 JWE(JSON Web Encryption)를 사용하세요. 이는 전체 페이로드를 암호화합니다.
서명 후 페이로드를 변경하면 어떻게 되나?
서명이 무효가 됩니다. HMAC 서명은 인코딩된 헤더와 페이로드의 정확한 바이트에서 계산됩니다. 공백을 추가하거나 단일 문자를 변경하는 것처럼 모든 변경 사항은 완전히 다른 서명을 생성합니다. 올바르게 구현된 검증자는 서명 불일치 오류로 토큰을 거부합니다.