도구 설명

Base64 to Hex 변환기 정보

Base64 to Hex는 인코딩된 페이로드를 바탕 바이트의 16진수 표현으로 바꿔 줍니다. 덕분에 Base64 문자 더미 안에 무엇이 들었는지 짐작하는 대신, 바이너리 덩어리를 한 바이트씩 읽을 수 있습니다.

양방향 변환을 지원하며, data URI 접두사와 PEM 헤더 줄을 제거하고, 0x 접두사나 구분자가 있든 없든 16진수를 받아들이며, 바이트 수와 함께 선두 바이트가 알려진 시그니처와 맞을 경우 감지된 파일 형식을 알려 줍니다.

Base64 to Hex 사용법

인코딩된 값을 입력란에 붙여 넣습니다. data:image/png;base64, 같은 접두사나 PEM 블록의 BEGIN, END 줄은 자동으로 제거되고 공백은 무시됩니다.
방향 전환 버튼으로 Base64 to Hex와 Hex to Base64 사이를 오갑니다.
16진수 입력은 사용하던 도구가 만들어 낸 형태 그대로 붙여 넣어도 됩니다. 숫자만 있는 형태, 0x 접두사가 붙은 형태, 공백이나 콜론, 하이픈으로 바이트를 나눈 형태 모두 지원합니다.
디버거나 프로토콜 문서가 쓰는 배치에 맞추려면 대문자 출력이나 바이트 사이 간격 옵션을 켭니다.

이럴 때 사용합니다

PEM의 Base64 본문을 16진수로 바꿔 DER 구조를 손으로 따라가며 인증서나 키의 원시 바이트를 살펴볼 때.
확장자를 믿는 대신 파일이나 이미지 앞부분의 매직 넘버를 확인해 실제 형식을 판별할 때.
16진수로 문서화되어 있지만 Base64로 전달되는 바이너리 프로토콜 프레임, 펌웨어 페이로드, 암호 테스트 벡터를 디버깅할 때.
패킷 캡처 도구가 뽑아낸 16진수 덤프를 Base64로 바꿔 설정 파일이나 API 요청 본문에 붙여 넣을 때.

Base64와 16진수가 같은 바이트를 표현하는 방식

둘 다 동일한 바이트 열의 텍스트 표현이지만, 밀도와 가독성 사이에서 정반대 방향의 절충을 택합니다.

Base64는 3바이트를 4문자에 담으므로, 인코딩된 텍스트는 원본 데이터보다 약 33퍼센트 커집니다.
끝에 붙는 = 문자는 패딩이며, 입력 길이가 3의 배수가 아닐 때 추가됩니다.
16진수는 1바이트를 정확히 2문자로 대응시켜 크기는 두 배가 되지만 모든 바이트의 오프셋이 고정됩니다.
이 고정 대응이 디버깅에서 16진수가 유리한 이유입니다. 12번 바이트는 언제나 24번 문자에서 시작하므로, 명세의 오프셋이 화면에 보이는 위치와 그대로 맞아떨어집니다.

Base64 → Hex 자주 묻는 질문

일반 Base64 디코더에서 제 이미지나 인증서가 왜 깨진 글자로 보이나요?: 대부분의 디코더는 결과를 UTF-8 텍스트로 표시합니다. 바이너리 페이로드에는 유효한 텍스트가 아닌 바이트 값이 들어 있어 대체 문자로 표시되거나 망가집니다. 16진수는 그런 문제가 없습니다.
PEM 블록 전체나 data URI를 그대로 붙여 넣어도 되나요?: 됩니다. BEGIN과 END 표시 줄, 그리고 data URI 접두사는 디코딩 전에 제거되고 줄바꿈은 무시됩니다.
반대 방향에서는 어떤 16진수 형식을 받아들이나요?: 0x 접두사, 숫자만 있는 16진수, 그리고 공백이나 콜론, 하이픈으로 구분된 바이트가 모두 동작합니다. 구분자는 바이트를 다시 인코딩하기 전에 제거됩니다.
감지된 파일 형식은 무슨 뜻인가요?: 선두 바이트를 PNG, JPEG, GIF, PDF, ZIP, GZIP, DER의 알려진 시그니처와 대조한 결과입니다. 일치하는 것이 없으면 추측 대신 아무 형식도 표시하지 않습니다.
제 데이터가 어딘가로 업로드되나요?: 아닙니다. 디코딩, 재인코딩, 시그니처 감지가 모두 브라우저 안에서 이루어지므로 키, 인증서, 캡처한 프레임이 wetool.site로 전송되는 일은 없습니다.

Base64 to Hex와 텍스트 중심 Base64 디코더의 차이

범용 Base64 인코더/디코더는 UTF-8 텍스트 경로를 택합니다. Base64를 디코딩한 뒤 결과를 문자열로 해석하는 것입니다. JSON이나 읽을 수 있는 토큰이라면 문제없지만, PNG 헤더나 DER로 인코딩된 인증서, 바이너리 프로토콜 프레임에는 유효한 텍스트 의미가 없는 바이트 값이 들어 있어서 출력이 깨져 나오고 되돌리는 과정에서 바이트가 유실될 수 있습니다. 이 페이지는 텍스트 계층을 아예 건드리지 않습니다. Base64와 16진수를 바이트 수준에서 변환하므로 0x00, 0xFF, 그리고 모든 유효하지 않은 UTF-8 시퀀스가 왕복 변환을 그대로 견딥니다.

16진수 덤프를 바이트 단위로 읽기

페이로드가 16진수로 바뀌고 나면, 앞쪽 몇 바이트만 봐도 지금 다루는 것이 무엇인지 대개 알 수 있습니다.

89 50 4e 47 은 PNG 파일이고, ff d8 ff 는 JPEG 데이터의 시작을 나타냅니다.
25 50 44 46 은 PDF, 50 4b 03 04 는 ZIP 또는 ZIP 기반 컨테이너, 1f 8b 는 GZIP입니다.
선두의 30 82 는 DER 구조의 SEQUENCE 태그로, PEM의 Base64를 디코딩했을 때 인증서나 키 본문이 보이는 모습입니다.
16진수 자릿수가 홀수면 온전한 바이트를 이룰 수 없으므로, 복사한 덤프의 양 끝에서 빠진 자리가 없는지 확인하십시오.