Base64는 바이너리 데이터를 ASCII 문자열로 변환하는 인코딩 방식입니다. A-Z, a-z, 0-9, +, / 총 64개의 인쇄 가능한 문자를 사용하여 데이터를 표현합니다. 이메일 첨부파일(SMTP), 웹 이미지 데이터 URI, JWT 토큰, HTTP Basic 인증 등에서 광범위하게 쓰이며, 텍스트만 지원하는 시스템에서 바이너리 데이터를 안전하게 전송할 수 있게 해줍니다. 원본 대비 약 33% 크기가 증가하지만, 데이터 손실 없이 전달할 수 있다는 점에서 개발 현장에서 필수적인 도구입니다. Base64라는 이름은 사용하는 문자 집합이 정확히 64개라는 데서 유래했으며, 1987년 RFC 989에서 PEM(Privacy-Enhanced Mail)의 일부로 처음 표준화되었습니다. 현재 가장 널리 참조되는 표준은 2006년에 발행된 RFC 4648로, 일반 Base64와 URL-safe 변형을 모두 정의하고 있습니다. URL 인코딩이나 Hex 인코딩 같은 다른 텍스트 인코딩 방식과 비교하면, Base64는 인코딩 효율성과 가독성 사이에서 좋은 균형을 제공합니다.

작동 원리

Base64 인코딩은 입력 데이터를 3바이트(24비트) 단위로 묶어 처리합니다. 24비트를 6비트씩 4그룹으로 나누고, 각 6비트 값(0~63)을 미리 정해진 64개 문자 테이블에서 대응하는 문자로 변환합니다. 예를 들어 "Hi"라는 문자열은 UTF-8로 0x48 0x69 두 바이트인데, 이를 이진수로 펼치면 01001000 01101001이 됩니다. 3바이트에 맞추기 위해 끝에 0 패딩을 붙여 01001000 01101001 00000000으로 만들고, 6비트씩 나누면 010010 000110 100100 000000이 됩니다. 각각 테이블에서 S, G, k, A에 해당하므로 마지막 패딩 바이트 위치에 =를 넣어 최종 결과는 "SGk="가 됩니다. 이처럼 3바이트가 4문자로 변환되기 때문에 출력 크기가 약 33% 증가하는 것입니다.

인코딩과 디코딩 따라 하기

상단 왼쪽의 인코딩 / 디코딩 탭에서 작업 방향을 선택합니다. 탭을 바꾸면 입력·출력 칸의 라벨도 함께 바뀝니다.
왼쪽 입력 칸에 텍스트(인코딩 모드) 또는 Base64 문자열(디코딩 모드)을 붙여넣습니다. 실시간 옵션이 켜져 있으면 입력하는 즉시 결과가 표시됩니다.
URL 파라미터나 파일명에 넣을 결과가 필요하면 URL-safe를 체크합니다. +는 -로, /는 _로 바뀌고 끝의 = 패딩이 제거됩니다.
실시간 옵션을 껐다면 인코딩(또는 디코딩) 버튼을 눌러 변환을 실행합니다.
화살표 모양의 교체 버튼을 누르면 출력 내용이 입력 칸으로 옮겨지면서 모드가 반대로 전환되어, 방금 인코딩한 결과를 바로 디코딩해 검증할 수 있습니다.
결과는 복사 버튼으로 클립보드에 담고, 지우기로 양쪽 칸을 초기화합니다.

개발 현장에서 만나는 Base64

이미지를 데이터 URI로 인라인하기. 작은 아이콘이나 로고를 별도 HTTP 요청 없이 CSS나 HTML에 직접 넣을 때 data:image/png;base64,iVBORw0KGgo... 형태의 데이터 URI를 사용합니다. 파일 크기가 33% 커지는 대신 요청 횟수가 줄어들기 때문에, 수 KB 수준의 작은 리소스에만 쓰는 것이 좋습니다.

HTTP Basic 인증 헤더 만들기. Basic 인증은 아이디:비밀번호 문자열을 Base64로 인코딩해 헤더에 넣는 방식입니다. 예를 들어 user:pass1234를 인코딩하면 dXNlcjpwYXNzMTIzNA==가 되고, 요청에는 Authorization: Basic dXNlcjpwYXNzMTIzNA==로 들어갑니다. API 테스트 중 헤더 값을 빠르게 만들거나, 로그에 찍힌 헤더를 디코딩해 어떤 계정이 쓰였는지 확인할 때 유용합니다.

JWT 토큰 들여다보기. JWT의 헤더와 페이로드는 URL-safe Base64로 인코딩된 JSON입니다. 토큰을 점(.) 기준으로 나눈 뒤 앞의 두 조각을 URL-safe 옵션을 켜고 디코딩하면 {"alg":"HS256","typ":"JWT"} 같은 내용이 그대로 보입니다. 여기서 알 수 있듯 Base64는 암호화가 아니므로, 페이로드에 민감한 정보를 넣으면 누구나 읽을 수 있다는 점을 꼭 기억해야 합니다.

