본문으로 건너뛰기
yutils
JWT 생성기 (HMAC)
예시

입력 (JWT 토큰)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoieXV0aWxzIiwiZXhwIjoxNzgwMDAwMDAwfQ.signature

디코딩 결과 (Header + Payload)

Header: { "alg": "HS256", "typ": "JWT" }
Payload: { "sub": "123", "name": "yutils", "exp": 1780000000 }

참고

이 도구는 디코딩만 수행합니다. exp(만료) 값은 Unix 초 단위 — 사람이 읽기 좋게 보려면 unix-timestamp 도구에 붙여 넣으세요. 서명 검증은 서버에서 별도 수행해야 합니다.

사용법 / 자주 묻는 질문

이런 경우 사용하세요

  • 쿠키·Authorization 헤더에 박힌 JWT의 header / payload 살펴보기
  • exp(만료) · iat(발급) · sub(주체) 클레임 값을 빠르게 확인
  • 디버깅 중 iss(발급자) · aud(대상)가 기대와 일치하는지 검증
  • 백엔드가 사용한 알고리즘(alg) · 키 ID(kid) 확인
  • 프론트엔드에서 토큰 모양을 시각적으로 검증 (서명 검증은 별도)

자주 묻는 질문

Q.서명 검증도 해주나요?
A.아닙니다. 서명 검증은 공개키가 필요하며 외부 도구에 키를 붙여넣는 것은 권장하지 않습니다. yutils는 디코딩만 수행합니다. 검증은 서버 또는 `jose` 같은 라이브러리로 직접 수행하세요.
Q.토큰이 어딘가로 전송되나요?
A.아닙니다. 모든 디코딩은 브라우저에서만 처리됩니다. 토큰이 yutils 서버나 외부 API로 나가지 않습니다.
Q.누구나 디코딩할 수 있는데 JWT가 어떻게 안전한가요?
A.JWT payload는 원래 읽을 수 있도록 설계됐습니다. 보안은 서명에서 옵니다 — 서버의 비밀 키만이 유효한 서명을 만들 수 있기 때문입니다. 따라서 민감 정보는 절대 payload에 넣지 마세요.
재미있는 사실

  • JWT의 공식 발음은 'jot'입니다. RFC 7519 §1에 정확히 박혀 있습니다 — "JWTs are pronounced 'jot'". 하지만 현장에서는 다들 J·W·T라고 부르는 중. RFC 작성자들도 결국 받아들인 듯합니다.

    RFC 7519 §1

  • 초기 JWT 라이브러리들은 `alg: none` 알고리즘을 받아들였습니다. 토큰을 만든 사람이 "서명 없음"이라고 헤더에 박으면 서버가 검증을 건너뛰는 구조. 2015년 이 결함으로 수많은 서비스가 누구나 발급 가능한 admin 토큰에 노출됐고, 이후 대부분의 라이브러리가 `none`을 거부하는 default로 바뀌었습니다.

    Auth0 — JWT none 취약점

  • JWT payload는 암호화가 아니라 인코딩일 뿐입니다 — 누구나 Base64URL로 디코드해 내용을 읽을 수 있어요. 그래서 비밀번호·신용카드번호 같은 민감 정보를 절대 payload에 넣으면 안 됩니다. JWT의 보안은 "서명을 위조할 수 없다"에서 옵니다.

    RFC 7519

관련 도구

이 카테고리 모든 도구 보기 →