이미지 Base64 변환, 용량이 정확히 33% 커지는 이유
이미지 파일을 텍스트 상자 안에 그대로 붙여넣고 싶을 때가 있습니다. 이메일 본문에, JSON 응답값 안에, CSS 파일 속성값 안에 이미지를 통째로 실어 보내고 싶은 경우입니다. 그런데 이미지는 원래 텍스트가 아니라 순수한 이진 데이터(바이너리)입니다. 이 바이너리를 텍스트만 안전하게 지나가는 통로에 밀어 넣으려면 별도의 변환이 필요한데, 그게 바로 Base64 인코딩입니다.
이 변환을 거치면 이미지는 문자열 하나처럼 편하게 다룰 수 있지만, 대신 용량이 늘어납니다. 그것도 대략적인 어림값이 아니라, 계산으로 정확히 나오는 비율만큼 늘어납니다.
요약 ① Base64는 8비트 단위 바이트를 6비트 단위로 재포장해서, 이미지 같은 바이너리를 텍스트 전용 통로(이메일·JSON·CSS)에 실어 보내는 인코딩입니다. ② 3바이트(24비트)가 6비트 묶음 4개, 즉 문자 4개로 바뀌기 때문에 용량은 산술적으로 정확히 4/3배(약 33% 증가)가 됩니다. ③ 이 증가율은 파일 크기와 무관하게 고정이라, 몇 KB짜리 아이콘에는 유리하지만 몇 MB짜리 사진에는 그만큼 손해가 커집니다.
텍스트 통로에 바이너리를 태워야 하는 이유
이메일 첨부값, JSON 문자열, CSS 속성값에는 공통점이 있습니다. 전부 텍스트만 안전하게 통과할 수 있는 자리라는 점입니다. 이미지 원본 바이트에는 화면에 보이지 않는 제어 문자나, 통로 중간에서 다른 의미로 해석될 수 있는 값이 섞여 있을 수 있습니다.
이런 바이트를 텍스트 자리에 그대로 밀어 넣으면 중간에서 잘리거나 손상될 위험이 있습니다. Base64는 이 문제를 우회합니다. 원본 값이 무엇이든 상관없이, 영문 대소문자·숫자·기호 몇 개로만 이루어진 64종류의 안전한 문자만으로 다시 표현하는 방식입니다. 그래서 결과물은 항상 사람이 읽을 수 있는 순수 텍스트이고, 이메일이든 JSON이든 CSS든 안전하게 지나갈 수 있습니다.
8비트를 6비트로 나누면 정확히 왜 33% 커지는가
이미지 파일은 8비트짜리 바이트가 죽 늘어선 이진 데이터입니다. 8비트로 표현 가능한 값은 0부터 255까지 총 256가지입니다. 반면 Base64가 쓰는 안전한 문자는 64개(A-Z, a-z, 0-9, +, /)뿐입니다. 64가지 값을 구분하는 데는 6비트면 충분합니다(2의 6제곱이 64이기 때문입니다).
그래서 Base64는 원본을 8비트 단위가 아니라 6비트 단위로 다시 잘라서 읽습니다. 이걸 3바이트 단위로 묶으면 계산이 딱 맞아떨어집니다. 3바이트는 8비트씩 3개, 즉 24비트입니다. 이 24비트를 6비트씩 나누면 정확히 4묶음이 나옵니다. 원래 3바이트였던 데이터가 6비트 묶음 4개, 즉 Base64 문자 4개로 바뀌는 것입니다.
정리하면 "3바이트가 4문자로" 바뀝니다. 늘어난 비율은 4를 3으로 나눈 값, 즉 4/3 = 1.333...배이고 퍼센트로는 약 33.3% 증가입니다. 이 숫자는 이미지 종류나 압축 방식과 무관하게, Base64로 바꾸는 순간 그대로 적용되는 산술적 결과입니다. (원본 바이트 수가 3의 배수가 아니면 마지막 자리를 = 문자로 채우는 처리가 조금 더 붙지만 전체 비율에 미치는 영향은 미미합니다.)
그래서 작은 아이콘엔 유리하고 큰 사진엔 불리하다
이 4/3배 비율 자체는 파일이 크든 작든 항상 똑같이 적용됩니다. 하지만 늘어나는 절대 용량은 원본 크기에 비례해서 커집니다. 예를 들어 30KB짜리 아이콘이라면 30 × 4/3 = 40KB로, 늘어나는 양은 10KB 정도라 별도 파일 요청 하나를 줄이는 이득이 더 크게 느껴집니다.
반대로 300KB짜리 사진이라면 400KB가 되어 100KB가 그냥 불어납니다. 게다가 이미지를 Data URI로 CSS나 HTML 안에 박아 넣으면 그 문서 자체가 통째로 커질 뿐 아니라, 브라우저가 이미지 파일을 별도로 캐싱해 재사용하는 이점도 사라집니다. 아이콘·로고처럼 작고 자주 재사용되는 이미지에는 잘 맞고, 사진처럼 크고 한 번만 쓰이는 이미지에는 잘 맞지 않는 이유입니다.
직접 계산기를 두드리지 않아도, 실제 이미지를 넣어보면 이 비율이 내 파일에서 얼마나 되는지 바로 확인할 수 있습니다.
이미지를 끌어다 놓으면 즉시 Base64 Data URI와 <img>·CSS 스니펫까지 함께 생성해 복사할 수 있습니다.
도구가 이 계산을 대신 처리하는 방식
이미지 → Base64 도구는 지금까지 설명한 8비트→6비트 재포장 과정을 브라우저 안에서 그대로 수행합니다. 이미지를 끌어다 놓거나 클릭해서 선택하면, 별도의 변환 버튼을 누르지 않아도 파일을 읽는 즉시 Base64 Data URI로 바뀐 결과가 화면에 나타납니다.
결과 화면에는 원본 파일의 MIME 타입, 원본 크기, 그리고 변환된 Base64 길이가 나란히 표시됩니다. 두 크기를 나란히 비교해 보면 앞서 설명한 4/3배 증가가 실제 숫자로 확인됩니다. 변환된 이미지 자체도 작게 미리보기로 나와서 어떤 파일이 바뀐 결과인지 바로 알 수 있습니다.
결과는 그대로 코드에 옮길 수 있는 형태로도 함께 나옵니다. Data URI 문자열 전체, <img> 태그에 바로 넣을 수 있는 스니펫, CSS의 background-image 속성에 넣을 수 있는 스니펫이 각각 복사 버튼과 함께 준비되어 있어서, 코드 에디터에 붙여넣기만 하면 됩니다. 변환은 브라우저 안에서만 처리되고 파일이 서버로 전송되지 않습니다.
정리
- Base64는 8비트 바이트를 6비트 단위로 재포장해서 바이너리를 텍스트 전용 통로에 실어 보내는 인코딩입니다.
- 3바이트(24비트)가 6비트 묶음 4개, 즉 Base64 문자 4개로 바뀌므로 용량은 정확히 4/3배(약 33%) 커집니다.
- 이 증가율은 파일 크기와 무관하게 고정이라 원본 크기만 알면 결과 크기를 미리 계산할 수 있습니다.
- 몇 KB 수준의 작은 아이콘·로고는 늘어나는 절대 용량이 작아 HTML/CSS에 직접 넣어 요청 수를 줄이는 데 유리합니다.
- 몇백 KB~MB 단위의 사진은 늘어나는 절대 용량도 크고 별도 캐싱 이점도 사라지므로, 일반 이미지 파일로 두는 편이 유리합니다.
이미지를 끌어다 놓으면 즉시 Base64 Data URI와 <img>·CSS 스니펫까지 함께 생성해 복사할 수 있습니다.
자주 묻는 질문
data URI란 정확히 무엇인가요?
data URI는 "data:이미지 형식;base64,인코딩된 문자열" 형태로, 이미지 데이터 자체를 하나의 문자열 안에 담은 표현입니다. 다른 파일을 가리키기만 하는 일반 URL과 달리 이 문자열 자체가 이미지 데이터를 전부 포함하고 있어서, HTML의 src나 CSS의 background-image 속성에 파일 경로 대신 그대로 넣을 수 있습니다.
왜 하필 33%가 늘어나나요? 다른 비율이 될 수도 있나요?
아닙니다. 8비트 바이트를 6비트 단위로 재포장하는 방식 자체가 3바이트를 4문자로 바꾸는 구조이기 때문에, 늘어나는 비율은 항상 4/3배(약 33%)로 고정됩니다. 이미지 종류나 압축 방식과 관계없이 Base64로 인코딩하는 모든 데이터에 똑같이 적용되는 산술적 결과입니다.
이미지를 무조건 Base64로 바꿔서 쓰는 게 좋은가요?
아닙니다. 아주 작은 아이콘이나 로고처럼 파일 하나를 추가로 요청하는 부담이 더 크게 느껴지는 경우에는 33% 늘어난 용량을 감수할 만합니다. 하지만 사진처럼 원본 자체가 큰 이미지는 늘어나는 절대 용량도 크고, 브라우저가 이미지 파일을 별도로 캐싱하는 이점도 사라지므로 일반적인 이미지 태그로 불러오는 편이 유리합니다.
변환한 이미지가 서버에 저장되나요?
아니요. 변환은 브라우저 안에서 파일을 읽어 문자열로 바꾸는 과정으로 끝나며, 이미지 파일이 서버로 전송되거나 저장되지 않습니다. 페이지를 새로고침하면 입력했던 이미지와 결과 모두 사라집니다.