Base64 설명: 데이터가 커지는 이유와 디코딩 방법

Base64는 A부터 Z, a부터 z, 0부터 9까지와 +, /를 더한 64개 문자로 이진 데이터를 일반 텍스트로 표현해요. 세 바이트가 네 글자가 되므로 텍스트는 담고 있는 데이터보다 약 3분의 1 길어요. 웹 페이지의 데이터 URL, JSON 필드, 이메일 첨부처럼 텍스트만 받는 형식에서 주로 써요.

Base64 인코딩과 디코딩Base64 문자열을 읽거나 만들기무료로 사용하기

텍스트 형식에 필요한 이유

많은 형식이 처음부터 텍스트만 다루도록 만들어졌어요. 이메일 본문, JSON 파일, CSS 파일은 글자와 기호를 안전하게 담을 수 있지만, 원본 이미지나 zip 파일에는 일부 시스템이 바꾸거나 잘라내거나 제어 코드로 읽어 버리는 바이트 값이 들어 있어요. Base64는 모든 텍스트 시스템이 그대로 통과시키는 문자만 써서 데이터가 손상 없이 전달되게 해줘요. 표준은 RFC 4648에 정의되어 있어요.

Base64는 암호가 아니라 인코딩이에요. 누구나 키 없이 디코딩할 수 있으니 비밀번호나 개인 정보를 숨기는 용도로 쓰면 안 돼요.

세 바이트가 네 글자가 되는 방법

'Man'이라는 단어를 예로 들어 볼게요. 이 단어는 3바이트이고, 10진수로 77, 97, 110이에요. 이 세 바이트는 합쳐서 24비트가 돼요. 24비트를 6비트씩 네 묶음으로 나누면 각 묶음은 0부터 63까지의 숫자가 되고, 이 숫자가 알파벳의 문자 하나를 가리켜요. 그래서 'Man'은 'TWFu'가 돼요.

6비트로는 64가지 값만 표현할 수 있어서 네 글자로 세 바이트를 담게 돼요. 따라서 줄바꿈을 더하기 전에도 출력은 입력보다 약 3분의 1 커져요.

데이터가 3바이트 단위로 딱 떨어지지 않으면 인코더가 끝에 = 기호를 채워요. 2바이트인 'Ma'는 'TWE='가 되고, 1바이트인 'M'은 'TQ=='가 돼요. 이 패딩은 마지막 묶음에 바이트가 몇 개 들어 있는지 디코더에 알려 주는 역할을 해요.

텍스트는 먼저 UTF-8로 인코딩해야 해요

Base64는 바이트를 기준으로 동작하지만, 텍스트는 글자로 이루어져 있어요. 'é'나 '✓' 같은 글자는 웹에서 널리 쓰는 UTF-8에서 한 바이트 이상으로 저장돼요. 브라우저의 btoa() 함수는 문자열의 글자 하나를 바이트 하나로 취급해서, 기본 라틴 문자 범위를 넘는 글자에서 실패해요. 체크 표시에 호출하면 InvalidCharacterError가 발생해요.

해결 방법은 텍스트를 먼저 UTF-8 바이트로 바꾼 다음 그 바이트를 인코딩하는 거예요. 'héllo ✓'라는 문구는 UTF-8로 10바이트이고, 이를 Base64로 바꾸면 'aMOpbGxvIOKckw=='가 돼요. Base64 도구가 이 단계를 자동으로 처리해 줘요. 디코딩할 때도 바이트를 UTF-8 텍스트로 읽어요. 바이트가 올바른 UTF-8 텍스트가 아니면 도구가 파일로 보고 다운로드를 제공해요.

URL에 안전한 Base64

표준 알파벳에는 +와 /가 들어 있어요. URL에서 +는 공백을 뜻할 수 있고, /는 경로의 구분자이기 때문에 Base64 문자열이 링크를 깨뜨릴 수 있어요. URL에 안전한 형식(RFC 4648, 5장)은 대신 -와 _를 쓰고, 보통 = 패딩은 생략해요. 문자열을 URL, 파일 이름, 토큰에 넣을 때 이 형식을 사용하세요. 디코더는 두 형식 모두, 패딩이 있든 없든 받아들여요.

Base64 값이 링크에서 나왔다면 URL을 먼저 디코딩하세요. 링크에서 퍼센트 인코딩된 값은 Base64를 읽기 전에 먼저 디코딩해야 해요. 링크 규칙은 퍼센트 인코딩 가이드에서 자세히 설명해요.

