Base64로 인코딩
텍스트, 이미지, 어떤 파일이든 정확하게 Base64로 변환합니다. 흔한 한 줄짜리 구현이 해내지 못하는 악센트 문자와 이모지도 그대로 유지됩니다. 아무것도 저장하지 않습니다.
- 저장되지 않음
- 대기열 없음, 기다림 없음
- 회원가입 없음, 워터마크 없음
텍스트는 UTF-8로 인코딩되므로 악센트 문자와 이모지도 그대로 유지돼요.
여기에 Base64 내용이 표시돼요.
사용 방법
텍스트 붙여넣기 또는 파일 놓기
텍스트는 UTF-8로 인코딩합니다. 파일은 바이트 단위 그대로 인코딩하며, 저장하지 않습니다.
방식 선택
표준 Base64, 토큰과 쿼리 문자열용 URL 안전 Base64URL, 또는 CSS나 <img> 태그에 바로 붙여 넣을 수 있는 완전한 data URI 중에서 고르세요.
복사하기
결과를 복사하거나, 크다면 텍스트 파일로 다운로드하세요.
정확히 3분의 1만큼 커지는 이유
Base64는 3바이트씩 묶어 4개의 문자로 씁니다. 각 문자는 24비트 중 6비트를 담습니다. 4를 3으로 나눈 값이 바로 그 유명한 33퍼센트의 출처입니다. 비효율이 아니라 산수이며, 출력 가능한 문자 범위 안에 머물면서 이보다 나은 인코더는 없습니다. 데이터가 3으로 딱 나누어떨어지지 않으면 마지막 묶음을 채우고 = 기호 한두 개로 표시합니다. 그래서 Base64 문자열의 길이는 항상 4의 배수입니다.
문자 집합은 두 가지이며, 잘못 고르는 것이 사람들이 이곳을 찾는 가장 흔한 이유입니다. 표준 문자 집합은 +와 /로 끝나는데, 둘 다 URL에서 의미가 있습니다. 쿼리 문자열에서 +는 공백이 되고, /는 경로 구분자처럼 보입니다. URL 안전 변형은 대신 -와 _를 쓰며, JSON Web Token, 파일 이름, 주소에 들어가는 모든 것이 이것을 씁니다. 그 밖에는 똑같지만, 한쪽으로 인코딩한 값을 다른 쪽으로 디코딩하면 데이터 손상처럼 보이는 방식으로 실패합니다.
줄 바꿈은 상황에 따라 달라지는 또 하나의 요소입니다. 이메일 첨부 파일은 한 줄에 76자, PEM 인증서와 키는 64자를 기대하며, data URI나 JSON 필드는 줄 바꿈이 전혀 없어야 합니다. 요즘은 줄 바꿈 없는 경우가 일반적이라 여기서는 기본적으로 꺼 두었습니다. 대상이 이메일 헤더나 -----BEGIN----- 블록이라면 켜세요. 이들은 엄청나게 긴 한 줄을 거부합니다.
Base64는 암호화가 아니며 아무런 보호도 제공하지 않습니다. 문자 집합을 바꿀 뿐이므로 누구나 즉시 되돌릴 수 있고, 보안 스캐너는 이를 자동으로 되돌립니다. Base64의 목적은 이메일 본문, JSON 필드, XML 문서, 스타일시트의 data URI처럼 텍스트만 받는 통로로 바이너리 데이터를 옮기는 것입니다. 설정 파일의 비밀번호를 Base64로 숨겨 봐야 들여다보는 사람에게는 아무것도 가려지지 않습니다.
다른 작업이 필요할 때
명령줄에서는 Linux에서 base64 -w 0 file.bin이 줄 바꿈 없이 인코딩하고, macOS에서는 그냥 base64가 같은 일을 하며, openssl base64 -A는 어디서나 똑같이 작동합니다. URL 안전 문자 집합이 필요하면 basenc --base64url이 문자 치환 단계 없이 제대로 처리합니다.
큰 파일이라면 이 페이지의 방식은 전부 맞지 않습니다. 파일 전체를 메모리에 올리고, 인코딩하면서 다른 작업이 시작되기도 전에 3분의 1만큼 부풀리기 때문입니다. 명령줄 도구는 스트리밍으로 처리하며, 코드에서는 모든 언어에 점진적 인코더가 있습니다. Base64가 정말 필요한지도 따져 볼 만합니다. 바이너리를 multipart/form-data나 원시 본문으로 보내면 메모리 문제와 33퍼센트 증가를 모두 피할 수 있습니다.
자주 묻는 질문
제 텍스트나 파일이 어딘가에 저장되나요?
아니요. 아무것도 저장하지 않고, 로그도 남기지 않으며, 어떤 서버도 내용을 보지 않습니다. 네트워크를 끊어도 계속 작동합니다. 특히 이런 도구에서는 이것이 부가적인 장점이 아닙니다. 사람들이 온라인 인코더와 디코더에 붙여 넣는 것은 세션 토큰, API 키, Authorization 헤더, 고객 기록처럼 실제로 쓰이고 있는 값인 경우가 많습니다. 이를 어딘가로 전송하는 페이지에 붙여 넣는 것은 사이트가 삭제에 대해 무엇을 약속하든 곧 유출입니다.
여기서는 왜 악센트 문자와 이모지가 제대로 되나요?
인코딩하기 전에 텍스트를 UTF-8 바이트로 변환하기 때문입니다. 이것이 올바른 순서이며, 대부분의 간단한 구현이 빠뜨리는 단계입니다. 브라우저 자체의 `btoa`는 텍스트를 아예 받지 못합니다. 문자 하나를 1바이트로 받기 때문에 `btoa("café")`는 그냥 오류를 냅니다. 널리 쓰이는 우회법인 `btoa(unescape(encodeURIComponent(s)))`는 우연히 작동할 뿐이며, 이모지나 기본 범위를 벗어난 문자에서는 무너집니다. 이 페이지는 UTF-8을 한 번, 제대로 인코딩하므로 日本語와 🎉도 그대로 들어가고 똑같이 디코딩됩니다.
Base64URL은 무엇이고 언제 필요한가요?
두 문자를 바꾼 Base64입니다. +는 -가 되고, /는 _가 되며, 끝의 = 패딩은 생략됩니다. +, /, =가 모두 URL에서 의미를 가지기 때문에, 일반 Base64는 쿼리 문자열이나 경로를 거치면서 망가집니다. 그래서 이 변형이 존재합니다. JWT, OAuth 토큰, URL에 들어가는 모든 것이 Base64URL을 씁니다. 결과를 링크에 넣을 거라면 이것을 고르세요.
Base64가 무언가를 암호화하거나 보호하나요?
아니요. 이 점은 분명히 말해 둘 가치가 있습니다. Base64는 인코딩이지 암호화가 아니며, 키도 비밀도 없습니다. 문자열을 본 사람은 누구나 이 사이트에서도 한 번에 디코딩할 수 있습니다. Base64는 이메일 첨부 파일이나 data URI처럼 텍스트만 받는 통로로 바이너리 데이터를 안전하게 옮기려고 존재합니다. 비밀로 지켜야 할 것이라면 암호화가 필요하며, Base64는 아무런 보호도 제공하지 않습니다.
왜 Base64가 원본 파일보다 크나요?
항상 약 33% 더 큽니다. Base64는 3바이트마다 텍스트 문자 4개로 표현하므로 설계상 크기가 3분의 1만큼 늘고, 패딩이 약간 더해집니다. 바이너리를 텍스트로 바꾸는 대가이며, 큰 이미지를 CSS에 data URI로 넣는 것이 대개 손해인 이유이기도 합니다.
이미지를 data URI로 인코딩할 수 있나요?
네. 이미지를 끌어다 놓고 Data URI를 선택하세요. 올바른 미디어 타입이 이미 채워진 완전한 `data:image/png;base64,…` 문자열이 나오며, 스타일시트, <img> 태그, 이메일 템플릿에 바로 붙여 넣을 수 있습니다.
용량 제한이 있나요?
고정된 용량 한도가 아니라 사용 가능한 메모리가 한계이며, 넉넉합니다. 여러 MB짜리 파일도 문제없이 인코딩됩니다. 큰 파일을 처리하려고 일부러 조각 단위로 인코딩합니다. 흔한 구현은 약 125 KB에서 “Maximum call stack size exceeded” 오류로 멈추며, 수많은 온라인 인코더에 있는 버그입니다.
참고: Base64는 데이터를 약 33% 크게 만듭니다. 결함이 아니라 형식 자체의 특성입니다. 파일은 통째로 메모리에 읽어 들이므로, 매우 큰 파일은 휴대폰에서 끝나기 전에 탭의 메모리를 다 쓸 수 있습니다. 줄 바꿈은 기본적으로 꺼져 있으며, 이메일과 PEM 형식은 줄 바꿈이 켜져 있어야 합니다.
내 웹사이트에 이 도구 넣기
블로그, 수업 페이지, 도움말 글 어디에나 무료로 넣을 수 있습니다. 코드 한 줄만 붙여 넣으면 방문자가 페이지에서 바로 사용할 수 있습니다.