본문으로 건너뛰기

Base64 인코더 디코더 - 무료 온라인 Base64 변환 도구

Base64 인코더 디코더는 텍스트를 Base64 문자열로 바꾸거나 Base64 문자열을 원래 텍스트로 되돌리는 무료 온라인 도구다. 유니코드와 이모지도 정확히 처리하며, 설치나 로그인, 파일 업로드 없이 브라우저에서 바로 쓸 수 있다.

Base64 인코더/디코더

텍스트를 Base64 인코딩으로 변환하고 그 반대로 변환

로딩 계산기...
📚

문서화

Base64 인코딩이란?

Base64는 이미지 같은 바이너리 데이터를 포함한 모든 데이터를 문자, 숫자 및 몇 가지 기호만으로 이루어진 일반 텍스트로 변환하는 방법입니다. base64 인코더는 데이터를 이러한 텍스트 형식으로 변환합니다. base64 디코더는 이를 원래 데이터로 되돌립니다. 프로그램은 일반 텍스트를 요구하는 이메일이나 JSON 같은 시스템을 통해 바이너리 데이터를 안전하게 전송할 때 Base64를 사용합니다.

Base64는 64개의 문자로 이루어진 알파벳을 사용합니다.

  • 대문자 A–Z (26개)
  • 소문자 a–z (26개)
  • 숫자 0–9 (10개)
  • 일반적으로 + 및 /인 두 기호 (2개)

일부 시스템은 패딩으로 출력 끝에 등호(=)도 사용합니다. 패딩은 64자 알파벳에 포함되지 않으며, 길이를 맞추기 위해 추가될 뿐입니다.

Base64가 필요한 이유

이메일(SMTP)과 HTTP의 일부를 비롯한 많은 오래된 텍스트 프로토콜은 7비트 ASCII 텍스트를 전송하도록 만들어졌습니다. 이러한 프로토콜은 JPEG 이미지 내부의 바이트처럼 원시 바이너리 바이트를 손상시킬 수 있습니다. Base64는 모든 바이트를 안전하고 출력 가능한 문자만으로 표현하여 이 문제를 피합니다. 따라서 이메일 첨부 파일, 웹 페이지에 삽입된 이미지, JSON 내부의 바이너리 필드는 모두 흔히 먼저 Base64를 거칩니다.

Base64는 압축도 암호화도 아닙니다. 인코딩된 출력은 항상 입력보다 크며, 누구나 비밀번호나 키 없이 디코딩할 수 있습니다.

이 도구 사용 방법

  1. 입력 상자에 텍스트를 입력하거나 붙여 넣습니다.
  2. 텍스트를 Base64로 변환하려면 "Base64로 인코딩"을 선택하고, Base64 문자열을 다시 텍스트로 변환하려면 "Base64에서 디코딩"을 선택합니다.
  3. 입력하는 동안 출력이 자동으로 업데이트되도록 실시간 변환을 켭니다.
  4. 복사 버튼으로 결과를 복사합니다.

이 도구는 표준 유니코드 텍스트를 읽고 쓰므로 일반적인 영어 문자뿐 아니라 악센트가 붙은 문자, 기호, 이모지도 올바르게 인코딩하고 디코딩합니다.

Base64 인코딩의 작동 방식

Base64는 입력의 3바이트(24비트)를 4개의 출력 문자로 변환합니다(각 문자는 6비트를 담음). 이는 24를 6으로 나누면 4가 되기 때문입니다.

  1. 입력 바이트를 가져와 이진수로 씁니다.
  2. 비트를 24비트 단위(3바이트)로 묶습니다.
  3. 각 24비트 묶음을 네 개의 6비트 조각으로 나눕니다.
  4. 각 6비트 숫자(0~63)를 Base64 알파벳에서 찾아 해당 문자를 씁니다.

입력 길이가 3의 배수가 아니면 마지막 묶음은 짧습니다. 인코더는 0비트로 이를 패딩한 다음 출력에 = 문자를 추가하여 결과가 여전히 4개씩 묶이도록 합니다.

  • 남은 바이트가 하나이면 Base64 문자 2개와 ==가 생성됩니다.
  • 남은 바이트가 두 개이면 Base64 문자 3개와 = 하나가 생성됩니다.

Base64 인코딩 예

