JWT 디코더

개발

JSON Web Token(헤더, 페이로드)을 디코딩하고 만료와 서명을 확인합니다. 디코딩 전용 — 서명은 검증하지 않습니다.

100% 클라이언트 백엔드 없음

입력

헤더

페이로드

발급(iat)
시작(nbf)
만료(exp)
서명

이 페이지에서

JWT란?#

JWT(JSON Web Token, RFC 7519에 정의)는 두 당사자 사이에 클레임을 싣기 위해 만들어진 간결하고 URL에 안전한 토큰입니다. 로그인 후 브라우저가 API에 보내는 자격 증명, OAuth 제공자가 의존 응용 프로그램에 건네는 신원 단언, 그리고 대부분의 현대 세션 및 접근 제어 흐름이 여행하는 봉투입니다. 매력은 클레임 — 사용자가 누구인지, 무엇을 할 수 있는지, 토큰이 언제 만료되는지 — 이 JSON으로 토큰 자체 안에 여행한다는 점입니다. 그래서 수신 서비스는 데이터베이스 조회 없이 클레임을 읽을 수 있습니다.

JWT는 점으로 구분된 정확히 세 개의 base64url 인코딩 부분으로 이루어집니다. header.payload.signature. 헤더는 알고리즘과 토큰 타입을 이름 붙입니다. 페이로드는 클레임의 JSON 객체입니다. sub(주체), iat(발급 시각), exp(만료), nbf(시작 이전) 같은 등록된 것과 응용 프로그램이 추가하는 사용자 정의 클레임. 서명은 발급자가 비밀 키 또는 개인 키로 다른 두 부분에 대해 계산한 것이며, 이를 검증하는 것이 토큰이 변조되지 않았음을 증명합니다.

이 페이지는 JWT를 디코딩하고 검사합니다. 세 부분을 나누고, 헤더와 페이로드를 읽을 수 있는 JSON으로 base64url 디코딩하고, 표준 시간 클레임을 사람이 읽을 수 있는 타임스탬프로 드러내며, 라이브 상태 배지(유효, 만료됨, 아직 시작 전)를 보여 줍니다. 의도적으로 서명을 검증하지 않습니다. 발급자의 비밀 키 또는 공개 키가 필요하며 100% 클라이언트 사이드 도구의 범위를 벗어납니다. 서명 세그먼트는 받은 그대로 날것으로 표시됩니다.

사용 방법#

왼쪽 입력 상자에 토큰을 붙여넣습니다. 점으로 구분된 세 세그먼트여야 하며, 주변 공백은 자동으로 잘립니다.
레이아웃이 어떻게 동작하는지 보고 싶기만 하다면 예제 (iat/exp/nbf 포함)를 클릭해 내장 예시 토큰을 불러옵니다.
지우기 로 입력과 결과 창을 비웁니다.
오른쪽 패널을 읽습니다.
- 상단의 상태 배지 — 현재 시간과 비교한 nbf, exp 클레임에 기반해 녹색 유효, 만료됨, 또는 아직 시작 전.
- 헤더 카드(제목 표시줄에 HS256 같은 알고리즘 표시).
- 페이로드 카드, JSON으로 보기 좋게 출력.
- 시간 클레임 목록 — 발급(iat), 시작(nbf), 만료(exp) — 각각 unix 타임스탬프와 읽을 수 있는 날짜로 렌더링.
- 서명 세그먼트. 여전히 base64url 인코딩된 바이트이므로 날것으로 표시.
토큰이 형식이 잘못되면 빨간 상태 줄이 세 세그먼트 형태 검사, base64url 디코딩, 또는 JSON 파싱 중 어느 것에 실패했는지 알려 줍니다.

주요 기능#

라이브 시간 클레임 상태. iat, nbf, exp를 읽고 토큰이 현재 유효한지, 이미 만료되었는지, 아직 효력이 없는지 알려 줍니다. 로그인 버그 중에 실제로 묻는 세 가지 질문입니다.
사람이 읽을 수 있는 날짜. 1700000000 같은 Unix epoch 숫자가 그것이 나타내는 UTC 날짜 옆에 표시되어 머릿속 epoch 산술을 그만하게 해 줍니다.
알고리즘 표시. 헤더의 alg 값이 헤더 카드의 제목 표시줄로 올라가, HS256인지 RS256인지 예상 밖의 것인지 즉시 보게 합니다.
UTF-8 안전 디코딩. Base64url 세그먼트는 TextDecoder를 통해 바이트로 디코딩되므로 비 ASCII 클레임(다른 문자 체계의 이름, 역할)이 깨진 글자가 아니라 올바르게 렌더링됩니다.
디코딩 전용 — 검증하지 않음. 도구는 결코 비밀 키를 요구하지 않아, 완전히 신뢰하지 않는 토큰을 붙여넣기에 안전합니다. 아무것도 전송되지 않으며, 서명은 표시되지만 점검되지 않습니다.

