Base64 가이드
이 실용 가이드는 Base64가 무엇을 하는지, 언제 사용해야 하는지, 실제 데이터 문제를 어떻게 해결하는지 설명합니다. 별도 표시가 없으면 예제는 표준 Base64를 사용합니다.
관련 독립 튜토리얼
1. Base64란 무엇인가
Base64는 바이너리를 텍스트로 표현하는 인코딩입니다. 입력 3바이트마다 A-Z, a-z, 0-9, 더하기(+), 슬래시(/) 중 4개의 출력 문자를 만듭니다. 원본 길이가 3으로 나누어떨어지지 않으면 마지막 그룹에 등호(=) 패딩이 붙습니다. 4문자가 3바이트를 나타내므로 Base64 표현은 보통 약 3분의 1 커집니다. 인코딩은 정보를 숨기지 않으며, 문자열을 가진 사람은 누구나 디코딩할 수 있습니다.
이 형식은 전송 경로가 텍스트를 기대하지만 데이터가 바이너리일 때 유용합니다. 이메일 MIME 파트, JSON 필드, Data URL, 설정 파일, API payload가 흔한 예입니다. 큰 파일에는 크기 증가로 인한 대역폭과 메모리 비용 때문에 덜 적합합니다.
2. 텍스트를 올바르게 인코딩하기
텍스트는 먼저 정해진 문자 집합으로 바이트가 되어야 합니다. UTF-8은 Unicode를 일관되게 표현하므로 현대 애플리케이션의 가장 안전한 기본값입니다. 예를 들어 café는 보이는 문자 자체가 아니라 UTF-8 바이트가 인코딩됩니다.
브라우저에서는 원본 charset을 선택하고 텍스트를 붙여 넣은 뒤 결과를 확인합니다. 줄바꿈은 의도적으로 다루어야 합니다. 전체 문단을 인코딩하는 것과 줄별로 인코딩하는 것은 다른 문자열을 만듭니다. API에서는 charset과 LF/CRLF 정규화 여부를 문서화하세요.
3. 텍스트와 파일 디코딩
디코딩된 바이트가 항상 텍스트는 아닙니다. PNG, PDF, ZIP, 인증서는 정상적으로 디코딩되어도 텍스트 상자에서는 의미 없는 문자처럼 보일 수 있습니다. 입력이 data:application/pdf;base64,... 같은 Data URL로 시작하거나 원본이 바이너리라면 파일용 디코더를 사용하세요.
이메일과 문서 시스템은 Base64에 공백이나 줄바꿈을 넣는 경우가 많습니다. 표준 디코더는 무해한 줄바꿈을 제거할 수 있지만, 알파벳 내부의 우발적인 변경은 데이터를 손상시킵니다. 문제를 볼 때 파일 시그니처와 길이를 비교하세요.
Base64 디코더로 직접 시도해보세요.
4. Base64URL과 패딩
URL은 더하기와 슬래시를 특별하게 처리하므로 Base64URL은 +를 -로, /를 _로 바꿉니다. 많은 생산자는 끝의 패딩도 생략합니다. URL-safe 디코더는 최종 바이트를 만들기 전에 필요한 패딩을 복원해야 합니다.
Base64URL은 JSON Web Token과 URL 매개변수에서 흔히 사용됩니다. 이것은 암호화가 아니며 토큰을 신뢰할 수 있게 만들지도 않습니다. 애플리케이션은 여전히 인증, 권한 확인, 길이 검증, 적절한 암호화 또는 안전한 토큰 설계가 필요합니다.
5. HTML과 CSS의 Data URL
Data URL은 미디어 타입과 인코딩된 payload를 하나의 문자열에 넣습니다. 예: data:image/png;base64,.... 작은 아이콘, 테스트 데이터, 독립 데모에는 편리합니다. 큰 Data URL은 HTML/CSS의 캐싱과 유지보수를 어렵게 하므로 일반 정적 파일이 보통 더 좋습니다.
Data URL을 디코딩할 때는 쉼표 앞의 메타데이터와 Base64 payload를 분리하세요. 미디어 타입은 바이트를 해석하는 방법을 알려줄 뿐, 바이트가 유효하다는 증거는 아닙니다. 신뢰할 수 없는 콘텐츠를 표시하기 전에 파일 시그니처를 검증하세요.
6. API와 JWT의 Base64
API는 바이너리 필드에 Base64를 자주 사용하지만 JSON 자체는 텍스트라 일반 문자열에는 보통 Base64가 필요하지 않습니다. JWT는 점으로 구분된 Base64URL 인코딩 header와 payload를 사용합니다. 이 부분들은 읽을 수 있는 인코딩이지 비밀 저장소가 아닙니다.
API를 통합할 때 패딩 필요 여부, 줄바꿈 허용 여부, 예상 charset, 최대 payload 크기를 기록하세요. 빈 입력, Unicode 텍스트, 1바이트와 2바이트 값, 잘못된 문자를 테스트하세요.
7. 보안과 개인정보
Base64는 많아야 난독화입니다. 메시지를 인증하지 않고, 변조를 막지 않으며, 비밀을 보호하지 않습니다. 디코딩된 콘텐츠는 신뢰할 수 없는 입력으로 취급하고 파싱, 렌더링, 실행 전에 일반 검증을 적용하세요.
기밀 워크플로에는 조직의 통제 아래 있는 로컬 명령줄이나 오프라인 라이브러리를 사용하세요. 전송 보안에는 HTTPS와 데이터에 맞게 설계된 암호화 또는 authenticated encryption을 사용하세요.
8. 일반 오류와 체크리스트
“Invalid character”는 보통 표준 디코더가 URL-safe 문자나 관련 없는 문장부호를 받았다는 뜻입니다. “Incorrect padding”은 문자열이 잘렸거나 끝의 등호가 제거되었을 때 자주 발생합니다. 깨진 텍스트는 charset 불일치일 가능성이 높고, 성공적으로 디코딩되었지만 미리보기가 읽히지 않는다면 단순히 바이너리일 수 있습니다.
진단할 때는 전체 값 복사 여부, 표준/Base64URL 알파벳, 허용된 공백만 제거했는지, 원본 charset, 바이트 길이, 예상 파일 시그니처 순서로 확인하세요. SGVsbG8= 같은 알려진 정상 테스트 값을 보관하세요.
Base64 인코더로 직접 시도해보세요.
const text = "Hello, Base64!";
const encoded = btoa(unescape(encodeURIComponent(text)));
console.log(encoded); // SGVsbG8sIEJhc2U2NCE=
const decoded = decodeURIComponent(escape(atob(encoded)));
console.log(decoded);import base64
value = "你好, Base64"
encoded = base64.b64encode(value.encode("utf-8")).decode("ascii")
decoded = base64.b64decode(encoded).decode("utf-8")
print(encoded)
print(decoded)# Decode a text value on macOS or Linux
printf 'SGVsbG8=' | base64 --decode
# URL-safe decoding in Python
import base64
base64.urlsafe_b64decode("SGVsbG8")콘텐츠 검토: 2026년 8월 30일