JWT 디코더: 클레임과 만료 시간 확인

보안브라우저에서 실행(업로드 없음)

컴팩트 JSON Web Token을 브라우저에서 디코딩해 보호 헤더, 페이로드 클레임, 서명 바이트, exp·nbf·iat 시간을 확인합니다. 엄격한 Base64URL·JSON 검사로 잘못된 토큰은 찾지만 서명과 클레임은 검증하지 않습니다.

다음에 할 작업

관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.

작업 가이드

바이트를 손상하지 않고 Base64 API payload 디코딩하기

인코딩된 JSON 필드, Webhook metadata, 헤더, 쿠키, 로그를 반복 가능한 순서로 점검합니다. 디코딩 전에 알파벳과 패딩을 검증하고 바이너리 바이트를 보존하며 Base64를 암호화나 서명 검증과 구분합니다.

열기 관련 도구

Base64 인코더와 디코더 | UTF-8·Base64URL·Data URI

UTF-8을 엄격하게 인코딩하고 Base64·Base64URL·Data URI·바이너리 바이트를 로컬에서 디코딩합니다.

열기 관련 도구

파일 해시·체크섬 생성기

UTF-8 텍스트나 파일 원본 바이트를 해시하고 전체 체크섬을 로컬에서 비교합니다.

열기 관련 도구

요청·응답 디버깅용 HTTP 헤더 파서

HTTP 헤더 블록을 로컬에서 분석하고 민감값 마스킹과 프로토콜 진단을 제공합니다.

열기

이 도구 사용 방법

Bearer 접두사가 있거나 없는 3개 부분 JWT를 합성 또는 마스킹한 상태로 붙여넣습니다.

디코딩한 뒤 클레임을 읽기 전에 구조 오류가 없는지 확인합니다.

선언된 alg와 kid, 페이로드 클레임, 서명 바이트 수, exp·nbf·iat의 UTC 정보를 확인합니다.

서명 미검증, alg none, 만료, 아직 사용 전, 미래 iat, 중요 헤더, 정밀도 손실 경고를 모두 읽습니다.

디버깅용 결과를 복사하거나 내려받은 뒤 실제 판단은 신뢰할 수 있는 서버용 JWT 라이브러리로 원본 토큰을 검증해서 수행합니다.

이 도구를 써야 할 때

API 인증 디버깅

401 또는 403 응답을 조사하며 발급자, 대상, 주체, 스코프, 역할, 시간 클레임을 비교합니다.

OAuth·OpenID Connect 연동

액세스 토큰이나 ID 토큰의 클레임 형태를 살펴본 뒤 인증 제공자와 백엔드 검증 설정을 확인합니다.

토큰 보안 검토

alg none, 예상 밖 kid, 중요 헤더, 민감한 페이로드, 잘못된 NumericDate 순서를 점검합니다.

안전한 디버깅 문서

테스트·티켓·문서에 넣을 합성 토큰을 명시적으로 미검증 상태인 읽기 쉬운 JSON으로 정리합니다.

흔한 실수

디코딩 결과를 검증된 정보로 믿기

신뢰할 수 있는 라이브러리가 서명을 검증하고 허용 알고리즘, 발급자, 대상, 시간 규칙을 적용하기 전까지 헤더와 페이로드는 공격자가 만든 데이터일 수 있습니다. 읽힌다는 사실은 진위를 증명하지 않습니다.

페이로드에 비밀정보 넣기

일반적인 JWT 페이로드는 암호화가 아니라 서명과 인코딩만 되어 있습니다. 비밀번호, API 키, 세션 비밀, 불필요한 개인정보는 토큰 보유자에게 그대로 보입니다.

만료 시간만 확인하기

exp가 미래라는 이유만으로 토큰을 허용할 수 없습니다. nbf, iat, iss, aud, 키 선택, 폐기 여부, 애플리케이션 전용 클레임도 함께 검증해야 합니다.

토큰이 선언한 알고리즘을 신뢰하기

검증되지 않은 alg 값이 느슨한 검증 경로를 선택하게 해서는 안 됩니다. 검증기는 토큰 입력과 별개로 허용 알고리즘과 신뢰 키를 고정해야 합니다.

JWS와 JWE 형식 혼동하기

