Base64 인코딩 디코딩 원리와 결과 읽는 법

Base64로 인코딩된 문자열을 보고 이게 무슨 뜻인지 궁금하거나, 반대로 텍스트를 Base64로 바꿔서 어딘가에 넣어야 하는 사람을 위한 글입니다.

결과 문자열이 원본보다 길어지는 이유와 끝에 붙는 '=' 기호의 정체를 계산 과정으로 직접 확인할 수 있습니다. 암호화와 헷갈리기 쉬운 부분도 함께 정리했습니다.

요약 ① Base64는 원문을 8비트 바이트로 쪼갠 뒤 6비트씩 묶어 64개 문자표로 다시 표현하는 인코딩 방식입니다. ② 6비트 단위로 나누기 때문에 결과 문자열은 원본보다 약 4/3배(약 33%) 길어집니다. ③ Base64는 암호화가 아니라 표현 방식만 바꾸는 것이라, 별도 키 없이 누구나 원문으로 되돌릴 수 있습니다.

어디서 이 문자열을 마주치게 되나

웹페이지 소스나 API 응답을 열어보면 "data:image/png;base64,iVBORw0KGgo..."처럼 시작하는 긴 문자열이나, "eyJhbGciOiJIUzI1NiJ9..."처럼 생긴 문자열을 보게 되는 경우가 있습니다. 사람이 읽을 수 있는 언어가 아니라서 암호나 오류 메시지처럼 보이기 쉽습니다.

반대 방향도 있습니다. 텍스트나 파일을 이메일 첨부, API 전송, 데이터 URI 등의 형태로 옮겨야 할 때 Base64로 바꾸면, 결과 문자열이 원본보다 눈에 띄게 길어져서 "제대로 변환된 게 맞나" 의심하게 됩니다.

끝에 붙는 '='도 오류처럼 보입니다.

두 경우 모두 답은 같습니다. Base64가 어떤 계산을 거쳐 그 문자열을 만들어내는지 순서대로 따라가 보면, 왜 그렇게 생겼는지가 그대로 설명됩니다.

Base64가 실제로 계산되는 방식

전체 과정은 다섯 단계로 정리됩니다.

1. 원문을 바이트로 바꿉니다(UTF-8 기준. 영문·숫자는 1바이트, 한글은 대개 3바이트입니다).
2. 각 바이트를 8비트 이진수로 늘어놓습니다.
3. 이진수 전체를 앞에서부터 6비트씩 끊습니다.
4. 6비트 값(0~63)을 아래 64개 문자표에서 찾아 해당 문자로 바꿉니다.
5. 3바이트(24비트) 단위가 맞지 않고 남으면, 부족한 자리를 '=' 로 채워 전체 길이를 4의 배수로 맞춥니다.

문자표는 이렇게 구성됩니다.

직접 계산해보기 — "Cat"

"Cat"은 C, a, t 세 글자이므로 정확히 3바이트(24비트)입니다.

• C = 67 = 01000011
• a = 97 = 01100001
• t = 116 = 01110100

세 바이트를 이어 붙이면 24비트가 됩니다.

010000110110000101110100

이 24비트를 앞에서부터 6비트씩 네 조각으로 끊습니다.

010000 110110 000101 110100

각 조각을 10진수로 바꾸면 16, 54, 5, 52입니다. 문자표에서 찾으면 16=Q, 54=2, 5=F, 52=0이 되어 결과는 Q2F0 입니다. 실제로 이 도구의 인코딩 모드에 "Cat"을 넣으면 같은 결과가 나옵니다.

문자 수가 늘어나는 이유

3바이트가 정확히 4글자로 바뀌었다는 점이 핵심입니다. 원문은 3바이트(24비트)인데, 결과는 6비트짜리 문자 4개(24비트)입니다.

비트 수는 같지만 문자당 담는 정보량이 8비트에서 6비트로 줄어들었기 때문에, 같은 정보를 표현하는 데 더 많은 문자가 필요해진 것입니다. 이 비율이 정확히 4/3이고, 그래서 Base64 결과는 원본보다 약 33% 길어집니다.

'=' 패딩이 붙는 이유

원문 길이가 항상 3바이트의 배수인 것은 아닙니다. 남는 바이트 수에 따라 패딩 개수가 정해집니다.

