DevSpeedTools

인코딩 · 2026년 9월 1일

Base64 인코딩 — 그것이 무엇인지, 언제 사용하고, 언제 사용하지 말아야 하는지

Base64는 바이너리 데이터를 안전한 ASCII 텍스트로 변환합니다. 이메일, JWT, 데이터 URI, 임베딩 등 어디에나 있지만 암호화는 아닙니다. 작동 방식과 개발자들이 실제로 필요로 하는 곳을 설명합니다.

DevSpeedTools 작성

Base64는 모든 개발자가 사용해 본 적이지만Few가 멈추지 않고 설명할 수 있는 포맷 중 하나입니다. 랜덤한 문자처럼 보입니다. 데이터를 더 크게 만듭니다. 그럼에도 불구하고 이메일 첨부 파일, JWT 페이로드, CSS의 인라인 이미지 및 바이너리 데이터를 텍스트 전용 채널로 이동해야 하는 수십 개의 다른 프로토콜의 중추입니다.

짧은 버전: Base64는 임의의 바이너리 데이터를 인쇄 가능한 ASCII 문자로 인코딩합니다. 긴 버전에는 64문자 알파벳, 패딩 규칙 및 프로덕션에서 사람들을 혼동시키는 몇 가지 변형이 포함됩니다.

왜 Base64가 존재하는지

많은 시스템은 텍스트만 전송하도록 설계되었습니다 — 이메일(SMTP), URL, XML, JSON. 이 파이프 중 하나를 통해 바이너리 파일을 보내려면 바이트를 문자로 표현하는 방법이 필요합니다. Base64는 입력의 3바이트마다 출력의 4문자로 매핑하여 거의 모든 텍스트 프로토콜에서 안전한 문자만 사용하여 이를 해결합니다.

트레이드오프: Base64는 데이터 크기를 약 33% 증가시킵니다. 1KB 이미지는 약 1.3KB의 텍스트가 됩니다. 대부분의 사용 사례에서는 괜찮습니다. 고throughput 시스템에서는 중요하며, Base85나 원시 바이너리 프로토콜과 같은 대안을 볼 수 있습니다.

64문자

알파벳은:

A-Z  (26문자)
a-z  (26문자)
0-9  (10문자)
+ /  (2문자)

총 64문자, 그래서 이름이 붙여졌습니다. 입력 길이가 3바이트의 배수가 아닌 경우 = 문자가 패딩에 사용됩니다.

알파벳의 모든 문자는 인쇄 가능 ASCII이며, Base64 출력은 이메일을 통해 전달되고, JSON 문자열에 나타나며, HTML 속성 내에 위치할 수 있으며, 원시 바이너리를 손상시킬 수 있는 시스템을 생존할 수 있습니다.

인코딩 작동 방식

세 바이트의 입력을 가져갑니다. 각 바이트는 8비트이므로 총 24비트입니다. Base64는 24비트를 네 개의 6비트 그룹으로 나눕니다. 각 6비트 그룹은 알파벳의 한 문자에 매핑됩니다:

  • 000000 → A
  • 000001 → B
  • …
  • 111111 → z

그게 전부입니다. 인코딩은 키, 소금 또는 비밀 없는 단순한 비트 수준 변환입니다. 누구나 조회 테이블을 뒤집어 Base64를 디코딩할 수 있습니다.

패딩

입력 길이가 3의 배수가 아닌 경우 패딩으로 채웁니다:

  • 1바이트 남음 → 2 Base64 문자 + ==
  • 2바이트 남음 → 3 Base64 문자 + =
  • 0바이트 남음 → 패딩 없음

패딩 문자는 데이터를 전달하지 않습니다. 출력 길이가 항상 4의 배수가 되도록 존재하며, 많은 파서가 이를 기대합니다.

변형

