Base64 인코딩이란 무엇인가요?

Base64는 바이너리 데이터를 ASCII 문자열로 변환하는 인코딩 방식입니다. 이메일, URL, HTML 등 텍스트만 지원하는 환경에서 이미지나 파일 데이터를 전송할 때 사용됩니다.

한글도 Base64로 인코딩할 수 있나요?

네, 한글은 UTF-8로 먼저 인코딩한 후 Base64로 변환합니다. 이 도구는 자동으로 UTF-8 처리를 수행하여 한글, 일본어, 중국어 등 다국어를 올바르게 인코딩합니다.

Base64 인코딩의 용도는 무엇인가요?

이메일 첨부파일 전송(MIME), CSS/HTML에 이미지 삽입(Data URI), API 인증(Basic Auth), JSON 데이터에 바이너리 포함 등 다양한 곳에서 사용됩니다.

Base64 인코더/디코더

Base64 인코딩 · 디코딩 — RFC 4648 완전 해부

Base64는 임의의 바이너리 옥텟 시퀀스를 64개의 인쇄 가능한 ASCII 문자(A-Z, a-z,0-9, +, /)와 패딩 문자 =로 표현하는 인코딩 방식입니다.RFC 4648(2006, S. Josefsson)이 표준 알파벳과 변형(Base16, Base32 포함)을 정의하며, 이전의 RFC 2045 §6.8(MIME), RFC 3548을 폐기했습니다. 핵심 원리는 단순합니다. 입력 3바이트(24비트)를 6비트씩 4조각으로 나눠 각 조각을 알파벳 테이블의 인덱스로 매핑합니다. 따라서 출력은 항상 입력의 ⌈n/3⌉ × 4바이트, 즉 약 33.3% 크기 증가를 수반합니다. 이 도구는 브라우저의 btoa()/atob()를 래핑하되, 한글 등 비-Latin1 문자를 UTF-8로 선변환하여 InvalidCharacterError 없이 안전하게 처리합니다.

알파벳 테이블 — 표준 vs URL-safe

RFC 4648은 두 가지 알파벳을 정의합니다.

구분	62번 문자	63번 문자	패딩	사용처
표준 (§4)	`+`	`/`	`=`	MIME, PEM, SAML, S/MIME
URL-safe (§5)	`-`	`_`	생략 가능	JWT, URL 쿼리, 파일명

URL-safe 변형이 필요한 이유는 명확합니다. 표준 Base64의 +는 application/x-www-form-urlencoded에서 공백으로 해석되고, /는 경로 구분자로 취급됩니다. JWT(RFC 7519)의 header·payload는 이 때문에 Base64URL로 인코딩하며, 패딩 =도 제거합니다.

변환 예시 — 바이트 단위로 따라가기

입력 문자열      UTF-8 바이트(hex)        Base64 출력
──────────────────────────────────────────────────────
"Hello"          48 65 6C 6C 6F           SGVsbG8=
"AB"             41 42                    QUI=
"A"              41                       QQ==
"한"             ED 95 9C                 7ZWc
"한글"           ED 95 9C EA B8 80        7ZWc6riA
""               (empty)                  (empty)

패딩 규칙:
  입력 mod 3 = 0  →  패딩 없음
  입력 mod 3 = 1  →  == (2개)
  입력 mod 3 = 2  →  =  (1개)

실전 시나리오 5가지

Data URI — <img src="data:image/png;base64,iVBOR...">로 작은 아이콘을 HTML에 인라인. HTTP 왕복을 제거하지만 캐싱 불가·CSS 번들 증가에 주의
HTTP Basic Auth — Authorization: Basic dXNlcjpwYXNz. user:pass를 Base64 인코딩한 것이며 HTTPS 없이는 평문 노출
JWT 디버깅 — eyJhbGciOiJIUzI1NiJ9를 디코딩하면 {"alg":"HS256"}. header/payload 확인 후 JSON 포매터로 구조 파악
PEM 인증서 — -----BEGIN CERTIFICATE----- 사이의 본문이 Base64. openssl x509 -text로 파싱하기 전에 인코딩 무결성 확인
이메일 첨부(MIME) — RFC 2045에 따라 76문자마다 CRLF 줄바꿈 삽입. 이 도구의 출력에는 줄바꿈이 없으므로 MIME 용도라면 후처리 필요

API 디버깅 — Base64 페이로드 추적

마이크로서비스 간 통신에서 바이너리 페이로드를 JSON 필드에 Base64로 담는 패턴은 흔합니다. gRPC-JSON transcoding에서 bytes 필드는 자동으로 Base64 문자열이 되며, AWS API Gateway의 isBase64Encoded: true 응답도 동일합니다. 디버깅 시 응답 본문을 이 도구에 붙여 넣어 디코딩하면 원본 바이너리의 시작 바이트(magic number)로 파일 타입을 식별할 수 있습니다. 예를 들어 iVBOR로 시작하면 PNG,/9j/로 시작하면 JPEG입니다.

보안 주의 — Base64는 암호화가 아니다

Base64는 가역적 인코딩이므로 비밀번호, API 키, 개인정보를 Base64로 "숨기는" 것은 보안이 아닙니다. 누구나 디코딩할 수 있습니다. Basic Auth 헤더가 HTTPS 위에서만 안전한 이유가 여기에 있습니다. 민감 데이터 전송에는 AES-256-GCM 같은 대칭 암호화나 TLS를 사용하세요. 또한 디코딩 결과를 eval()이나 innerHTML에 직접 넣으면 XSS(Cross-Site Scripting) 공격 벡터가 됩니다. 디코딩 후 반드시 DOMPurify 등으로 새니타이징하거나 textContent로만 렌더링해야 합니다.

브라우저 호환성 — btoa/atob의 한계

JavaScript의 btoa()는 Latin1(ISO 8859-1) 범위(U+0000~U+00FF)만 받습니다. 한글(U+AC00~U+D7A3)을 직접 넣으면 InvalidCharacterError가 발생합니다. 해결책은 encodeURIComponent → percent-encoded 바이트 → String.fromCharCode파이프라인이며, 이 도구가 내부적으로 이 변환을 수행합니다. Node.js 환경이라면Buffer.from(str, 'utf-8').toString('base64')가 더 직관적입니다.

참고 자료

IETF RFC 4648 — The Base16, Base32, and Base64 Data Encodings
IETF RFC 2045 §6.8 — MIME Base64 Content-Transfer-Encoding
IETF RFC 7519 — JSON Web Token (JWT), Base64URL 사용 명세
MDN Web Docs — btoa() / atob() / WindowOrWorkerGlobalScope
OWASP — Cryptographic Failures (A02:2021), Base64 오용 사례