> 인코드 | 디코드 | 실행 <

A: 64문자 알파벳을 사용하는 바이너리-텍스트 인코딩 방식. Base64 데이터 변환, 이미지 임베딩, 이메일 첨부, API 데이터 전송에 필수.

A: 100% 무료 Base64 변환기. 파일 크기 제한 없음. 무제한 Base64 인코딩/디코딩 작업. 로컬 Base64 처리만.

A: 100% 안전한 Base64 처리. 로컬 Base64 인코딩/디코딩. 서버 업로드 없음. Base64 데이터가 기기를 떠나지 않음.

A: 표준 Base64는 +/ 문자 사용. URL 안전 Base64는 -_ 문자 사용. URL 안전 Base64가 웹 URL, 파일명, HTTP 헤더에 더 좋음.

A: 예. 이미지를 Base64로 변환: /image-to-base64/. PNG, JPG, GIF, SVG Base64 인코딩 지원. 모든 파일 유형.

A: Base64는 인코딩이지 암호화가 아님. Base64는 가역적 데이터 표현. 안전하지 않음. 보안을 위해서는 Base64가 아닌 AES 암호화 사용.

A: 빠른 Base64 인코더/디코더 + 오프라인 Base64 처리 + 무제한 파일 크기 + URL 안전 Base64 + 고급 옵션 + 완전 무료.

A: Base64는 임의의 바이너리 데이터를 A–Z, a–z, 0–9, +, /의 64개 ASCII 출력 가능 문자만으로 표현하는 인코딩 방식입니다(RFC 4648 §4). 3바이트(24비트)를 4문자(각 6비트)로 변환하기 때문에 출력 크기는 원본의 약 4/3배(+33%)가 됩니다. 이메일, JSON, URL, HTTP 헤더처럼 텍스트만 통과시키는 채널로 바이너리를 안전하게 전달할 때 사용합니다. Base64는 암호화가 아닙니다. 누구나 역변환할 수 있으므로 민감한 데이터는 AES 등으로 별도 암호화해야 합니다.

A: 상단 텍스트 영역에 Base64 문자열을 붙여넣고 [디코드] 버튼을 누르면 UTF-8 텍스트로 복호화됩니다. 모든 처리는 브라우저에서 이루어지므로 API 키나 비밀 값이 포함된 문자열도 서버로 전송되지 않습니다. 결과는 [복사] 버튼으로 클립보드에 바로 복사할 수 있으며, Base64URL(-/_)도 자동으로 인식합니다.

A: 한글을 포함한 임의의 텍스트를 입력한 뒤 [인코드]를 누르면 됩니다. 내부적으로 먼저 UTF-8로 인코딩한 다음 Base64로 변환하므로 「안녕하세요」 같은 멀티바이트 문자도 손상 없이 처리됩니다. URL에 삽입해야 한다면 --url-safe 및 --패딩없음 옵션을 켜서 Base64URL 형식으로 출력하세요.

A: 표준 btoa() / atob()는 Latin-1만 받아들이므로 한글을 그대로 넘기면 InvalidCharacterError가 발생합니다. UTF-8까지 안전하게 다루려면 다음 패턴을 씁니다:

// encode
const b64 = btoa(unescape(encodeURIComponent('안녕하세요')));
// decode
const text = decodeURIComponent(escape(atob(b64)));

A:
Node.js: Buffer.from('안녕하세요').toString('base64') / Buffer.from(b64, 'base64').toString('utf8')
Python: import base64; base64.b64encode('안녕하세요'.encode()).decode() / base64.b64decode(b64).decode()
Go: base64.StdEncoding.EncodeToString([]byte(s)) / base64.StdEncoding.DecodeString(s)
PHP: base64_encode($str) / base64_decode($b64)
셸: printf '안녕하세요' | base64

A: Base64는 3바이트 단위로 4문자를 생성하므로 원본이 3의 배수가 아닐 때 =(1바이트 남음: ==, 2바이트 남음: =)을 붙여 4의 배수 길이로 맞춥니다. RFC 4648 표준에서는 필수지만 JWT, OAuth 2.0, WebAuthn처럼 URL에 실어 보내는 경우에는 생략하는 것이 관례입니다. 길이에서 자동으로 복원할 수 있기 때문에 실질적인 문제는 없습니다.

A: 알파벳 중 마지막 두 문자가 다릅니다.
• 표준 Base64(§4): +와 / 사용. URL/파일명에서 특별한 의미를 가져 그대로 쓰기 어렵습니다.
• Base64URL(§5): +→-, /→_로 치환하고 패딩 =도 생략하는 것이 일반적. URL, HTTP 헤더, 쿠키, 파일명에 그대로 넣을 수 있습니다.
인코딩 대상 바이트는 동일하므로 세 문자만 치환하면 상호 변환이 가능합니다. 자세한 내용은 /ko/base64url/을 참고하세요.

A: 고정적으로 약 33% 증가합니다(정확히는 ceil(n/3)*4 바이트). 76자마다 개행이 들어가는 포맷에서는 약간의 추가 오버헤드가 있을 수 있습니다. HTTP에서 전송할 때는 gzip이나 brotli 압축을 켜면 Base64는 압축률이 높아 실효 오버헤드가 수 % 수준까지 줄어듭니다.

A: data: 스킴을 사용해 외부 파일 대신 바이너리를 HTML/CSS에 직접 내장하는 방식입니다. 형식은 data:<mime>;base64,<payload>. 예: <img src="data:image/png;base64,iVBORw0KGgo…">. HTTP 요청을 1회 절약할 수 있지만 캐시가 되지 않고 HTML/CSS 자체 크기가 커지므로 2KB 이하 아이콘에 주로 사용합니다. 이미지 변환은 /ko/image-to-base64/에서 할 수 있습니다.

A: 문자열 → 바이트 배열 → Base64 순으로 처리하면 문제가 없습니다. 깨지는 전형적 사례: (1) EUC-KR / CP949 바이트 배열을 Base64로 만든 문자열을 UTF-8로 해석한 경우, (2) 브라우저에서 btoa('안녕')을 직접 호출해 InvalidCharacterError가 발생한 경우, (3) 한쪽에서만 encodeURIComponent를 적용한 경우. 본 도구는 항상 UTF-8 기준으로 처리하므로 타 시스템과 주고받을 때는 상대 시스템의 인코딩을 먼저 확인하세요.

A: 안 됩니다. Base64는 공개된 인코딩 규칙이며, 키 없이도 한 줄 코드로 원본을 복원할 수 있습니다. 비밀번호, API 키, 개인정보, 의료정보 같은 민감한 데이터를 Base64로만 "숨긴" 채 저장·전송하는 것은 보안상 심각한 실수입니다. 기밀성이 필요하다면 AES-GCM이나 ChaCha20-Poly1305 같은 인증 암호화를 사용하고, 그 결과를 필요에 따라 Base64로 문자열화하세요.