로그인 토큰이 대표적인 예예요. JSON 웹 토큰은 점으로 이어진 Base64url 부분 세 개, 즉 헤더, 데이터, 서명으로 이루어져요. JWT 디코더는 이를 나눠서 헤더와 데이터를 읽기 쉬운 JSON으로 보여 줘요.

데이터 URL과 이미지

데이터 URL은 파일 자체를 링크 안에 넣어요. 형식은 data: 다음에 미디어 타입, ;base64, 쉼표, 데이터 순서예요. 작은 이미지는 data:image/png;base64, 뒤에 인코딩된 바이트가 붙는 형태가 돼요. 웹 페이지와 스타일시트는 이 형식을 받아들이므로, 작은 아이콘을 불러올 때 별도 요청을 줄일 수 있어요.

대신 크기가 문제예요. 데이터는 약 3분의 1 커지고, 브라우저가 캐시할 수 있는 별도 파일이 아니라 페이지나 스타일시트 안에 들어가서 전달돼요. 데이터 URL은 작은 그림에만 쓰고, 큰 사진에는 쓰지 마세요. 사진이 크다면 인코딩하기 전에 사진 용량을 줄이세요.

도구에서 Base64를 디코딩하면 데이터의 앞부분 바이트를 확인해요. PNG, JPEG, GIF, WebP 파일은 각각 정해진 시그니처로 시작하므로, 도구가 미리보기를 보여 주고 다운로드도 제공해요. 이미지 타입의 데이터 URL도 그림으로 표시돼요.

fixmint에서 하는 방법

1. Text or Base64 위에서 Encode 또는 Decode를 고른 다음, 텍스트나 Base64를 붙여 넣으세요.
2. 토큰, 파일 이름, 링크용이라면 URL-safe alphabet, no = padding을 체크하세요. 디코더는 어느 쪽이든 두 형식을 모두 받아들여요.
3. 파일로 데이터 URL을 만들려면 파일을 드롭 영역에 놓고 For files: output a data: URL을 체크하세요.
4. 결과를 복사하세요. 디코딩된 바이트가 텍스트가 아니라 파일이라면 도구가 제공하는 다운로드를 이용하세요.

자주 생기는 디코딩 오류

• 허용되지 않는 문자가 있어요. 입력에 64개 문자 밖의 글자가 들어 있어요. 복사한 문장에서 가져온 따옴표 같은 것이 예예요. 텍스트가 어디에서 왔는지 확인하세요. 복사한 텍스트의 영폭 공백도 같은 오류를 일으키므로, 숨은 문자를 제거한 뒤 다시 시도하세요. 숨은 문자가 어디에서 생기는지는 숨은 문자 가이드에서 다뤄요.
• 길이가 맞지 않아요. 글자가 빠졌거나 더 들어가 있어요. 보통 복사가 중간에 끊겼다는 뜻이에요.
• 줄바꿈과 공백. 이메일(MIME)은 Base64를 76자마다 줄바꿈해요. 디코더가 공백과 줄바꿈을 제거하므로, 줄바꿈된 텍스트를 그대로 붙여 넣어도 돼요.
• 패딩 누락. 일부 시스템은 = 기호를 빼고 보내요. 디코더가 다시 채워 넣어요.

예외 상황

• 디코딩 결과가 이상한 문자열로 보여요. 텍스트가 아니라 파일일 수 있어요. zip 파일, PDF, 프로그램은 디코딩하면 텍스트로 읽히지 않는 바이트가 나와요. 도구는 이런 결과를 다운로드로 제공해요.
• 매우 큰 입력. 인코딩이나 디코딩을 하는 동안 전체 파일이 브라우저 안에 올라가므로, 아주 큰 파일은 느리고 휴대폰에서는 실패할 수 있어요.

빠른 답변

Base64는 암호화와 같은가요?

아니요. 키 없이 되돌릴 수 있는 인코딩이라서 누구나 디코딩할 수 있어요.

왜 Base64 문자열이 원본 파일보다 길어요?

세 바이트마다 네 글자가 되므로 텍스트가 약 3분의 1 커져요.

복사한 Base64 문자열이 왜 디코딩되지 않아요?

보통 복사하는 동안 글자가 빠졌거나 더해진 경우예요. 줄바꿈이 잘못된 자리에 들어갔거나 마지막 글자가 빠진 경우가 흔해요. 원본에서 다시 복사해 보세요.