Base64 인코딩·디코딩

이진 데이터를 A–Z, a–z, 0–9, +, / 64개 ASCII 문자로 바꾸는 인코딩 방식입니다. 이메일(MIME), JSON, HTML 등 텍스트만 다룰 수 있는 곳에 이미지·파일을 실어 보낼 때 사용합니다. 3바이트를 4문자로 바꾸며, 용량은 약 33% 늘어납니다. 디코딩한 JSON 데이터를 읽기 좋게 다듬으려면 JSON 포맷터·정리 도구를 이용해 보세요.

대부분 문자셋 문제입니다. 한글은 UTF-8로 인코딩된 경우가 대부분이므로, 디코딩 시 문자셋을 UTF-8로 지정해 주세요. 구형 시스템에서 받은 데이터라면 EUC-KR 등 원래 문자셋을 확인해야 합니다. 개발자 참고: 브라우저의 atob()은 ASCII만 처리하므로 한글은 TextDecoder와 함께 사용해야 합니다. 이 도구는 UTF-8 변환을 자동으로 처리합니다.

Base64 출력 길이를 4의 배수로 맞추기 위한 채움 문자입니다. 원본 길이를 3으로 나눈 나머지가 1이면 ==, 2이면 =이 붙습니다(예: M→TQ==, Ma→TWE=). 디코딩할 때는 필요하지만, URL-safe(Base64URL) 형식에서는 생략하는 것이 정상입니다.

+를 -로, /를 _로 바꾸고 = 패딩을 생략한 변형입니다(RFC 4648). URL·파일명·JWT 토큰처럼 +, /, =가 문제를 일으키는 곳에서 사용합니다. 두 형식은 서로 변환할 수 있으며, 이 도구의 URL-safe 토글을 켜면 자동으로 변환됩니다. 일반 텍스트의 퍼센트 인코딩(%20 등)이 필요하면 URL 인코딩·디코딩 도구를 이용해 보세요.

약 33% 늘어납니다. 3바이트를 4문자로 표현하기 때문입니다. 작은 이미지·아이콘을 HTML에 직접 넣을 때는 편리하지만, 큰 파일은 별도 파일로 두는 것이 좋습니다.

네. 변환된 문자열을 Data URI(data:image/png;base64,...) 형태로 만들면 브라우저에서 바로 미리보기할 수 있고, <img> 태그·CSS·마크다운용 코드를 복사해 바로 사용할 수 있습니다. 이 페이지의 "Base64 → 이미지" 탭에서 문자열을 붙여넣으면 미리보기와 다운로드를 바로 확인할 수 있습니다.

아닙니다. Base64는 암호화가 아니라 인코딩이라서 누구나 디코딩할 수 있습니다. 디코딩은 복호화가 아니며, 비밀번호나 개인정보를 "보호"하는 용도로 사용하면 안 됩니다. 실제 암호문(AES 등)을 해독하는 것과는 다릅니다.

권장하지 않습니다. 표준 Base64의 더하기, 슬래시, 등호 문자는 URL에서 예약된 의미를 가져 서버가 다르게 해석할 수 있습니다. 예를 들어 더하기 기호는 공백으로 해석되는 경우가 있어 데이터가 손상됩니다. URL 인코딩으로 감싸거나, 문자를 치환하고 패딩을 제거하는 Base64URL 방식을 사용하세요. API 명세에 Base64URL을 쓰라고 되어 있다면 반드시 변환 방식을 확인하세요.

브라우저 메모리에 부담을 주어 멈추거나 느려질 수 있습니다. Base64는 원본보다 약 33% 커지므로 수 MB 이상의 파일은 서버 방식이나 전용 프로그램을 권장합니다. 특히 모바일 브라우저는 메모리 제한이 엄격해 큰 파일 처리에 취약합니다. 이미지는 이미지 용량 줄이기로 먼저 줄인 뒤 인코딩하세요. 텍스트 위주의 설정 파일이나 인증서처럼 크기가 작은 데이터에는 이 도구가 가장 간편합니다.

세 가지가 흔합니다. 첫째, 문자열 중간에 들어간 줄바꿈이나 공백입니다. 이메일이나 메신저로 전달되는 과정에서 자동으로 줄바꿈이 들어가는 경우가 많습니다. 둘째, URL용으로 변환된 Base64URL을 표준 디코더에 넣은 경우입니다. 셋째, 문자열이 잘려서 길이가 4의 배수가 아닌 경우입니다. 원본 문자열을 그대로 복사했는지 먼저 확인하세요. 그래도 안 되면 인코딩한 쪽의 문자셋이 UTF-8인지 확인해 보세요.