Base64 인코더/디코더
Base64는 64개의 ASCII 문자를 사용하여 바이너리 데이터를 텍스트로 표현하는 인코딩 방식입니다. JSON, XML, URL 등 텍스트 기반 형식에 바이너리 데이터를 삽입하는 데 주로 사용됩니다. 이 도구는 Base64를 디코딩하여 원본 콘텐츠를 확인하고, 결과가 JSON, XML 또는 기타 파싱 가능한 형식인지 자동으로 감지합니다.
사양
주요 사용 사례
- Base64로 인코딩된 API 페이로드 및 웹훅 디코딩
- JWT 토큰의 인코딩된 데이터 검사
- 이메일 첨부 파일 디코딩 (MIME Base64)
- 인코딩된 오류 메시지 및 스택 트레이스 디버깅
- 환경 변수의 인코딩된 설정 값 확인
기능
- 표준 Base64를 UTF-8 텍스트로 디코딩
- URL 안전 Base64 변형 처리 (+ 및 / 대신 - 및 _ 사용)
- 디코딩된 콘텐츠 유형 자동 감지 (JSON, XML 등)
- 구조화된 데이터 감지 시 적절한 파서로 연계
- 텍스트를 Base64로 인코딩
- 디코딩된 바이너리 이미지 데이터 미리보기
- 비-UTF-8 바이너리 데이터용 Hex 뷰어
- 형식 감지 배지 (Standard / URL-Safe / Mixed)
예제
팁
- Base64는 인코딩이지 암호화가 아닙니다. 보안을 제공하지 않습니다.
- 끝의 = 패딩은 일부 구현에서 생략될 수 있습니다.
- URL 안전 Base64는 URL 인코딩 문제를 피하기 위해 +를 -로, /를 _로 대체합니다.
- Base64는 데이터 크기를 약 33% 증가시킵니다.
이해하기 Base64 인코더/디코더
Base64는 RFC 4648에 정의된 바이너리-텍스트 인코딩 방식으로, 64개의 인쇄 가능한 ASCII 문자(A-Z, a-z, 0-9, +, /)와 패딩 문자(=)를 사용하여 임의의 바이너리 데이터를 표현합니다. 주요 목적은 이메일, JSON 페이로드, XML 문서, URL 매개변수 등 원시 바이트를 올바르게 처리하지 못할 수 있는 텍스트 기반 시스템을 통해 바이너리 데이터를 전송하는 것입니다.
인코딩 과정은 입력의 3바이트(24비트)마다 4개의 6비트 그룹으로 나눕니다. 각 6비트 값은 64개 문자 중 하나에 매핑됩니다. 입력 길이가 3바이트의 배수가 아닌 경우, 출력을 4문자의 배수로 맞추기 위해 하나 또는 두 개의 = 문자로 패딩합니다. 이는 Base64 인코딩된 데이터가 원본보다 약 33% 더 크다는 것을 의미합니다.
두 가지 주요 변형이 존재합니다. 표준 Base64는 +와 /를 사용하며 MIME 이메일 인코딩에 사용됩니다. URL 안전 Base64(base64url)는 URL 예약 문자를 피하기 위해 +를 -로, /를 _로 대체합니다. JWT 토큰은 패딩 없이 URL 안전 변형을 사용합니다. 일부 구현에서는 원본 데이터 길이를 추론할 수 있으므로 후행 = 패딩을 생략합니다.
Base64는 웹 개발 전반에 나타납니다. 데이터 URI는 HTML/CSS에 이미지와 글꼴을 삽입합니다. JWT 토큰은 세 개의 Base64url 인코딩된 세그먼트입니다. SAML 메시지는 Base64로 인코딩된 XML입니다. API 응답은 JSON 내에서 바이너리 콘텐츠를 Base64로 인코딩할 수 있습니다. 중요한 것은 Base64는 인코딩이지 암호화가 아니라는 것입니다. 보안이나 기밀성을 전혀 제공하지 않습니다.
Base64는 암호화의 한 형태가 아니며 절대 그렇게 취급해서는 안 됩니다. 키나 비밀 없이 데이터를 다른 표현으로 변환할 뿐이며, 누구나 Base64 문자열을 즉시 디코딩할 수 있습니다. 민감한 데이터가 Base64로 인코딩되어 있다면 완전히 노출된 것입니다. 비밀을 유지해야 하는 데이터에는 AES나 RSA 같은 실제 암호화 알고리즘을 사용하세요. 표준 Base64는 62번과 63번 문자로 +와 /를 사용하고, URL 안전 Base64(base64url, RFC 4648 섹션 5에 정의)는 URL에서 +와 /가 특별한 의미를 가지므로 -와 _로 대체합니다. JWT 토큰은 항상 패딩 없이 URL 안전 변형을 사용합니다.
= 패딩 문자는 인코딩된 출력 길이가 항상 4문자의 배수가 되도록 보장합니다. Base64는 3바이트를 4문자로 인코딩하므로, 길이가 3의 배수가 아닌 입력에는 패딩이 필요합니다: 나머지 1바이트는 ==를 생성하고, 나머지 2바이트는 =를 생성합니다. JWT를 포함한 일부 구현에서는 디코더가 인코딩된 문자열 길이에서 원본 길이를 계산할 수 있으므로 패딩을 완전히 생략합니다.
33% 크기 증가는 인코딩에 내재된 특성입니다: 3바이트(24비트)마다 4개의 ASCII 문자(32비트)가 되어 고정 4/3 확장 비율이 되며, 이를 줄일 수 없습니다. 크기가 문제라면 인코딩 전에 데이터를 압축하세요. 대용량 바이너리 자산의 경우 텍스트 형식에 Base64를 삽입하는 것보다 멀티파트 업로드나 바이너리 WebSocket 프레임 같은 적절한 바이너리 전송 메커니즘을 고려하세요.