Base64 인코더/디코더
가장 빠르고 안전한 무료 Base64 인코더 & 디코더입니다. 모든 데이터 처리는 서버 전송 없이 사용자의 브라우저 내에서 안전하게 로컬로 이루어집니다.
※ 인코딩은 단순히 데이터를 안전하게 전송하기 위한 변환 방식일 뿐, 보안을 위한 암호화가 아닙니다. 민감한 정보는 별도로 암호화해야 합니다.
활용 꿀팁
텍스트와 파일의 Base64 변환 방향을 먼저 확인하세요
문자열이나 이미지를 Base64로 바꾸려면 인코딩을, Base64 문자열을 원래 데이터로 확인하려면 디코딩을 선택하세요. API 테스트, Data URI 생성, 개발 중 데이터 확인에 활용할 수 있지만 Base64는 암호화 방식이 아니므로 민감한 정보를 보호하는 용도로 사용하면 안 됩니다.
Base64 인코더/디코더란?
Base64 인코더/디코더는 이진(Binary) 데이터와 일반 텍스트 데이터를 인터넷 상에서 손상 없이 안전하게 전송할 수 있도록 설계된 ASCII 문자 집합(64개 기호)으로 상호 변환해 주는 고성능 웹 유틸리티입니다. 이메일 전송 규격(MIME), HTML/CSS 문서 내 이미지 파일 직접 임베딩(Data URI 스킴), 네트워크 API 데이터 페이로드 가공 등 다양한 전송 매체에서 문자 깨짐 현상을 예방하고 호환성을 확보하는 데 필수적으로 사용되는 개발 및 시스템 통합 도구입니다.
사용 방법
- 1상단 탭에서 변환할 유형(텍스트 인코딩/디코딩 또는 이미지/파일 변환)을 선택합니다.
- 2텍스트를 변환할 경우 원문 텍스트를 붙여넣고 문자 인코딩 세트(기본 UTF-8)와 운영체제에 맞는 줄바꿈 문자(LF 또는 CRLF) 규격을 확인합니다.
- 3이미지 또는 일반 파일을 Data URI 코드로 변환하려면 업로드 영역에 파일을 끌어다 놓거나 선택합니다.
- 4'인코드(Encode)' 또는 '디코드(Decode)' 버튼을 누르면 즉시 변환 처리가 완료되어 출력 창에 결과가 나타납니다.
- 5결과물 복사 버튼을 눌러 소스 코드 파일(HTML, CSS, JSON 등)에 붙여넣거나, 변환된 이미지 미리보기를 확인하여 데이터 검증을 진행합니다.
Base64는 암호화가 아닌 전송용 표현이다
최근 검토: 2026년 7월 11일Base64 길이와 변환 공식
인코딩 문자 수 = 4 × ceil(바이트 수 ÷ 3); 24비트 = 6비트 조각 4개
3바이트를 4개의 6비트 값으로 나눠 64개 문자표에 매핑하므로 원본보다 문자열이 길어집니다.
Cat 문자열을 Base64로 인코딩하는 경우
- • UTF-8 텍스트 Cat
- • 문자열 바이트 수 3
- • 줄바꿈 없음
- 1. 3바이트를 24비트 블록으로 묶음
- 2. 4개의 6비트 값과 패딩 규칙을 적용해 Q2F0 생성
Cat은 Q2F0으로 인코딩되고, 3바이트가 4문자로 늘어나 약 33.3%의 길이 오버헤드가 생깁니다.
결과 해석
- Base64는 깨지기 쉬운 바이트를 ASCII 문자로 옮기는 형식 변환이며 비밀을 숨기지 않습니다.
- 작은 아이콘이나 Data URI에는 편리하지만 대용량 파일은 원본 URL이나 별도 저장소가 효율적입니다.
결과가 달라지는 조건
- UTF-8과 다른 문자셋을 섞으면 디코딩 결과가 깨질 수 있습니다.
- URL 쿼리에서 +와 /를 안전하게 다뤄야 하므로 URL-safe Base64가 필요한 경우가 있습니다.
자주 발생하는 입력 오류
- Base64 문자열을 API 키나 비밀번호 보호 수단으로 오해하면 정보가 그대로 노출됩니다.
- 복사 과정에서 끝의 = 패딩이나 줄바꿈을 임의로 제거하면 디코딩이 실패할 수 있습니다.
관련 지식 및 참고 자료
- ●Base64 변환 메커니즘: 8비트(1바이트) 3개로 이루어진 24비트의 이진 데이터를 6비트씩 4개로 쪼개어, 0~63으로 매핑된 64개의 ASCII 문자(대문자 A-Z, 소문자 a-z, 숫자 0-9, 기호 +, /)로 치환합니다. 남는 비트는 패딩 문자(=)로 메우게 됩니다.
- ●데이터 크기 증가: 24비트의 데이터가 32비트로 확장되므로, Base64로 인코딩된 데이터는 원본 바이너리 크기 대비 약 33%가 증가합니다. 따라서 네트워크 대역폭이나 파일 용량이 민감한 환경에서는 전송 효율성을 신중하게 따져봐야 합니다.
- ●Data URI 스킴 구조: data:[미디어타입];base64,[Base64코드] 형식으로 HTML의 <img> 태그나 CSS의 background-image 속성에 직접 이미지 데이터를 내장할 수 있어, 추가적인 HTTP 요청(Request) 횟수를 줄여 웹 페이지 로딩 속도를 최적화하는 데 기여합니다.
- ●주의사항: Base64는 전송을 위한 텍스트 포맷 변환(인코딩)일 뿐, 암호화(Encryption) 기술이 아닙니다. 디코더를 사용하면 누구나 원본 데이터를 복원할 수 있으므로, 민감한 개인정보나 시스템 접근 권한 토큰을 보안 처리 없이 Base64로만 감싸서 노출하는 것은 매우 위험합니다.
FAQ
Q.Base64 인코딩과 데이터 암호화(AES, RSA 등)의 결정적인 차이점은 무엇인가요?
인코딩은 데이터를 보안 가공하는 것이 아니라 컴퓨터 간에 서로 잘 이해할 수 있도록 형태(포맷)를 안전하게 변경하는 것입니다. 암호키가 없어도 공개된 표준 알고리즘에 따라 누구나 즉시 복구(디코딩)할 수 있습니다. 반면 암호화는 비밀키(Secret Key)를 소유한 사람만 해독할 수 있게 난독화하는 기술입니다. 따라서 보안이 필수인 정보는 반드시 암호화를 적용한 후 필요에 따라 전송용 Base64 인코딩을 추가로 결합하는 방식을 사용해야 합니다.
Q.HTML 문서에 이미지를 Data URI 형식으로 직접 넣으면 어떤 장단점이 있나요?
가장 큰 장점은 웹 브라우저가 외부 이미지 파일을 가져오기 위해 서버에 개별 HTTP 요청을 보내지 않아도 되므로 로딩 요청 횟수가 대폭 단축된다는 점입니다. 단점은 Base64 파일 변환으로 인해 전체 소스 코드 크기가 약 33% 커진다는 것입니다. 따라서 크기가 작은 아이콘, 로고, SVG 이미지 등은 Data URI가 유리하지만, 큰 고해상도 사진은 일반 이미지 파일 링크로 연결하는 것이 네트워크 리소스상 훨씬 유리합니다.
Q.디코딩 시 깨진 글자가 출력되거나 오류가 나는 원인은 무엇인가요?
가장 대표적인 원인은 문자 인코딩 설정의 불일치입니다. 예를 들어 UTF-8로 저장된 데이터를 EUC-KR 형식으로 디코딩하면 한글이 깨지게 됩니다. 또 다른 원인은 Base64 인코딩 데이터의 일부 문자가 유실되거나 공백, 특수 기호가 변형된 경우입니다. 특히 URL 파라미터로 Base64를 전송할 때 + 기호가 공백으로 자동 변환되는 문제를 막기 위해 Safe URL Base64 규격을 적용했는지 검토해야 합니다.
Q.Base64 뒤에 붙어있는 = 문자(패딩)는 어떤 역할을 하나요?
Base64 인코딩은 3바이트 단위로 데이터를 쪼갭니다. 그러나 원본 데이터의 크기가 3의 배수로 떨어지지 않고 1바이트 또는 2바이트가 남을 수 있습니다. 이때 데이터의 완결성을 맞추고 디코더가 올바른 길이로 복구할 수 있도록 부족한 부분을 표시해주는 채움 기호가 바로 패딩(=) 기호입니다. 남은 바이트에 따라 끝에 = 혹은 ==가 붙게 됩니다.