자주 묻는 질문

결과 끝에 붙는 = 기호는 무엇인가요?

패딩 문자입니다. Base64는 3바이트를 4문자로 변환하는데, 원본 길이가 3의 배수가 아니면 부족한 자리를 =로 채워 출력 길이를 4의 배수로 맞춥니다. 원본이 3으로 나눠 1바이트 남으면 ==, 2바이트 남으면 = 하나가 붙습니다.

URL-safe 옵션은 언제 켜야 하나요?

일반 Base64의 +와 /는 URL에서 각각 공백과 경로 구분자로 해석될 수 있어 문제가 됩니다. 인코딩 결과를 URL 쿼리 파라미터, 파일명, JWT처럼 URL에 노출되는 곳에 쓸 예정이라면 URL-safe를 켜세요. 반대로 URL-safe로 만들어진 문자열(-나 _가 포함된 경우)을 디코딩할 때도 이 옵션을 켜야 정상적으로 풀립니다.

한글을 인코딩해도 깨지지 않나요?

이 도구는 한글을 포함한 모든 문자를 먼저 UTF-8 바이트로 변환한 뒤 인코딩하므로 안전하게 왕복됩니다. 다만 다른 시스템에서 디코딩할 때 그쪽도 UTF-8로 해석해야 원래 글자가 복원됩니다. 다른 도구에서 디코딩한 한글이 깨진다면 대부분 문자 인코딩 해석 차이가 원인입니다.

디코딩할 때 오류가 나는 이유는 무엇인가요?

입력에 Base64 문자 집합 밖의 문자가 섞여 있거나, 문자열 길이가 4의 배수가 아니거나, URL-safe 문자열을 일반 모드로 디코딩하려 할 때 오류가 발생합니다. 복사 과정에서 줄바꿈이나 공백이 끼어드는 경우도 흔하니, 오류가 나면 먼저 앞뒤 공백과 개행을 제거해 보세요.

Base64로 비밀번호를 보호할 수 있나요?

없습니다. Base64는 키 없이 누구나 되돌릴 수 있는 단순 표현 변환이며, 암호화가 아닙니다. 데이터를 숨기는 것이 목적이라면 AES 같은 암호화 알고리즘을, 무결성 확인이 목적이라면 SHA-256 같은 해시를 사용해야 합니다.

인코딩하면 왜 용량이 커지나요?

3바이트(24비트)를 6비트씩 나눠 4개의 문자로 표현하기 때문에 출력이 원본보다 약 33% 커집니다. 대용량 파일을 Base64로 주고받으면 전송량이 그만큼 늘어나므로, 큰 데이터는 multipart 업로드 같은 바이너리 전송 방식이 더 효율적입니다.

입력한 내용이 외부로 전송되나요?

아니요. 변환은 브라우저에 내장된 btoa()/atob() 함수로 기기 안에서만 처리되며, 어떤 데이터도 서버로 전송되지 않습니다. 인증 토큰처럼 민감한 문자열을 다루는 중이라면 개발자 도구의 네트워크 탭에서 요청이 발생하지 않는 것을 직접 확인해 보셔도 됩니다.

이메일에서 복사한 Base64에 줄바꿈이 들어 있는 이유는요?

이메일에 쓰이는 MIME 표준은 인코딩 결과를 76자마다 줄바꿈하도록 정하고 있어서, 메일 원문에서 복사한 Base64에는 개행이 섞여 있는 경우가 많습니다. 디코더에 따라 이 개행을 허용하기도, 오류로 처리하기도 하므로 디코딩이 실패하면 줄바꿈을 모두 제거한 뒤 다시 시도해 보세요.

이미지 같은 파일도 여기서 인코딩할 수 있나요?

이 도구는 텍스트 입력 전용입니다. 파일을 통째로 인코딩하려면 macOS/Linux의 base64 파일명 명령이나 Windows의 certutil -encode를 사용하는 것이 편리합니다. 반대로 파일에서 추출한 Base64 문자열의 내용을 확인하는 용도로는 이 도구의 디코딩 모드를 그대로 활용할 수 있습니다.

같이 보면 좋은 도구

UTM 링크 생성기 - 마케팅 캠페인 추적용 UTM 링크 생성
Box Shadow 생성기 - CSS box-shadow 생성기
해시 생성기 - MD5, SHA-1, SHA-256 해시 생성
JSON 포매터 - JSON 정렬 및 검증
이미지 압축 - 이미지 파일 크기 줄이기

더 읽어볼 만한 글

Base64 인코딩의 원리

Base64 인코딩/디코딩