모든 Base64가 동일하지는 않습니다:

  • 표준 Base64 (A-Za-z+/=) — 기본값, MIME 이메일 및 대부분의 프로토콜에서 사용.
  • URL 안전 Base64 (A-Za-z-_) — +를 -로, /를 _로 대체하고 패딩을 제거. JWT, URL 매개변수 및 파일명에 사용.
  • 패딩 없는 Base64 — 일부 시스템은 = 문자를 생략합니다. 출력이 더 짧아지지만 일부 파서는 실패합니다.

JWT 또는 데이터 URI를 디버깅할 때 디코딩이 실패하는 경우, 첫 번째로 확인할 것은 인코더가 URL 안전 Base64를 사용했는지 표준 Base64를 사용했는지입니다. 표준 Base64 문자열로 예상한 것 중간에 -가 있으면 그게 단서입니다.

개발자가 실제로 Base64를 만나는 곳

이메일 첨부 파일. MIME(RFC 2045)는 바이너리 첨부 파일을 인코딩하기 위해 Base64를 사용합니다. 랜덤 문자의 긴 문자열이 있는 .eml 파일을 본 적이 있다면,那是 Base64로 인코딩된 콘텐츠입니다.

JWT 페이로드. JWT의 세 부분(헤더, 페이로드, 서명)은 각각 URL 안전으로 Base64 인코딩됩니다. JWT를 디코딩할 때 각 세그먼트의 Base64url 인코딩을 반전시키고 있습니다.

데이터 URI. data:image/png;base64,iVBOR...는 이미지를 HTML이나 CSS에 직접 인라인으로 포함할 수 있게 합니다. 이미지 바이트는 텍스트 속성에 나타날 수 있도록 Base64 인코딩됩니다.

API. 일부 API는 Base64로 인코딩된 바이너리 데이터를 받거나 반환합니다(파일 업로드, 이미지 처리, 암호화 서명). 대부분의 API가 멀티파트 폼 데이터를 지원하는 지금은 덜 일반적이지만 여전히 나타납니다.

임베딩. 머신러닝 모델은 때때로 임베딩을 JSON의 Base64 문자열로 저장합니다. 성능에는 이상적이지 않지만 전송에는 편리합니다.

Base64를 사용하면 안 되는 경우

암호화로 사용하지 마세요. Base64는 인코딩이지 암호화가 아닙니다. 누구나 디코딩할 수 있습니다. 민감한 데이터를 Base64에 넣는 것은 숨기는 것일 뿐 보호하는 것이 아닙니다.

압축으로 사용하지 마세요. Base64는 데이터를 더 크게 만들지 작게 만들지 않습니다. 이미 압축된 데이터(예: .gz 파일)를 Base64 인코딩하면 이점 없이 오버헤드를 추가합니다.

성능에 민감한 경로에서 사용하지 마세요. 인코딩/디코딩은 CPU 시간을 추가하고 페이로드 크기를 증가시킵니다. 고주기 내부 API의 경우 대신 바이너리 프로토콜(protobuf, msgpack)을 사용하세요.

변형을 잊지 마세요. URL이나 JWT용 Base64를 생성하는 경우 URL 안전 Base64를 사용하세요. 이메일이나 일반 전송용으로 생성하는 경우 표준 Base64를 사용하세요. 혼동하면 조용한 데이터 손상이 발생합니다.

빠른 참조 | 시나리오 | 변형 | 패딩 | |–––––|——|——| | JWT | URL 안전 | 아니오 | | 이메일 / MIME | 표준 | 예 | | 데이터 URI | 표준 | 선택적 | | URL 매개변수 | URL 안전 | 아니오 | | 일반 전송 | 표준 | 예 |

시도해보기

디코딩해야 하는 Base64 문자열이나 인코딩해야 하는 바이너리 데이터가 있다면 브라우저 기반 도구를 사용하여 변환이 로컬에서 이루어지도록 하세요 — 데이터가 그렇게 간단한 작업을 위해 서버로 전송되지 않습니다.