• "A" 한 글자(1바이트, 01000001)는 6비트씩 끊으면 두 조각(010000, 010000 → Q, Q)만 만들어지므로, 부족한 두 자리를 '='로 채워 QQ== 가 됩니다.
• "Hi"(2바이트)는 같은 방식으로 세 조각(S, G, k)이 나오므로, 부족한 한 자리만 '='로 채워 SGk= 가 됩니다.
• "가"처럼 한 글자가 3바이트인 문자(UTF-8로 EA B0 80)는 이미 3바이트 단위가 맞아떨어져 패딩 없이 4글자(6rCA)로 변환됩니다.

'='의 개수만 보면 원문이 3의 배수보다 몇 바이트 부족했는지(1바이트 부족이면 '==', 2바이트 부족이면 '=') 거꾸로 알 수 있습니다.

이 도구는 인코딩 전에 원문을 UTF-8 바이트로 바꾸고, 디코딩 후에는 그 바이트를 다시 UTF-8로 해석하기 때문에 한글이나 이모지를 넣어도 값이 깨지지 않습니다.

저희 도구로 확인하기.

직접 해보기 →

자주 헷갈리는 부분

가장 흔한 오해는 Base64를 암호화로 착각하는 것입니다. 정리하면 아래와 같습니다.

Base64는 "숨기는" 인코딩이 아니라 "표현 방식을 바꾸는" 인코딩입니다. 문자표가 공개돼 있고 계산 규칙도 고정돼 있어서, 위 계산을 거꾸로 따라가면 누구나 원문을 복원할 수 있습니다.

이 도구의 디코딩 모드는 atob 함수로 이 과정을 그대로 수행하며, 표준 문자가 아닌 값이 섞이면 결과 대신 오류 메시지를 보여줍니다.

공백이나 줄바꿈이 섞인 Base64 문자열을 그대로 붙여넣어도, 이 도구는 공백류 문자를 먼저 제거한 뒤 디코딩을 시도합니다. 다만 '=' 위치가 중간에 끼어 있거나 표준 문자표에 없는 기호가 섞이면 여전히 오류로 처리됩니다.

정리

• Base64는 원문을 바이트로 쪼갠 뒤 6비트씩 묶어 64개 문자로 재표현하는 인코딩입니다.
• 8비트를 6비트 단위로 표현하기 때문에 결과 문자열은 원본보다 약 4/3배(약 33%) 길어집니다.
• 끝에 붙는 '=' 는 원문 길이를 4의 배수로 맞추기 위한 패딩이며, 1바이트나 2바이트가 남을 때만 붙습니다.
• Base64는 암호화가 아니며, 별도 키 없이 누구나 디코딩해 원문을 복원할 수 있습니다.
• 이 도구는 UTF-8 기준으로 인코딩·디코딩하므로 한글이나 이모지를 넣어도 값이 깨지지 않습니다.

자주 묻는 질문

Base64로 인코딩하면 암호화되나요?

아닙니다. Base64는 데이터를 64개의 정해진 문자로 재표현하는 인코딩이지 암호화가 아닙니다.

별도의 비밀키가 필요 없고, 문자표와 계산 규칙만 알면 누구나 원문으로 되돌릴 수 있습니다. 데이터를 숨기거나 보호할 목적으로는 적합하지 않습니다.

왜 결과 문자열 끝에 '='이 붙나요?

원문 바이트 수가 3의 배수가 아닐 때, 마지막 6비트 조각을 4개가 아닌 2개나 3개까지만 만들 수 있기 때문입니다. Base64 문자열은 항상 길이가 4의 배수여야 하므로, 부족한 자리를 '='로 채워 맞춥니다.

1바이트가 남으면 '==', 2바이트가 남으면 '=' 하나가 붙습니다.

한글이나 이모지도 깨지지 않고 변환되나요?

깨지지 않습니다. 이 도구는 인코딩할 때 텍스트를 먼저 UTF-8 바이트로 바꾸고, 디코딩할 때는 그 바이트를 다시 UTF-8로 해석해 문자를 복원합니다.

한글 한 글자는 대개 3바이트, 이모지는 4바이트로 이뤄져 있는데, 이 과정을 그대로 거치므로 원래 문자로 정확히 돌아옵니다.

Base64 문자열의 길이만 보고 원본 크기를 짐작할 수 있나요?

대략 가능합니다. 3바이트가 4글자로 바뀌는 규칙을 거꾸로 적용하면, 원본 바이트 수는 대략 (패딩을 뺀 Base64 길이) × 3 ÷ 4로 추정할 수 있습니다.

'='가 있다면 그만큼(1개당 대략 1바이트씩) 빼서 계산하면 더 정확해집니다. 정확한 값이 필요하면 직접 디코딩해 원문 길이를 확인하는 편이 확실합니다.