5개 부분으로 된 JWE는 암호화된 형식이므로 지정된 복호화 키와 알고리즘 처리가 필요합니다. 3개 부분 JWS처럼 페이로드만 읽을 수 없습니다.

예시

UTF-8 클레임과 NumericDate 확인

이 합성 RS256 토큰에는 한글 UTF-8 문자열과 미래 시간 클레임이 들어 있습니다. 서명 문자열은 의도적으로 데모 값이므로 결과는 계속 신뢰할 수 없는 데이터입니다.

입력

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRlbW8tMjAyNi0wNyJ9.eyJzdWIiOiJkZW1vX3VzZXJfNDIiLCJuYW1lIjoi6rCA656MIiwic2NvcGUiOiJyZXBvcnRzOnJlYWQiLCJpc3MiOiJodHRwczovL2F1dGguZXhhbXBsZS50ZXN0IiwiYXVkIjoicmVwb3J0cy1hcGkiLCJpYXQiOjE3ODQwNzM2MDAsIm5iZiI6MTc4NDA3MzYwMCwiZXhwIjoxODkzNDU2MDAwfQ.ZGVtby1zaWduYXR1cmUtbm90LXZlcmlmaWVk

출력

{
  "header": { "alg": "RS256", "typ": "JWT", "kid": "demo-2026-07" },
  "payload": { "sub": "demo_user_42", "name": "가람", "exp": 1893456000 },
  "inspection": { "signatureVerified": false }
}

서명 없는 alg none 토큰 식별

보호되지 않은 토큰은 alg none을 선언하고 세 번째 부분이 비어 있어야 합니다. 디코더는 이를 유효하다고 하지 않고 무결성 보호가 없다는 경고를 표시합니다.

입력

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZW1vIiwiZXhwIjoxNzAwMDAwMDAwfQ.

출력

{
  "algorithm": "none",
  "signature": { "present": false, "verified": false },
  "expirationStatus": "expired"
}

엄격한 디코딩 경계와 신뢰 모델

서명된 컴팩트 JWT는 보호 헤더, 페이로드, 서명의 세 부분을 점으로 연결합니다. 앞의 두 부분은 무패딩 Base64URL로 인코딩된 UTF-8 JSON 객체이므로 키가 없어도 누구나 내용을 읽을 수 있습니다.

디코더는 정규 Base64URL 문자, 유효한 UTF-8, 헤더와 페이로드 각각 하나의 JSON 객체, 비어 있지 않은 alg 문자열, 알고리즘에 맞는 서명 부분을 요구합니다. 파서마다 다르게 해석될 수 있는 중복 키도 거부합니다.

exp, nbf, iat는 유한한 NumericDate 초로 검사합니다. 원래 값과 함께 UTC 및 상대 초를 추가하고, 만료·사용 전·미래 발급·잘못된 값·불가능한 시간 순서를 서로 다른 경고로 모두 유지합니다.

서명 부분은 바이트 수를 계산하기 위해서만 디코딩합니다. 비밀키·공개키·JWKS 조회, MAC 비교, 발급자·대상·폐기 여부·권한 규칙 검사는 이 브라우저 도구에서 전혀 수행하지 않습니다.

입력 100KB, JSON 깊이 64단계, 노드 50,000개, 포맷 출력 512KB로 제한합니다. 5개 부분 JWE는 암호화된 토큰이므로 일반 페이로드 디코딩과 구분해 거부합니다.

자주 묻는 질문

JWT 서명을 검증하나요?

아닙니다. 이 도구는 컴팩트 토큰 데이터를 디코딩하고 살펴보기만 합니다. 신뢰 서버에서 신뢰 키로 서명을 검증하고 허용 알고리즘, 발급자, 대상, 시간 클레임과 서비스 정책을 적용해야 합니다.

토큰이 유효하거나 만료됐는지 판정하나요?

브라우저 시계 기준으로 exp가 없거나, 잘못되었거나, 이미 지났거나, 아직 미래인지 표시합니다. 이는 관찰 결과일 뿐 서명, 발급자, 대상, 시계 오차 정책과 토큰 허용 여부를 증명하지 않습니다.

JWT 시간 클레임은 어떻게 표시하나요?

exp, nbf, iat는 Unix epoch 이후 초 단위인 NumericDate입니다. 원래 값을 유지하면서 UTC 시각과 현재 기준 남은 초 또는 지난 초를 결과에 추가합니다.

