Base64 인코더
일반 텍스트 또는 이진 문자열을 Base64 인코딩된 출력으로 변환합니다. RFC 4648에 따라 표준 및 URL 안전 알파벳을 지원하며, 이모지 및 비라틴 스크립트를 포함한 전체 UTF-8을 처리합니다.
Base64는 데이터 크기를 대략 33% 증가시킵니다. 이 거래는 이진 데이터가 이메일 헤더, JSON 페이로드 및 HTTP 인증 헤더와 같은 텍스트 전용 채널에서 살아남아야 하기 때문에 존재합니다. RFC 4648에 정의된 Base64는 A-Z, a-z, 0-9, 그리고 +와 / (또는 URL 안전 모드에서 -와 _)를 사용합니다. 이 브라우저 기반 인코더는 내장된 btoa() 및 TextEncoder API를 사용하여 입력을 완전히 장치에서 처리합니다. 개인 문자열, 토큰 및 자격 증명은 어떤 서버에도 전송되지 않습니다.
Base64로 인코딩하는 방법
- 인코딩할 텍스트를 입력 필드에 입력하거나 붙여넣습니다.
- 표준 또는 URL 안전 인코딩 모드를 선택합니다.
- 인코딩된 Base64 출력이 즉시 출력 패널에 나타납니다.
- 복사를 클릭하여 결과를 클립보드에 복사합니다.
Base64 인코딩 작동 방식
64자 알파벳
Base64는 A-Z (26), a-z (26), 0-9 (10) 및 두 개의 추가 문자로 구성된 64자 알파벳을 사용합니다. 표준 Base64 (RFC 4648 §4)는 +와 /를 사용합니다. URL 안전 Base64 (RFC 4648 §5)는 이를 -와 _로 대체합니다. 인코딩은 3개의 입력 바이트(24비트)를 가져와 4개의 6비트 그룹으로 나누고 각 6비트 값을 해당 알파벳 문자에 매핑합니다. 이 때문에 Base64 출력 길이는 항상 4의 배수입니다.
패딩
Base64는 3바이트 그룹으로 데이터를 처리하기 때문에, 입력 길이가 3의 배수가 아닌 경우 패딩이 필요합니다. 남은 1바이트는 끝에 ==를 생성합니다. 남은 2바이트는 =를 생성합니다. 패딩은 표준 Base64에서 필요하지만, URL 안전 구현에서는 종종 제거됩니다. 특히 JWT에서 그렇습니다.
예시
입력
Hello, World!출력 (표준 Base64)
SGVsbG8sIFdvcmxkIQ==두 개의 = 패딩 문자가 나타나는 이유는 "Hello, World!"가 13바이트이기 때문입니다 - 13 mod 3 = 1, 그래서 마지막 그룹에 1바이트가 남습니다.
일반적인 사용 사례
- HTTP 기본 인증 -
Authorization: Basic헤더는 Base64로 인코딩된username:password를 요구합니다. - HTML/CSS의 인라인 이미지 - 데이터 URI:
data:image/png;base64,iVBORw0KGgo... - JWT 토큰 - 헤더와 페이로드 섹션은 URL 안전 Base64를 사용합니다.
- 이메일 첨부파일 - MIME (RFC 2045)는 텍스트 기반 이메일 프로토콜에서 이진 첨부파일을 Base64로 인코딩합니다.
표준 Base64와 URL 안전 Base64
표준 Base64는 +와 /를 사용하며, 이는 URL에서 특별한 의미를 가집니다. URL 안전 Base64는 이를 -와 _로 대체하여 URL, 파일 이름 및 쿼리 매개변수에서 안전하게 만듭니다. JWT, OAuth 토큰 및 URL에 나타나는 모든 Base64 데이터에 URL 안전 모드를 사용하세요. 출력을 디코딩하려면 Base64 디코더를 사용하세요. URL 쿼리 매개변수에 인코딩된 데이터를 포함하려면 이 도구와 URL 인코더를 결합하세요.
자주 묻는 질문
Base64는 암호화의 한 형태인가요?
아니요. Base64는 인코딩 방식이지 암호화나 보안의 형태가 아닙니다. Base64 문자열을 가진 누구나 키 없이 즉시 디코딩할 수 있습니다. 기밀성은 전혀 제공하지 않습니다. 데이터를 보호해야 한다면 AES-256이나 RSA를 사용하세요 - Base64는 텍스트 채널에서 이진 데이터를 안전하게 전송하기 위한 것이지 정보를 숨기기 위한 것이 아닙니다.
왜 Base64 출력은 항상 == 또는 =로 끝나나요?
Base64는 데이터를 3바이트 그룹으로 인코딩하여 4문자로 변환합니다. 입력 길이가 3으로 나누어 떨어지지 않으면 마지막 그룹은 3바이트 대신 1바이트 또는 2바이트를 가집니다. 남은 1바이트는 == 패딩을 생성하고, 2바이트는 =를 생성합니다. 패딩은 출력 길이가 항상 4의 배수가 되도록 보장합니다. 이는 RFC 4648에서 요구하는 사항입니다.
이 인코더는 유니코드와 이모지를 올바르게 처리하나요?
네. 인코더는 먼저 브라우저의 TextEncoder API를 사용하여 텍스트를 UTF-8 바이트로 변환한 후 Base64를 적용합니다. 이모지(UTF-8에서 4바이트), 중국어 문자, 아랍 문자, 악센트가 있는 라틴 문자 등 모든 유니코드 문자가 올바르게 인코딩되고 원래 텍스트로 디코딩됩니다.
URL 안전 Base64란 무엇이며 언제 사용해야 하나요?
URL 안전 Base64 (RFC 4648 §5)는 +를 -로, /를 _로 대체합니다. Base64 데이터가 URL, 파일 이름, 쿠키 또는 HTTP 헤더에 나타날 때마다 사용하세요. 표준 문자가 잘못 해석될 수 있습니다. JWT 토큰, OAuth 액세스 토큰, PKCE 코드 검증기도 모두 URL 안전 Base64를 사용합니다.
Base64는 데이터 크기를 얼마나 증가시키나요?
Base64 인코딩은 데이터 크기를 정확히 33.33% 증가시킵니다 - 3개의 입력 바이트는 4개의 출력 문자로 변환됩니다 (4/3 = 1.333...). 또한 출력에는 최대 2개의 패딩 문자가 포함될 수 있습니다. 대용량 이진 페이로드의 경우, 멀티파트 또는 이진 프로토콜이 Base64보다 더 대역폭 효율적입니다.