Base64 인코더·디코더

Base64는 암호화가 아닙니다

가장 먼저 짚어야 할 점입니다. Base64는 누구나 되돌릴 수 있는 인코딩이며 비밀을 지켜주지 않습니다.

비밀번호나 API 키를 Base64로 감싸는 것은 보안 조치가 되지 못합니다. 어떤 도구로도 1초 만에 원본이 나옵니다. 실제로 유출 사고에서 "암호화했다"고 주장했다가 Base64였던 사례가 반복적으로 나옵니다.

암호화가 필요하다면 AES 같은 실제 암호 알고리즘을, 단방향 변환이 필요하다면 해시를 써야 합니다.

그럼 Base64는 왜 쓰나요

바이너리 데이터를 텍스트만 다룰 수 있는 통로로 옮기기 위해서입니다.

이메일(SMTP), JSON, XML, URL 같은 곳은 원래 텍스트를 전제로 설계되었습니다. 이미지나 실행 파일의 바이트를 그대로 넣으면 제어 문자 때문에 깨집니다.

Base64는 3바이트를 4개의 안전한 문자로 바꿔 이 문제를 해결합니다. 대신 데이터 크기가 약 33% 늘어납니다.

대표적인 용도는 이렇습니다.

• 이메일 첨부파일 — MIME 인코딩
• Data URI — HTML/CSS에 이미지를 직접 삽입 (data:image/png;base64,...)
• HTTP Basic 인증 — 사용자명:비밀번호를 Base64로 (그래서 HTTPS가 필수입니다)
• JWT — 헤더와 페이로드
• API 응답에 바이너리 담기

한글이 깨지는 이유

브라우저의 기본 함수 btoa()는 1바이트 문자만 처리합니다. 한글이나 이모지를 넣으면 예외가 발생하거나 깨진 결과가 나옵니다.

올바른 방법은 먼저 UTF-8로 인코딩한 뒤 Base64로 변환하는 것입니다. 이 도구는 그렇게 처리하므로 한글, 이모지, 일본어, 중국어 모두 정상적으로 왕복됩니다.

다른 곳에서 만든 Base64가 깨진다면, 그쪽에서 UTF-8 처리를 빠뜨렸을 가능성이 큽니다.

URL-safe Base64

표준 Base64는 +와 / 문자를 씁니다. 그런데 이 두 문자는 URL에서 다른 의미를 갖습니다. +는 공백으로 해석될 수 있고 /는 경로 구분자입니다.

그래서 URL에 담을 때는 URL-safe 변형을 씁니다.

| 표준 | URL-safe | |---|---| | + | - | | / | _ | | = 패딩 | 생략 |

JWT와 OAuth 토큰이 이 방식을 씁니다. 두 형식은 호환되지 않으므로 디코딩할 때 종류를 맞춰야 합니다. 이 도구는 -나 _가 보이면 자동으로 URL-safe로 판단해 디코딩합니다.

끝에 붙는 = 는 뭔가요

패딩입니다. Base64는 3바이트씩 묶어 4문자로 바꾸는데, 원본 길이가 3의 배수가 아니면 남는 자리가 생깁니다. 이를 =로 채워 전체 길이를 4의 배수로 맞춥니다.

• 원본이 3의 배수 → 패딩 없음
• 나머지 1바이트 → ==
• 나머지 2바이트 → =

패딩이 없어도 대부분의 디코더는 길이로 유추해 처리합니다. URL-safe 방식은 아예 패딩을 생략합니다.

Data URI로 이미지 넣기

작은 아이콘을 HTML에 직접 넣을 때 씁니다.

<img src="data:image/png;base64,iVBORw0KGgo...">

HTTP 요청 하나를 줄일 수 있어 아주 작은 이미지에는 유리합니다. 다만 크기가 33% 늘고 브라우저 캐시를 활용할 수 없어, 몇 KB를 넘는 이미지에는 오히려 손해입니다.

함께 확인하면 좋은 것

JWT 토큰의 내용을 보려면 JWT 디코더가 편합니다. 되돌릴 수 없는 변환이 필요하다면 해시 생성기를, JSON 정리는 JSON 포맷터를 이용하세요.