사용 예#

예제 를 클릭하면 입력이 헤더가 다음으로 디코딩되는 토큰으로 채워집니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

그리고 페이로드는 다음으로 디코딩됩니다.

{
  "sub": "1234567890",
  "name": "ArpGate Demo",
  "iat": 1700000000,
  "exp": 4102444800,
  "nbf": 1699999000
}

시간 클레임 목록은 다음을 표시합니다.

Issued at   1700000000  (2023-11-14 22:13:20 UTC)
Not before  1699999000  (2023-11-14 21:56:40 UTC)
Expires     4102444800  (2100-01-01 00:00:00 UTC)

상태 배지는 유효 로 읽힙니다. 현재 시간이 nbf 이후이고 exp 이전이기 때문입니다. 서명 세그먼트는 리터럴 문자열 c2FtcGxlLXNpZ25hdHVyZS1ub3QtdmVyaWZpZWQ로 표시되며, 이는 “sample-signature-not-verified”라는 텍스트로 디코딩됩니다. 이 토큰의 서명이 예시용이지 실제 HMAC-SHA256 출력이 아님을 나타내는 의도적 표식입니다.

마지막 점이 이 도구에 대해 이해할 가장 중요한 단일 사실입니다. 깨끗이 디코딩되는 토큰이 반드시 신뢰할 수 있는 토큰은 아닙니다. 누구나 헤더와 페이로드를 위조할 수 있습니다. 발급자의 비밀 키 또는 공개 키에 대해 점검된 서명만이 진본성을 증명합니다. 클레임을 읽고 시간 창을 디버깅하는 데 이 페이지를 쓰고, 서명 검증은 실제 백엔드에서 하세요.

FAQ#

이 도구가 JWT가 진본인지 알려주나요?#

아니요, 그것은 의도된 설계입니다. 디코딩은 토큰 안의 JSON을 읽을 뿐, 토큰이 발급을 주장한 자가 실제로 발급했음을 증명하지 않습니다. 진본성을 검증하려면 alg에 맞는 키(HS256의 공유 비밀, RS256/ES256의 발급자 공개 키)와 신뢰할 수 있는 백엔드의 검증 루틴이 필요합니다. 깨끗이 디코딩된 토큰을 검증된 것으로 취급하지 마세요.

상태가 “만료됨”이라고요. 여기서 토큰을 갱신할 수 있나요?#

아닙니다. 갱신은 새 접근 토큰을 받기 위해 인증 서버의 갱신 엔드포인트를 호출하는 것입니다. 이 정적 클라이언트 사이드 페이지가 수행할 수도, 해서도 안 되는 네트워크 작업입니다. 여기서 할 수 있는 것은 이전 토큰이 정확히 언제 만료되었는지 확인하는 것입니다. 대개 필요했던 단서입니다.

`iat`, `nbf`, `exp`의 차이는?#

iat(발급 시각)은 토큰이 생성된 때입니다. 정보성입니다. nbf(시작 이전)는 토큰이 받아들여져야 하는 가장 이른 시각입니다. nbf 이전에는 서명이 유효해도 검증 서버가 거부해야 합니다. exp(만료)는 이후에 토큰이 거부되어야 할 하드 차단점입니다. 잘 구성된 토큰은 nbf ≤ iat ≈ 현재, 그리고 가까운 미래의 exp를 가집니다(접근 토큰은 분 단위, 갱신 토큰은 더 김).

내 페이로드에 비 ASCII 문자가 있는데 다른 곳에서는 깨져 보입니다. 여기서는 왜 올바르나요?#

일부 디코더가 각 base64url 문자를 바이트로 잘못 취급하여 먼저 날 바이트로 디코딩하지 않기 때문입니다. 이 페이지는 Uint8Array로 디코딩한 뒤 TextDecoder를 통해 실행하여 바이트를 올바른 UTF-8로 해석합니다. 그것이 올바른 방법이며, 어느 문자 체계의 이름, 역할, 범위도 쓰인 대로 렌더링되는 이유입니다.