Base64란? — 원리와 URL 인코딩과의 차이
개발 문서나 API 응답에서 aGVsbG8= 같은 외계어를 만난 적 있을 겁니다. 주소창에서는 한글이 %EC%95%88%EB%85%95처럼 변하기도 합니다. 둘 다 "인코딩"이지만 서로 다른 것입니다. 이 글에서 Base64의 원리와 흔한 오해, URL 인코딩과의 차이를 정리합니다.
Base64의 원리
컴퓨터의 모든 데이터는 0과 1(바이너리)입니다. 그런데 이메일·JSON·HTML처럼 텍스트만 안전하게 다룰 수 있는 통로가 많습니다. Base64는 임의의 바이너리 데이터를 알파벳 대소문자(52) + 숫자(10) + '+'와 '/'(2), 총 64개의 안전한 문자만으로 표현하는 변환 규칙입니다.
hello→aGVsbG8=안녕→7JWI64WV
3바이트(24비트)를 6비트씩 4글자로 쪼개 표현하기 때문에 용량이 약 33% 커지고, 길이가 3의 배수로 안 떨어지면 끝을 =(패딩)로 채웁니다. 끝에 붙는 =나 ==는 오류가 아니라 길이 맞춤 기호입니다.
왜, 어디에 쓰나
- 이메일 첨부파일(MIME): 이메일 규격은 텍스트 기반이라, 사진·문서를 Base64로 바꿔 싣습니다.
- 데이터 URI:
data:image/png;base64,...형태로 이미지를 별도 파일 없이 HTML·CSS에 직접 넣습니다. (이미지 ↔ Base64 도구로 만들 수 있습니다) - JWT 토큰: 로그인 토큰의 머리(헤더)·내용(페이로드)이 Base64URL로 인코딩되어 있습니다.
- API 인증: HTTP Basic 인증은 "아이디:비밀번호"를 Base64로 바꿔 헤더에 넣습니다.
가장 큰 오해 — 암호화가 아니다
Base64로 바꾼 문자열은 사람 눈에 못 알아볼 뿐, 누구나 1초 만에 원문으로 되돌릴 수 있습니다. 키도 비밀도 없는 단순 표현 변환이기 때문입니다.
URL 인코딩과의 차이
주소창의 %EC%95%88%EB%85%95은 URL 인코딩(퍼센트 인코딩)입니다. URL에는 쓸 수 있는 문자가 제한되어 있어, 한글·공백·특수문자를 %+16진수 코드로 바꿉니다.
| Base64 | URL 인코딩 | |
|---|---|---|
| 목적 | 바이너리 → 안전한 텍스트 | URL 금지 문자 → 안전한 표기 |
| 대상 | 데이터 전체 | 문제 되는 문자만 |
| '안녕'의 결과 | 7JWI64WV | %EC%95%88%EB%85%95 |
| 흔한 위치 | JWT, 데이터 URI, 메일 | 주소창, 쿼리스트링 |
링크를 복사했더니 %투성이라면 URL 디코딩으로 원래 한글을 복원할 수 있습니다. 둘 다 인코더·디코더에서 양방향으로 변환됩니다.
아닙니다. Base64는 누구나 즉시 원문으로 되돌릴 수 있는 인코딩(표현 방식 변환)일 뿐, 키가 없으면 풀 수 없는 암호화가 아닙니다. 비밀번호나 개인정보를 Base64로 바꿔 저장하는 것은 보안 효과가 전혀 없습니다. 보호가 필요하면 해시(비밀번호)나 암호화(데이터)를 사용해야 합니다.
이미지 등 바이너리 데이터를 텍스트만 다룰 수 있는 곳에 실어 보낼 때 쓰입니다. 대표적으로 이메일 첨부파일(MIME), 웹 페이지에 이미지를 직접 넣는 데이터 URI(data:image/png;base64,...), JWT 토큰, API 인증 헤더 등이 있습니다. 끝의 = 기호는 길이를 맞추기 위한 패딩입니다.
목적이 다릅니다. Base64는 바이너리 데이터를 64개의 안전한 문자로 바꾸는 것이고, URL 인코딩(퍼센트 인코딩)은 주소에 쓸 수 없는 문자(한글·공백 등)를 %로 시작하는 코드로 바꾸는 것입니다. 주소창의 한글이 %EC%95%88처럼 보이는 것이 URL 인코딩이며, 둘은 변환 규칙도 결과도 다릅니다.