Base64 인코딩 텍스트 변환 실무 활용
Base64 인코딩의 원리와 33% 크기 증가 이유, 이메일 첨부파일·Data URI·JWT 토큰 등 실무 활용 사례를 설명합니다.
Q.Base64 인코딩을 사용하는 이유는 무엇인가요?
Base64는 바이너리 데이터를 ASCII 텍스트로 변환해 텍스트 전용 시스템(이메일, XML, JSON)에서 안전하게 전송하기 위해 사용합니다. 3바이트를 4문자로 변환하므로 데이터 크기가 약 33% 증가하는 단점이 있습니다.
이미지를 CSS에 직접 삽입하거나 API 응답에 파일을 포함시킬 때 Base64를 자주 만난다. RFC 4648 표준에 정의된 Base64 알파벳은 A-Z, a-z, 0-9, +, / 64개 문자다. 이 64개 문자는 모든 ASCII 호환 시스템에서 안전하게 전송된다.
Base64 인코딩 원리
3바이트(24비트) 바이너리를 6비트씩 4개 그룹으로 나눈 뒤, 각 그룹을 Base64 알파벳 문자 하나에 대응시킨다.
- 원본 3바이트 → 인코딩 후 4문자
- 크기 증가율: 정확히 4/3배 = 약 33%
입력 데이터가 3의 배수가 아니면 = 패딩 문자로 채운다.
"Man" → 바이너리 01001101 01100001 01101110
→ 6비트 분할: 010011 010110 000101 101110
→ TWFu
주요 활용 사례
1. 이메일 MIME 첨부파일 (RFC 2045)
이메일 프로토콜 SMTP는 텍스트 전용이다. PDF, 이미지 같은 바이너리 첨부파일을 전송하려면 Base64로 변환해야 한다. 이것이 이메일 첨부파일이 느리게 전송되는 이유 중 하나다(파일 크기 33% 증가).
2. Data URI Scheme
HTML/CSS에서 외부 파일 요청 없이 리소스를 직접 포함할 때 사용한다.
html
<img src="data:image/png;base64,iVBORw0KGgo...">
작은 아이콘(1KB 미만)은 Data URI가 HTTP 요청을 줄여 성능에 유리하다. 큰 이미지는 오히려 파싱 비용이 증가한다.
3. JWT(JSON Web Token)
JWT의 헤더와 페이로드는 Base64URL로 인코딩된다. Base64URL은 기본 Base64에서 + → -, / → _ 로 교체해 URL에서 안전하게 사용할 수 있다.
eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyIjoiYWxpY2UifQ.xxx
JWT는 서명된 데이터이므로 Base64 디코딩으로 내용을 확인할 수 있지만, 변조는 서명 검증으로 방지한다.
4. API 인증 (Basic Auth)
HTTP Basic Authentication은 username:password를 Base64로 인코딩한 값을 Authorization 헤더에 포함한다.
Authorization: Basic dXNlcjpwYXNzd29yZA==
Base64는 암호화가 아니므로 HTTPS 없이 사용하면 디코딩으로 즉시 내용이 노출된다.
Base64 vs Base64URL
| 구분 | 알파벳 | 패딩 | 용도 |
|---|---|---|---|
| Base64 | A-Z a-z 0-9 + / | = | 이메일, Data URI |
| Base64URL | A-Z a-z 0-9 - _ | 생략 가능 | JWT, URL 파라미터 |
디코딩 확인
Base64 문자열이 주어지면 텍스트 도구로 쉽게 디코딩할 수 있다. = 패딩이 있으면 표준 Base64, 없으면 Base64URL일 가능성이 높다.
---
이 글은 AI가 공개 자료를 기반으로 작성했습니다. 보안 관련 활용 시 HTTPS 적용 여부를 반드시 확인하세요.