PC·모바일 문제 해결
Base64로 인코딩하면 왜 파일 크기가 커질까?
Base64는 바이너리를 보통 약 3분의 1 더 크게 만듭니다. 3바이트가 4문자가 되는 구조, padding, Data URL 오버헤드, 언제 그 용량이 괜찮은지를 봅니다.
Base64는 바이너리 3바이트를 출력 가능한 Base64 문자 4개로 나타내기 때문에, 보통 약 3분의 1 더 커집니다.
입력 길이가 3의 배수가 아니면 표준 padded Base64는 = 문자를 붙일 수 있습니다. 인코딩 길이는 4 × ceil(n / 3)이고, n은 원본 바이트 수입니다.
“약 33%”는 큰 입력을 말할 때입니다. 아주 작은 입력은 padding 때문에 비율이 더 커 보일 수 있습니다. Base64는 압축도 암호화도 아닙니다. 그 질문이라면 [Base64는 암호화가 아닙니다: 실제로 무엇을 하는 걸까?](/ko/story/base64-is-not-encryption)을 보세요.
이 글은 Base64 출력이 원본 바이트보다 커지는 이유를 설명합니다. 보안 안내가 아닙니다. 인코딩과 암호화를 구분하려면 Base64는 암호화가 아닙니다: 실제로 무엇을 하는 걸까?을 보세요.
Base64는 왜 공간이 더 필요할까?
3바이트는 24비트입니다. Base64는 이 24비트를 6비트 그룹 4개로 나눕니다. 각 6비트 그룹이 Base64 문자 하나가 되므로, 입력 3바이트는 출력 문자 4개가 됩니다. 그 ASCII 텍스트를 문자당 1바이트로 저장하면 3바이트가 4바이트가 됩니다. 4 / 3 ≈ 1.333, 약 33.3% 증가입니다.
- 3바이트 (24비트)
- 6비트 그룹 4개로 나눔
- 각 그룹 → Base64 문자 1개
- 문자 4개 (텍스트로 보통 4바이트)
확인 가능한 간단한 예
아래는 표준 padded Base64와 같습니다.
Man
ManBase64
TWFuMan은 UTF-8/ASCII 3바이트입니다. TWFu는 문자 4개입니다. 3 → 4.
Hello
HelloBase64
SGVsbG8=Hello는 5바이트입니다. SGVsbG8=는 = 하나 포함해 문자 8개입니다. 작은 데이터에서는 padding 때문에 33%보다 비율이 커 보입니다.
Base64 크기는 어떻게 계산하나?
표준 padded Base64에서 encodedLength = 4 × ceil(originalBytes / 3)입니다.
| 원본 바이트 | Base64 문자 수 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 4 | 8 |
| 5 | 8 |
| 6 | 8 |
1바이트나 2바이트도 문자 4개가 됩니다. 고정 33%가 아니라 이 공식을 쓰세요.
“=” padding은 무엇을 뜻하나?
= 표시는 마지막 3바이트 블록이 가득 차지 않았음을 나타낼 수 있습니다. 입력 1바이트는 = 두 개, 2바이트는 하나, 3바이트는 없습니다. padding은 암호화도 보안 기능도 아닙니다.
Base64URL은 공간이 덜 드나?
Base64URL은 +를 -, /를 _로 바꾸고, Base64 인코딩은 인코딩 때 끝의 =를 뺍니다. padding을 빼면 그 = 개수만큼 문자열이 짧아질 수 있습니다. 3바이트 → 4문자 구조는 같으므로, Base64URL이 바이너리보다 근본적으로 공간 효율적인 형식은 아닙니다.
아주 작은 입력은 왜 33%보다 더 커 보이나?
1바이트 → 문자 4개는 길이 300% 증가입니다. 2바이트 → 4는 100%입니다. 3바이트 → 4는 약 33.3%입니다. n이 커질수록 padding 영향은 상대적으로 줄고 overhead는 약 33%에 가까워집니다. Base64가 항상 정확히 33% 큰 것은 아닙니다.
Base64 Data URL은 왜 더 크나?
Data URL은 페이로드 앞에 data:image/png;base64, 같은 메타데이터 prefix를 붙입니다. 그 prefix도 Base64 텍스트에 더해지는 문자입니다. 아주 작은 파일에서는 prefix 비율이 더 커 보일 수 있습니다. Base64 인코딩은 raw Base64 또는 Data URL을 만들 수 있고, Data URL 출력은 표준 alphabet을 씁니다.
Base64와 바이너리, 어느 쪽이 작나?
원본 바이너리가 바이너리 전송·저장에는 더 공간 효율적입니다. Base64는 더 크지만 JSON, 이메일, 그 밖의 텍스트 전용 경로에서 텍스트로 안전합니다. Base64의 목적은 binary-to-text encoding이지 압축이 아닙니다.
Base64는 파일을 압축하나?
아닙니다. Base64는 압축 형식이 아닙니다. 인코딩된 텍스트는 보통 원본보다 큽니다. 그 텍스트에 나중에 gzip이나 Brotli를 적용하면 일부 중복이 줄어들 수 있고, 결과는 데이터와 압축기에 따라 다릅니다. gzip이 Base64 overhead를 완전히 없애지는 않습니다.
Base64를 gzip하면 어떻게 되나?
HTTP 압축은 Base64 텍스트의 반복 패턴 일부를 줄일 수 있습니다. JPEG, PNG, ZIP처럼 이미 압축된 바이너리는 원본 바이트도 잘 안 줄어드는 경우가 많고, Base64 후 gzip도 경우에 따라 다릅니다. gzip 이후의 고정 추가 비율은 없습니다.
파일을 Base64로 저장해야 하나?
JSON 필드, 작은 인라인 자산, 텍스트 전용 API, 복사·붙여넣기, Data URL에는 Base64가 맞을 수 있습니다. 큰 파일에서는 저장, 메모리, 파싱, 페이로드가 모두 커집니다. “파일에 Base64를 쓰지 말라”는 뜻은 아닙니다.
JSON API에서 Base64가 흔한 이유
JSON에는 네이티브 raw binary 타입이 없어서, API는 바이트를 Base64 문자열로 넣는 경우가 많습니다. 큰 파일에는 multipart/form-data, 오브젝트 스토리지, 직접 바이너리 업로드가 더 맞을 수 있습니다. 어느 쪽이든 항상 최선은 아닙니다.
이메일에서 Base64를 쓰는 이유
MIME은 바이너리 첨부 파일을 텍스트로 안전한 문자로 보내려고 Base64를 쓸 수 있습니다. 같은 용량 overhead는 그대로입니다. 더 작은 파일이 되는 것이 아니라 전송용 표현입니다.
언제 그 추가 용량이 가치 있나?
바이너리가 텍스트 안에 들어가야 하고, 페이로드가 작고, API 필드가 Base64를 요구하고, Data URL이 필요하거나, 이식 가능한 텍스트 형태가 도움이 될 때 추가 용량이 가치 있을 수 있습니다. 큰 미디어에서 용량 효율이 중요하고 시스템이 허용하면 원본 바이너리 전송이 낫습니다.
언제 Base64를 피하는 것이 좋나?
큰 파일, 빠듯한 대역폭, 잦은 전송, 이미 바이너리 경로가 있을 때는 건너뛰는 편이 나을 수 있습니다. 상황의 문제이지 “Base64는 나쁜 습관”이 아닙니다.
직접 확인할 수 있는 padded Base64 길이
원본 바이트 수와 표준 padded Base64 문자 수:
| 원본 바이트 | Base64 문자 수 |
|---|---|
| 1 | 4 |
| 2 | 4 |
| 3 | 4 |
| 10 | 16 |
| 100 | 136 |
| 1,000 | 1,336 |
모든 행은 4 × ceil(n / 3)을 따릅니다. 길이는 Base64 텍스트 문자 수이며 별도의 메가바이트 단위가 아닙니다.
예: 1,000바이트 파일은 얼마나 커지나?
4 × ceil(1000 / 3). ceil(333.333…) = 334이고 4 × 334 = 1336입니다. 따라서 1,000바이트는 표준 padded Base64에서 문자 1,336개가 됩니다. UTF-8/ASCII로 저장하면 문자는 보통 1바이트이지만, 런타임은 문자당 더 많은 메모리를 쓸 수 있으므로 1,336을 정확한 메모리 바이트로 보지 마세요.
Base64는 파일 크기보다 메모리를 더 쓰나?
어떤 런타임은 문자당 1바이트보다 크게 문자열을 저장합니다. 인코딩·디코딩 중에는 바이너리 버퍼와 문자열이 동시에 있을 수도 있습니다. 메모리 사용량은 Base64 문자 길이와 정확히 같지 않습니다.
간단한 용량 결정 안내
시스템이 원본 바이너리를 받으면 용량을 위해 그것을 쓰세요. 텍스트만 되면 Base64가 맞을 수 있습니다. 페이로드가 크면 바이너리 업로드 경로를 확인하세요. URL 안전 텍스트면 Base64URL을 고려하세요. 3→4 확장은 그대로입니다.
- 바이너리 데이터를 보내야 함
- 원본 바이너리 가능? 용량을 위해 바이너리
- 텍스트 전용 필드? Base64가 맞을 수 있음
- 큰 페이로드? 바이너리 업로드 경로 확인
- URL 안전 텍스트? Base64URL 고려
- 큰 입력에서는 텍스트가 약 33% 더 많다고 기대
Base64는 데이터를 작게 만들려고 설계되지 않았습니다. 텍스트 기반 시스템 안에서 바이너리를 나타내기 쉽게 하고, 그 대가는 추가 용량입니다.
브라우저에서 Base64 인코딩·디코딩
NEXNARA Base64 인코딩는 텍스트를 인코딩·디코딩하고, 파일을 Base64나 Data URL로, Base64를 다시 파일로 바꿀 수 있습니다.
텍스트는 UTF-8 바이트 다음 Base64입니다. “ASCII만”이 아닙니다. Standard 또는 Base64URL을 고르세요. 파일 출력은 raw Base64 또는 Data URL(표준 alphabet)입니다. 잘못된 Base64는 거절됩니다. UTF-8이 아닌 바이트를 텍스트로 디코드하면 실패하니 바이너리는 파일로 모드를 쓰세요.
10 MB를 넘는 파일은 탭이 느려질 수 있습니다(경고). 32 MB를 넘는 파일은 막습니다.
인코딩과 디코딩은 브라우저에서 이루어집니다. 이 도구를 위해 파일이 NEXNARA 서버로 전송되지 않습니다. 광고와 다른 사이트 기능은 네트워크를 사용합니다.
Base64 인코딩에 텍스트나 파일을 넣고 원본 바이트와 인코딩 길이를 비교해 보세요.
FAQ
Base64는 왜 파일 크기가 커지나?
3바이트(24비트)를 문자 4개(4 × 6비트)로 매핑합니다. 텍스트로 저장하면 큰 입력에서 약 3분의 1이 더 큽니다.
Base64는 항상 33% 더 크나?
아닙니다. 큰 입력은 약 33.3%에 가까워집니다. 아주 작은 입력은 padding 때문에 더 커질 수 있습니다. 4 × ceil(n / 3)을 쓰세요.
Base64는 바이너리보다 얼마나 크나?
표준 padded 길이는 문자 4 × ceil(n / 3)개입니다. Data URL prefix가 더해질 수 있습니다. 런타임 메모리는 그 문자 수보다 클 수 있습니다.
Base64 압축은 파일 크기를 줄이나?
Base64는 압축하지 않습니다. 인코딩된 텍스트에 gzip이나 Brotli를 쓰면 일부가 줄어들 수 있지만, 모든 경우 overhead가 사라지지는 않습니다.
Base64URL은 공간이 덜 드나?
= padding을 빼서 문자가 0~2개 짧아질 수 있습니다. 3→4 인코딩 구조는 같습니다.
큰 파일에 Base64를 써야 하나?
텍스트가 필요할 때만입니다. 크거나 잦은 전송에는 바이너리 경로가 더 작은 경우가 많습니다. API에서 Base64가 항상 틀린 것은 아닙니다.