브라우저 개발자 도구를 열고 아무 사이트의 네트워크 요청을 보면, 거의 확실하게 어딘가에서 긴 Base64 문자열을 찾을 수 있습니다——Authorization 헤더의 Bearer token, CSS의 data URL, API가 반환하는 이미지 필드 등. Base64는 어디에나 있습니다.
1. Base64란 무엇인가? 「왜 필요한가」부터 이해하기
초기의 많은 통신 프로토콜(SMTP, HTTP/1.1)은 순수 텍스트(ASCII) 전송만을 고려해 설계되었습니다. 이미지나 PDF 등의 바이너리 데이터를 전송하려면 변환이 필요했습니다. Base64는 3바이트(24비트)의 바이너리 데이터를 4개의 6비트 숫자로 재그룹화하여, 64개 문자 알파벳(A–Z, a–z, 0–9, +, /)으로 표현합니다. 결과：모든 바이너리 데이터를 텍스트 문자로 표현할 수 있습니다.
| 특성 | 설명 |
|---|---|
| 문자 집합 | A–Z(26), a–z(26), 0–9(10), +, / 총 64개 |
| 패딩 문자 | =, 3의 배수로 맞추기 위해 |
| 크기 증가 | 원본 데이터보다 약 33% 증가 |
직접 시도해보기：Base64 인코더/디코더 도구로 임의의 텍스트나 데이터를 인코딩하거나, Base64 문자열을 원래 내용으로 디코딩할 수 있습니다.
2. 이메일 첨부파일 속의 Base64 (MIME)
SMTP 프로토콜은 원래 7비트 ASCII 텍스트만 지원했습니다. 첨부파일 전송에는 MIME 표준이 필요하며, MIME 첨부파일은 일반적으로 Base64로 인코딩됩니다. 「원본 이메일 보기」에서 보이는 긴 문자열이 Base64로 인코딩된 파일 내용입니다.
3. JWT Token：로그인 시스템에서 가장 흔한 Base64
JWT는 .으로 구분된 3개의 Base64url 부분으로 구성됩니다. 첫 두 부분을 디코딩하면：
헤더: {"alg":"HS256","typ":"JWT"}
페이로드: {"sub":"user123","exp":1748000000}중요：JWT의 처음 두 부분은 암호화되지 않아 누구나 디코딩할 수 있습니다. 세 번째 서명 부분만 변조 감지에 사용됩니다. JWT에 비밀번호나 민감한 데이터를 넣어서는 안 됩니다.
JWT 디코딩：JWT의 첫 번째 또는 두 번째 부분을 Base64 디코더 도구에 붙여넣으면 JSON 내용을 바로 확인할 수 있습니다. JSON 포매터로 구조를 더 명확히 읽을 수도 있습니다.
4. Data URL：HTML/CSS에 내장된 이미지
Data URL은 파일 전체를 HTML이나 CSS에 직접 내장할 수 있어 추가 HTTP 요청이 불필요합니다：
<img src="data:image/png;base64,iVBORw0KGgo...">5. Base64에 대한 흔한 오해
- Base64는 암호화가 아닙니다：인코딩입니다. 키 없이 누구나 즉시 디코딩 가능
- Base64는 데이터를 압축하지 않습니다：오히려 약 33% 증가
- 끝의
=은 정렬 패딩이지 암호화 기호가 아님 - URL에서는 Base64url 변형 사용：
+와/대신-와_
URL 인코딩 처리：URL 인코더/디코더 도구로 URL의 특수 문자를 변환할 수 있습니다.
정리
- Base64는 바이너리 데이터를 64개의 텍스트 문자로 변환하여 텍스트 전용 프로토콜에서 전송 가능하게 함
- 이메일 첨부(MIME), JWT Token, Data URL, Basic Auth가 가장 일반적인 용도
- JWT의 헤더와 페이로드는 Base64url 인코딩일 뿐——암호화 없음
- Base64는 암호화가 아니며, 데이터 크기는 33% 증가