"Hello"라는 단어를 인코딩합니다.

  1. ASCII 값: 72, 101, 108, 108, 111
  2. 이진수: 01001000 01100101 01101100 01101100 01101111
  3. 처음 3바이트(24비트)를 네 개의 6비트 그룹으로 나눕니다: 010010 000110 010101 101100. 이는 숫자 18, 6, 21, 44이며, 문자 S, G, V, s에 해당합니다.
  4. 남은 2바이트(16비트)를 세 개의 6비트 그룹으로 나누고 끝에 2개의 0비트를 추가합니다: 011011 000110 111100. 이는 숫자 27, 6, 60이며, 문자 b, G, 8에 해당합니다.
  5. 2바이트가 남았으므로 끝에 = 하나를 추가합니다.
  6. 결과: SGVsbG8=

디코딩은 이 단계를 역순으로 수행합니다. 각 문자를 해당 6비트 숫자로 다시 매핑하고, 비트를 하나의 스트림으로 연결한 다음, 그 스트림을 8비트 바이트 단위로 읽어 냅니다.

Base64 인코딩 길이 공식

입력이 n바이트일 때 인코딩된 문자 길이는 다음과 같습니다.

encoded_length = 4 × ⌈n / 3⌉

여기서 ⌈x⌉는 가장 가까운 정수로 올림한다는 뜻입니다. 이 공식은 Base64 출력이 입력보다 항상 약 3분의 1 큰 이유를 보여 줍니다. 3개의 입력 바이트마다 출력 문자 4개가 필요하므로 33% 증가합니다.

Base64가 사용되는 곳

  • 이메일 첨부 파일(MIME). 이메일은 텍스트용으로 만들어졌으므로 파일 첨부는 전송 전에 Base64로 변환되며, 첨부 파일은 원본보다 약 33% 커집니다.
  • 데이터 URI. 작은 이미지는 data:image/png;base64,iVBORw0KGgo...와 같이 HTML이나 CSS 내부에 텍스트로 직접 삽입할 수 있어 별도의 파일 요청이 필요하지 않습니다. 큰 파일은 페이지를 불필요하게 크게 만들고 별도로 캐시할 수 없으므로 작은 파일에 가장 적합합니다.
  • API와 JSON. JSON에는 원시 바이너리 데이터를 저장하는 기본 방법이 없으므로 JSON API를 통해 전송되는 바이너리 파일은 흔히 먼저 Base64로 인코딩됩니다.
  • HTTP 기본 인증. Authorization 헤더는 사용자 이름과 비밀번호를 Base64로 인코딩합니다. 예를 들면 Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=와 같습니다. 이것만으로는 안전하지 않습니다. 가로채는 사람은 누구나 자격 증명을 읽을 수 있으므로 기본 인증은 HTTPS를 통해서만 사용해야 합니다.
  • JSON 웹 토큰(JWT). JWT의 세 부분은 각각 URL에 넣기에 안전한 변형인 Base64URL로 인코딩됩니다.
  • 바이너리 데이터를 텍스트로 저장하기. 텍스트만 허용하는 데이터베이스나 구성 파일은 바이너리 데이터를 Base64 문자열로 저장하는 경우가 있습니다.

Base64와 다른 인코딩의 비교

URL 안전 Base64는 표준 + 및 / 문자를 - 및 _로 바꿉니다. +와 /는 URL에서 특별한 의미를 갖기 때문입니다. JWT, URL 쿼리 매개변수, 파일 이름에 사용됩니다. 이 도구는 표준 Base64 출력을 생성하며, URL 안전 형식으로 바꾸려면 이 두 문자만 서로 교체하면 됩니다.

Base32는 32자 알파벳을 사용하므로 각 문자가 6비트가 아닌 5비트를 담습니다. 5바이트를 8개의 문자로 변환하여 60%의 오버헤드가 발생합니다(8 ÷ 5 = 1.6). Base64의 33%와 비교되는 수치입니다. 출력 내용을 손으로 입력하거나 전화로 읽어야 할 때 Base32를 선택하는데, 대소문자 혼용과 쉽게 혼동되는 문자를 피할 수 있기 때문입니다.

16진수는 16개의 문자(0–9, A–F)를 사용하며 바이트당 2개의 문자가 필요해 크기가 두 배가 됩니다(100% 오버헤드). 크기를 작게 만드는 것보다 가독성이 중요한 해시, 색상, MAC 주소를 표시할 때 흔히 사용됩니다.

