개발자
🔐 Base64 인코더/디코더
텍스트 ↔ Base64 즉시 변환 + URL 안전 모드.
Base64 인코딩 원리
Base64는 바이너리 데이터를 64개의 ASCII 문자(A-Z, a-z, 0-9, +, /)로 표현하는 인코딩 방식입니다. 텍스트 기반 시스템에서 이진 데이터를 안전하게 전송하기 위해 1987년 RFC 1421(PEM)에서 처음 정의되었으며, 현재는 RFC 4648 표준입니다.
Base64 주요 사용 사례
📧 이메일 첨부파일
MIME 표준에서 이미지·문서를 7-bit ASCII로 안전하게 전송
🔑 JWT 토큰
JSON Web Token의 헤더·페이로드를 URL-safe Base64로 인코딩
🖼️ 이미지 Data URI
HTML/CSS에 이미지를 직접 임베드 (data:image/png;base64,...)
🔐 HTTP Basic 인증
Authorization 헤더에 user:password를 Base64로 전송
📦 PDF 임베드
API 응답에 PDF 바이너리를 텍스트로 포함
🔒 PEM 인증서
X.509 인증서·SSH 키를 텍스트 파일로 저장
표준 Base64 vs URL-safe Base64
| 항목 | 표준 Base64 | URL-safe (RFC 4648 §5) |
|---|---|---|
| 치환 | +, /, = | -, _, (없음) |
| 패딩 (=) | 항상 포함 | 생략 가능 |
| URL/파일명 | ⚠️ 인코딩 필요 | ✓ 그대로 사용 |
| 주요 사용처 | 이메일·일반 | JWT·OAuth·URL |
SGVsbG8/V29ybGQ+ → URL-safe SGVsbG8_V29ybGQ-JWT(JSON Web Token) 구조
HEADER
알고리즘(alg)·토큰 타입(typ). 예: HS256, RS256
PAYLOAD (Claims)
사용자 정보·만료 시간(exp)·발급(iat)·발급자(iss)·대상(aud)
SIGNATURE
HEADER.PAYLOAD를 비밀키로 서명. 위변조 검증용.
이미지 Data URI 활용
✅ 적합한 경우
- 작은 아이콘 (< 5KB)
- CSS 배경 이미지 단일 파일
- 오프라인 HTML 이메일 템플릿
- 캐시 분리가 불필요한 경우
❌ 부적합한 경우
- 큰 이미지 (> 50KB)
- 여러 페이지에서 재사용
- 브라우저 캐싱이 중요할 때
- 이미지 최적화·CDN 활용 필요
인코딩 방식 비교 ("Hi" 기준)
| 인코딩 | 결과 | 주요 용도 |
|---|---|---|
| Base64 | SGk= | 이메일·일반 바이너리 전송 |
| Base64 URL | SGk | JWT·URL 파라미터 |
| Hex | 4869 | 해시·암호화·디버깅 |
| Binary | 01001000 01101001 | 교육·로우레벨 분석 |
| URL Encoded | Hi (변경 없음) | 쿼리 스트링 (특수문자만 변환) |
| HTML Entity | Hi (변경 없음) | HTML 본문 안전 삽입 (<> 등) |
⚠️ Base64는 암호화가 아닙니다
흔한 오해: "Base64는 암호화 같다"라고 생각하는 경우가 있지만, 사실 Base64는 단순 인코딩이며 누구나 디코딩할 수 있습니다.
- 비밀번호·API 키·신용카드 정보를 Base64로 "감춰서" 저장하는 것은 보안에 도움이 되지 않습니다
- JWT의 PAYLOAD는 누구나 디코딩 가능 — 민감 정보 포함 금지
- 실제 보호가 필요하면 HTTPS, 암호화(AES·RSA), 해싱(bcrypt·argon2)을 사용하세요
자주 묻는 질문 (FAQ)
Q1. Base64로 인코딩하면 파일 크기가 왜 커지나요?
Base64는 3바이트(24비트)를 4문자(6비트 × 4)로 표현하므로 항상 4/3 = 약 33% 커집니다. 10MB 파일은 약 13.3MB가 되며, 줄바꿈·패딩까지 포함하면 더 늘어날 수 있습니다. 따라서 큰 파일은 Base64 대신 multipart/form-data나 파일 업로드 API를 사용하는 것이 효율적입니다.
Q2. JWT 토큰을 디코딩해도 보안에 문제 없나요?
JWT의 HEADER와 PAYLOAD는 암호화가 아닌 인코딩이므로 누구나 디코딩할 수 있습니다. 토큰 보유자가 내용을 보는 것은 정상이지만, PAYLOAD에 민감 정보(비밀번호, 신용카드 등)를 절대 포함하면 안 됩니다. 토큰의 무결성은 SIGNATURE로 보장되며, 서명 검증은 비밀키가 필요합니다. 본 도구는 디코딩만 수행하며 서명 검증은 하지 않습니다.
Q3. 한글을 Base64로 인코딩하면 깨지는 이유는?
브라우저 기본 btoa()는 ASCII 외 문자를 처리하지 못하는 한계가 있습니다. 본 도구는 UTF-8로 먼저 변환한 후 Base64 인코딩하므로 한글·이모지·특수문자도 안전합니다. 디코딩 시에도 동일한 방식을 사용해야 깨지지 않습니다. btoa(unescape(encodeURIComponent(text))) 패턴이 표준입니다.
Q4. URL-safe Base64는 언제 사용하나요?
표준 Base64에 포함된 +, /, =가 URL이나 파일명에서 특수한 의미를 가지므로 인코딩이 추가로 필요합니다. URL-safe는 이를 -, _로 치환하고 패딩을 생략해 그대로 URL이나 파일명에 사용할 수 있습니다. JWT, OAuth, URL 파라미터, S3 사전 서명 URL 등에서 표준입니다.
Q5. 이미지를 Base64 Data URI로 임베드하는 게 좋을까요?
경우에 따라 다릅니다. 5KB 이하 작은 아이콘은 HTTP 요청 절감·CSS 통합 면에서 유리하지만, 50KB 이상 큰 이미지는 ① 33% 크기 증가, ② 캐시 분리 불가, ③ 페이지 초기 로딩 지연 등의 단점이 큽니다. 일반적으로 SVG 아이콘 단일·이메일 템플릿은 Data URI, 일반 이미지는 CDN 사용을 권장합니다.