Base64 인코딩 & 디코딩
무료 온라인 Base64 인코딩 & 디코딩 도구. 100% 로컬 처리 — 데이터가 기기를 벗어나지 않습니다.
결과가 여기에 표시됩니다...
입력 → 인코딩
Usage Guide
Base64 소개
Base64는 64개의 인쇄 가능한 문자를 사용하여 바이너리 데이터를 표현하는 인코딩 방법으로, 텍스트 프로토콜을 통해 바이너리 데이터를 전송해야 하는 시나리오에서 널리 사용됩니다. Base64는 A-Z, a-z, 0-9, +, /(총 64자)와 패딩 문자로 =를 사용합니다. 3바이트(24비트)의 바이너리 데이터를 4개의 Base64 문자로 인코딩하여 인코딩된 데이터는 원본 크기의 약 133%가 됩니다. Base64는 암호화 알고리즘이 아니라 누구나 디코딩할 수 있는 인코딩 방법입니다.
사용 단계
Base64 인코딩과 디코딩은 매우 간단합니다:
인코딩 원리
Base64 인코딩은 다음 과정을 통해 바이너리 데이터를 ASCII 문자로 변환합니다:
Base64 변형
Base64에는 다양한 시나리오를 위한 여러 일반적인 변형이 있습니다:
응용 시나리오
Base64는 텍스트 프로토콜을 통해 바이너리 데이터를 전송해야 하는 시나리오에서 널리 사용됩니다:
FAQ
Q: Base64 인코딩은 데이터 크기를 증가시키나요?
A: 네, Base64 인코딩은 데이터 크기를 약 33% 증가시킵니다. 이유: Base64는 3바이트(24비트)를 4문자(32비트)로 인코딩하여 8비트를 추가합니다. 예를 들어, 100KB 파일은 인코딩 후 약 133KB가 됩니다. 영향: 1) 네트워크 전송 시간 증가. 2) 저장 공간 증가. 3) 인코딩/디코딩 CPU 오버헤드 증가. 최적화: 1) 큰 파일의 경우 인코딩 전에 압축(gzip 등) 고려. 2) URL 안전 Base64를 사용하고 패딩을 생략하면 크기를 약간 줄일 수 있음. 3) 웹 리소스의 경우 Data URL 대신 직접 바이너리 전송(Blob URL 등) 사용 고려.
Q: Base64와 암호화의 차이점은 무엇인가요?
A: Base64는 인코딩이지 암호화가 아닙니다. 근본적으로 다릅니다. Base64 인코딩: 1) 목적: 바이너리 데이터를 전송을 위한 텍스트 형식으로 변환. 2) 가역성: 누구나 키 없이 디코딩 가능. 3) 보안: 보안 없음, 데이터 기밀성 보호 불가. 암호화: 1) 목적: 데이터 기밀성 보호 및 무단 접근 방지. 2) 가역성: 복호화에 키 필요. 3) 보안: 데이터 보호 제공. 올바른 접근법: 데이터 보호가 필요한 경우 먼저 AES 또는 유사한 알고리즘으로 암호화한 다음 전송을 위해 Base64로 인코딩하세요.
Q: Base64 문자열이 = 기호로 끝나는 이유는 무엇인가요?
A: =는 Base64의 패딩 문자로, 인코딩 길이를 맞추는 데 사용됩니다. 이유: Base64는 3바이트를 4문자로 인코딩합니다. 원본 데이터 길이가 3의 배수가 아니면 마지막 그룹은 3바이트 미만이 되어 = 패딩이 필요합니다. 규칙: 1) 1바이트 남음: 2문자 + 2 =로 인코딩. 2) 2바이트 남음: 3문자 + 1 =로 인코딩. 3) 정확히 3바이트: 패딩 불필요. 예시: “A” → “QQ==”, “AB” → “QUI=”, “ABC” → “QUJD”. URL 안전: URL에서 =를 생략할 수 있으며(URL 안전 Base64), 디코딩 시 자동으로 추가됩니다.
Q: Base64와 Hex 인코딩의 차이점은 무엇인가요?
A: Base64와 Hex 는 모두 바이너리 데이터의 텍스트 표현이지만 다른 특성을 가집니다. Base64: 1) 64자 사용(A-Z, a-z, 0-9, +, /). 2) 인코딩 크기는 원본 데이터의 약 133%. 3) 더 컴팩트하여 전송에 적합. Hex(16진수): 1) 16자 사용(0-9, A-F). 2) 인코딩 크기는 원본 데이터의 200%. 3) 더 읽기 쉬워 디버깅에 적합. 선택 조언: 1) 컴팩트한 전송 필요: Base64 사용. 2) 가독성과 디버깅 필요: Hex 사용. 3) 암호화 알고리즘 출력: 일반적으로 Hex 사용(예: SHA-256).
Q: Data URL이란 무엇인가요? 어떻게 사용하나요?
A: Data URL은 Base64 인코딩을 사용하여 데이터를 URL에 직접 임베드하는 방법입니다. 형식: data:[미디어 타입];base64,[Base64 데이터]. 예시: data:image/png;base64,iVBORw0KGgoAAAANS.... 장점: 1) HTTP 요청 감소, 페이지 로드 속도 향상. 2) 추가 파일 불필요, 공유 및 임베드 용이. 단점: 1) HTML/CSS 파일 크기 증가. 2) 브라우저 캐시 활용 불가. 3) 큰 파일에 부적합. 사용 사례: 1) 작은 아이콘, 로고(< 10KB). 2) 인라인 SVG 이미지. 3) 폰트 파일(작은 폰트). 4) CSS 배경 이미지. 모범 사례: 10KB 미만의 리소스에만 Data URL을 사용하고, 큰 파일은 별도 파일을 사용하여 CDN과 캐싱을 활용하세요.
Q: JavaScript에서 Base64를 어떻게 사용하나요?
A: JavaScript는 내장 Base64 인코딩 및 디코딩 메서드를 제공합니다. 인코딩: btoa(string) - 문자열을 Base64로 인코딩. 디코딩: atob(base64String) - Base64를 문자열로 디코딩. 주의: btoa와 atob는 ASCII 문자만 지원합니다. UTF-8 문자열의 경우 먼저 변환이 필요합니다:// UTF-8 인코딩
const base64 = btoa(unescape(encodeURIComponent('중문')));
// UTF-8 디코딩
const text = decodeURIComponent(escape(atob(base64)));
현대적 방법: UTF-8 처리를 위해 TextEncoder와 TextDecoder API 사용. 파일 인코딩: FileReader.readAsDataURL()을 사용하여 파일을 Data URL로 인코딩.
Use Cases
권장: 작은 이미지의 Data URL
Data URL을 사용하여 HTML과 CSS에 작은 이미지(아이콘, 로고 등)를 임베드하면 HTTP 요청을 줄이고 페이지 로드 속도를 향상시킬 수 있습니다. 10KB 미만의 이미지에 권장하며, 큰 이미지는 별도 파일을 사용하여 CDN과 브라우저 캐싱을 활용하세요. Data URL은 인라인 SVG 이미지에 특히 적합합니다. SVG는 텍스트 형식이므로 Base64 인코딩 후에도 읽기 쉬운 상태를 유지합니다.
- ✅ 작은 아이콘, 로고(< 10KB)
- ✅ 인라인 SVG 이미지
- ✅ CSS 배경 이미지(작은 것)
- ❌ 큰 이미지 피하기(> 50KB)
- 💡 자동 변환을 위해 빌드 도구(Webpack 등) 사용
권장: JWT(JSON Web Token)
JWT는 클라이언트와 서버 간에 안전하게 정보를 전송하기 위해 Header와 Payload 인코딩에 Base64를 사용합니다. JWT는 Header, Payload, Signature 세 부분으로 구성되며 점으로 구분됩니다. Header와 Payload는 Base64 인코딩을 사용하고, Signature는 HMAC-SHA256 또는 RSA 서명을 사용합니다.
- ✅ 사용자 인증 및 권한 부여
- ✅ 싱글 사인온(SSO)
- ✅ API 액세스 토큰
- ❌ JWT에 민감한 정보 저장 금지(Base64는 디코딩 가능)
- 💡 JWT 전송에 HTTPS 사용
권장: HTTP Basic Authentication
HTTP Basic Authentication은 사용자 이름과 비밀번호를 Base64로 인코딩하여 Authorization: Basic [Base64(사용자명:비밀번호)] 형식으로 사용합니다. Base64 인코딩은 보안을 제공하지 않지만 HTTPS와 함께 사용하면 전송 중 자격 증명을 보호할 수 있습니다. HTTP Basic Authentication은 간단하고 사용하기 쉬워 내부 시스템이나 빠른 인증 구현이 필요한 시나리오에 적합합니다.
- ✅ 내부 시스템, 관리 패널
- ✅ API 인증(HTTPS와 함께)
- ✅ 간단한 사용자 인증
- ❌ 평문 전송을 피하기 위해 HTTPS를 사용해야 함
- 💡 더 안전한 OAuth 2.0 또는 JWT 고려
권장: 이메일 첨부 파일(MIME)
MIME(Multipurpose Internet Mail Extensions) 프로토콜은 이메일 첨부 파일을 Base64로 인코딩하여 바이너리 파일을 이메일 시스템에서 전송하기 위한 텍스트 형식으로 변환합니다. MIME Base64는 이메일 프로토콜 줄 길이 제한을 준수하기 위해 76자마다 줄 바꿈(CRLF)을 삽입합니다. 현대 이메일 클라이언트는 사용자의 수동 개입 없이 Base64 인코딩과 디코딩을 자동으로 처리합니다.
- ✅ 이메일 첨부 파일 인코딩
- ✅ 이메일 본문에 이미지 임베드
- ✅ RFC 2045 표준 준수
- 💡 자동 처리를 위해 이메일 라이브러리(Nodemailer 등) 사용
권장: API 바이너리 데이터 전송
JSON 및 XML과 같은 텍스트 형식 API에서 바이너리 데이터(이미지, 파일 등)를 전송할 때 Base64 인코딩을 사용할 수 있습니다. 이를 통해 multipart/form-data와 같은 복잡한 바이너리 전송 형식 처리를 피할 수 있습니다. 그러나 큰 파일의 경우 더 나은 성능을 위해 전용 파일 업로드 API(multipart/form-data 또는 객체 스토리지에 직접 업로드 등)가 권장됩니다.
- ✅ 작은 파일 전송(< 1MB)
- ✅ JSON API에 바이너리 데이터 임베드
- ✅ 설정 파일에 인증서 및 키 저장
- ❌ 큰 파일 전송 피하기(> 10MB)
- 💡 큰 파일에는 multipart/form-data 또는 객체 스토리지 사용
권장: 설정 파일에 바이너리 데이터 저장
설정 파일(JSON, YAML, XML 등)에 바이너리 데이터(SSL 인증서, 키, 작은 이미지 등)를 저장할 때 Base64 인코딩을 사용할 수 있습니다. 이를 통해 외부 파일 경로와 파일 읽기 문제를 처리할 필요가 없어 설정 파일이 자급자족하게 됩니다. Docker 이미지 및 Kubernetes ConfigMap과 같이 패키지화된 설정이 필요한 시나리오에 특히 적합합니다.
- ✅ SSL 인증서, 개인 키
- ✅ API 키, 토큰
- ✅ 작은 이미지, 아이콘
- ✅ Docker, Kubernetes 설정
- 💡 민감한 정보가 포함된 설정 파일 보호
모범 사례 권장사항
- Base64는 인코딩이지 암호화가 아니며 데이터 기밀성을 보호할 수 없습니다. 데이터 보호가 필요한 경우 먼저 암호화한 다음 인코딩하세요.
- Base64 인코딩은 데이터 크기를 약 33% 증가시킵니다. 큰 파일의 경우 인코딩 전에 압축을 고려하세요.
- Data URL은 10KB 미만의 리소스에 적합합니다. 큰 파일은 별도 파일을 사용하여 CDN과 캐싱을 활용하세요.
- HTTP Basic Authentication은 전송 중 자격 증명 도용을 방지하기 위해 HTTPS와 함께 사용해야 합니다.
- JWT Payload는 Base64 인코딩을 사용하며 누구나 디코딩할 수 있습니다. 민감한 정보를 저장하지 마세요.
- UTF-8 문자열의 경우 TextEncoder/TextDecoder 또는 encodeURIComponent/decodeURIComponent를 사용하여 처리하세요.