Base64를 사용하지 말아야 할 때

Base64는 크기와 CPU 비용을 증가시키므로 네트워크로 대용량 파일을 전송할 때 적합하지 않습니다. 원시 바이너리 데이터를 직접 전송하는 편이 더 작고 빠릅니다. 이를 비밀번호나 API 키 같은 민감한 정보를 숨기는 데 사용해서는 안 됩니다. 디코딩에 비밀 정보가 필요하지 않기 때문입니다. 대용량 파일을 저장할 때는 텍스트 필드에 긴 Base64 문자열을 저장하는 것보다 데이터베이스의 바이너리 열 형식이나 파일 저장 서비스를 사용하는 편이 일반적으로 낫습니다.

흔한 오류

  • UTF-8 변환 생략. 악센트가 붙은 문자나 이모지가 포함된 텍스트를 먼저 UTF-8 바이트로 변환하지 않고 인코딩하면 출력이 손상될 수 있습니다.
  • 패딩 제거. 일부 시스템은 끝의 = 문자를 제거합니다. 대부분의 디코더는 문자열 길이를 4의 배수가 되도록 다시 패딩하면 작동하지만, 모든 디코더가 이를 허용하는 것은 아니므로 패딩을 유지하는 편이 안전합니다.
  • 남은 줄 바꿈. 오래된 MIME 기반 인코더는 76자마다 줄 바꿈을 삽입하지만, 대부분의 최신 디코더는 줄 바꿈이 없는 하나의 연속된 문자열을 요구합니다.
  • 변형 혼동. 표준 Base64와 URL 안전 Base64는 알파벳에서 같은 두 위치에 서로 다른 문자를 사용합니다. 잘못된 변형으로 디코딩하면 의미 없는 결과가 나오거나 오류가 발생합니다.

자주 묻는 질문

Base64는 암호화의 한 형태인가요? 아니요. Base64는 암호화가 아니라 되돌릴 수 있는 텍스트 인코딩입니다. 누구나 비밀번호 없이 Base64 문자열을 즉시 디코딩할 수 있습니다. 데이터를 비밀로 유지해야 한다면 AES 같은 암호화 알고리즘을 사용하세요.

Base64를 사용하면 데이터가 커지는 이유는 무엇인가요? 원시 바이트는 8비트를 담지만, Base64에서는 한 문자가 6비트만 담기 때문입니다. 3바이트(24비트)를 4개의 문자로 변환하면 출력은 입력보다 4/3, 즉 약 33% 커집니다.

Base64로 이미지와 기타 바이너리 파일을 인코딩할 수 있나요? 예. 이미지, PDF, 오디오를 포함한 모든 바이너리 파일은 Base64로 인코딩한 뒤 바이트 단위로 정확히 원래대로 디코딩할 수 있습니다. HTML이나 CSS에 삽입하는 작은 이미지에 흔히 사용되지만, 대용량 파일에는 적합하지 않습니다.

Base64와 Base64URL의 차이는 무엇인가요? Base64URL은 표준 + 및 / 문자를 - 및 _로 바꾸므로 추가 이스케이프 없이 URL이나 파일 이름에 넣어도 안전합니다. JWT가 이 이유로 Base64URL을 사용합니다.

디코딩할 때 Base64 문자열에 "invalid" 오류가 발생하는 이유는 무엇인가요? 가장 흔한 원인은 Base64 알파벳에 속하지 않는 문자입니다. 예를 들어 URL 안전 변형에서 사용하는 -와 _가 이에 해당합니다. 또는 문자열 길이가 4의 배수보다 1만큼 클 수도 있습니다. 그런 길이를 가진 유효한 Base64 문자열은 없습니다. 디코딩된 바이트가 유효한 UTF-8 텍스트가 아닌 경우에도 디코딩이 실패합니다. 이 도구는 문자열 내부의 공백과 줄 바꿈을 무시하며, 끝의 = 패딩이 제거된 문자열도 디코딩합니다.

Base64는 어디에서 유래했나요? 이 기술은 1980년대 텍스트 전용 메일 시스템을 통해 바이너리 데이터를 전송하기 위한 초기 방식에서 비롯되었으며, 1996년에 RFC 2045의 MIME 일부로 공식 표준화되었습니다. Base64, Base32, Base16의 현재 참조 사양은 RFC 4648입니다.