암호화된 JWE도 디코딩하나요?

3개 부분으로 된 컴팩트 JWS는 디코딩할 수 있습니다. 5개 부분 JWE는 암호화되어 키와 알고리즘 정책이 필요하므로 전용 오류로 거부합니다.

입력한 JWT가 브라우저 밖으로 전송되나요?

디코딩은 브라우저에서 실행되며 토큰을 업로드하지 않습니다. 하지만 실제 액세스 토큰은 권한을 부여하거나 개인정보를 담을 수 있으므로 가능하면 마스킹한 토큰이나 합성 토큰을 사용하세요.

Base64URL 또는 JSON 오류가 나는 이유는 무엇인가요?

엄격한 무패딩 Base64URL은 영문자, 숫자, 하이픈, 밑줄만 허용합니다. 더하기, 슬래시, 등호 패딩, 내부 공백, 잘못된 UTF-8, 잘못된 JSON, 중복 키는 거부합니다.

입력과 구조 제한은 어떻게 되나요?

입력은 100KB까지 허용하고 JSON 깊이, 노드 수, 출력 크기도 제한합니다. 비정상적으로 크거나 복잡한 토큰이 브라우저 자원을 과도하게 쓰지 않도록 하는 경계입니다.

이 도구를 검증한 방법

관리 및 검수 SimpleWebUtils검토일 2026년 7월 18일

검증 방법: 검토에서는 수정하지 않은 “JWT를 안전하게 디코딩하기 예시” 샘플을 JWT 디코더: 클레임과 만료 시간 확인에 불러왔습니다. “민감한 값 먼저 가리기”에서 “신뢰하기 전 별도 검증”까지의 흐름을 실행해 화면 또는 다운로드 결과를 예시와 비교했습니다. 별도 조사 항목은 “디코딩을 검증으로 착각”, “Authorization 헤더 전체를 붙여넣는 경우”였습니다.

기대 결과: payload는 인코딩된 sub·scope·aud·exp를 그대로 보여 줬고, 결과에는 claim이 검증되지 않았으며 예제 만료 시각이 지났다는 경고가 계속 표시됐습니다.

공식 출처와 표준

RFC 7519: JSON Web Token (JWT)RFC Editor / IETF

검증한 작업 가이드 열기

다음에 할 작업

바이트를 손상하지 않고 Base64 API payload 디코딩하기

Base64 인코더와 디코더 | UTF-8·Base64URL·Data URI

파일 해시·체크섬 생성기

요청·응답 디버깅용 HTTP 헤더 파서

이 도구 사용 방법

이 도구를 써야 할 때

API 인증 디버깅

OAuth·OpenID Connect 연동

토큰 보안 검토

안전한 디버깅 문서

흔한 실수

디코딩 결과를 검증된 정보로 믿기

페이로드에 비밀정보 넣기

만료 시간만 확인하기

토큰이 선언한 알고리즘을 신뢰하기

JWS와 JWE 형식 혼동하기

예시

UTF-8 클레임과 NumericDate 확인

서명 없는 alg none 토큰 식별

엄격한 디코딩 경계와 신뢰 모델

자주 묻는 질문

JWT 서명을 검증하나요?

토큰이 유효하거나 만료됐는지 판정하나요?

JWT 시간 클레임은 어떻게 표시하나요?

암호화된 JWE도 디코딩하나요?

입력한 JWT가 브라우저 밖으로 전송되나요?

Base64URL 또는 JSON 오류가 나는 이유는 무엇인가요?

입력과 구조 제한은 어떻게 되나요?

이 도구를 검증한 방법

관련 작업 가이드

바이트를 손상하지 않고 Base64 API payload 디코딩하기

SHA-256으로 파일 체크섬 확인하기

JWT를 안전하게 디코딩하기

Unix 타임스탬프로 UTC 장애 타임라인 만들기

JWT 만료와 not-before 타임스탬프 확인하기

이중 인코딩된 쿼리 값 하나를 계층별로 복구하기

관련 도구

Base64 인코더와 디코더 | UTF-8·Base64URL·Data URI

파일 해시·체크섬 생성기

요청·응답 디버깅용 HTTP 헤더 파서

JSON 포매터 | 원문을 보존해 보기 좋게 정리·압축

URL 인코더·디코더 | 정확한 퍼센트 인코딩과 + 규칙