Base64 인코딩 / 디코딩

브라우저에서 텍스트를 Base64로 변환하고 다시 디코딩합니다. UTF-8 안전 처리와 선택적 URL-safe 변형을 지원하며, 어떤 데이터도 서버에 업로드되지 않습니다.

입력

0 줄 · 0 자

모드

URL-safe

Base64 인코딩 / 디코딩 사용 방법

1
인코딩 또는 디코딩 선택
텍스트를 Base64로 변환하려면 Mode를 Encode로, Base64 문자열을 읽을 수 있는 텍스트로 되돌리려면 Decode로 설정하세요.
2
입력값 입력
텍스트나 Base64를 입력 패널에 입력하거나 붙여넣고, 필요하다면 URL 및 파일명에 안전한 문자 집합을 쓰는 URL-safe를 켜세요.
3
변환
Convert를 클릭하면 입력값이 브라우저 안에서 로컬로 처리되며, UTF-8과 이모지를 완전히 지원합니다.

4
복사 또는 교체
결과를 복사하거나, Swap을 사용해 출력값을 입력란으로 옮기고 모드를 바꿔 빠르게 왕복 변환하세요.

Base64 인코딩 완전 가이드

Base64란 정확히 무엇인가요

Base64는 바이너리를 텍스트로 변환하는 인코딩 방식입니다. 임의의 바이너리 데이터를, 평문을 다루도록 만들어진 시스템을 거쳐도 손상되지 않는 64개의 출력 가능한 ASCII 문자만으로 표현합니다. RFC 4648에 정의된 표준 알파벳은 대문자 26자 A-Z, 소문자 26자 a-z, 숫자 10개 0-9, 그리고 두 기호 + 와 / 로 이루어집니다. 모두 합쳐 64개의 기호이며, 2의 6제곱이 64이므로 이는 문자 하나당 정확히 6비트의 데이터를 표현하기에 딱 맞습니다.

이름은 글자 그대로의 의미를 담고 있습니다. base 10이 열 개의 숫자 기호를 쓰고 base 16(16진수)이 열여섯 개를 쓰듯, base 64는 예순네 개를 씁니다. 이 인코딩은 완전히 가역적이며 무손실입니다. 인코딩한 어떤 바이트든 복호화하면 바이트 하나하나가 동일하게 되돌아오며, 바로 그 점이 핵심입니다.

Base64가 존재하는 이유

많은 통신 채널은 원시 바이트가 아니라 텍스트를 실어 나르도록 설계되었고, 출력 가능한 ASCII 범위를 벗어나는 것은 무엇이든 망가뜨립니다. 이메일이 대표적인 예입니다. 초기 SMTP 표준은 7비트 프로토콜이라 바이너리 데이터의 최상위 비트를 손상시키거나 떼어 낼 수 있었고, 그래서 MIME은 이미지와 파일 첨부를 안전하게 보내기 위해 Base64를 사용합니다. 바이너리가 무언가 텍스트적인 것 안에 실려 가야 할 때면 언제나 같은 문제가 나타납니다.

여러분은 알아채지 못한 채 끊임없이 Base64를 만나고 있습니다. 데이터 URI는 data:image/png;base64,iVBORw0K... 처럼 HTML과 CSS에 이미지를 직접 끼워 넣어, 작은 아이콘이 별도의 요청을 필요로 하지 않게 합니다. JSON Web Token(JWT)은 점으로 이어진 세 개의 Base64url 구획입니다. HTTP 기본 인증은 username:password 를 Base64로 보냅니다. 브라우저는 내장 함수 btoa 와 atob 를 통해 이를 노출하며, 이것이 JSON이나 XML, URL 안에 바이너리 페이로드를 담는 표준적인 방법입니다.

3바이트에서 4문자로의 대응 원리

Base64는 입력을 한 번에 3바이트씩 처리합니다. 3바이트는 24비트이고, 24는 6비트씩 네 묶음으로 정확히 나누어집니다. 6비트로 된 각 묶음은 0부터 63까지의 숫자이며, 이것이 알파벳의 문자 하나가 됩니다. 그래서 입력 3바이트마다 언제나 정확히 4개의 출력 문자가 만들어지고, 바로 이 때문에 Base64는 데이터를 약 3분의 1 정도 부풀립니다. 인코딩된 형태는 원본 크기의 약 133%입니다.

중요한 것은 알파벳에서의 위치입니다. 인덱스 0은 A, 인덱스 25는 Z, 인덱스 26은 a, 인덱스 51은 z, 인덱스 52는 0, 인덱스 61은 9, 인덱스 62는 +, 인덱스 63은 / 입니다. 인코딩된 문자열을 손으로 읽으려면 각 문자를 그 인덱스로 되돌리고, 그 인덱스를 6비트로 적은 다음, 모든 비트를 이어 붙인 뒤 그 흐름을 다시 8비트짜리 바이트로 잘라 내면 됩니다.

직접 해 보는 예시: "Man" 인코딩하기

세 글자 M, a, n 을 봅시다. 이들의 ASCII 바이트 값은 77, 97, 110이고, 이진수로는 01001101, 01100001, 01101110 입니다. 이 24비트를 하나의 흐름으로 이어 붙이면 010011010110000101101110 이 됩니다. 이제 이것을 6비트짜리 네 묶음으로 자릅니다. 010011, 010110, 000101, 101110.

이 묶음들은 숫자 19, 22, 5, 46입니다. 각각을 알파벳에서 찾아보면 T(인덱스 19), W(인덱스 22), F(인덱스 5), u(인덱스 46)가 됩니다. 따라서 "Man"은 "TWFu"로 인코딩됩니다. 패딩이 필요 없는 깔끔한 3바이트 대 4문자 변환입니다. 복호화는 그저 이 단계를 거꾸로 진행할 뿐입니다.

패딩과 등호 기호

입력이 항상 3바이트의 배수인 것은 아니므로, Base64는 나머지를 알릴 방법이 필요합니다. 1바이트가 남으면 2개의 문자 뒤에 2개의 패딩 표시(==)가 붙어 인코딩되고, 2바이트가 남으면 3개의 문자 뒤에 1개의 패딩 표시(=)가 붙어 인코딩됩니다. 패딩 문자 자체는 아무 데이터도 담지 않습니다. 마지막 묶음이 실제 바이트 몇 개를 나타내는지 디코더에게 알려 줄 뿐입니다.

예를 들어 단일 문자 "M"(바이트 77, 이진수 01001101)은 6비트 010011 과 010000 으로 패딩되어 T 와 Q 가 되고, 이어 == 로 완성되어 "TQ=="가 됩니다. 단어 "Ma"(2바이트)는 끝에 등호가 하나 붙은 "TWE="로 인코딩됩니다. 임의의 Base64 문자열 끝에 붙은 등호 개수를 세어 보면 원본 길이가 3의 배수였는지 알 수 있습니다.

URL-safe 변형

표준 문자인 + 와 / 는 이미 고유한 의미를 가진 곳에서 문제를 일으킵니다. URL에서 슬래시는 경로 구획을 나누고, 폼 인코딩된 쿼리 문자열에서 더하기 기호는 공백으로 해석되므로, 일반적인 Base64 값을 링크나 파일 이름에 넣으면 깨질 수 있습니다. 역시 RFC 4648에 정의된 URL-safe 알파벳은 + 를 - (하이픈)으로, / 를 _ (밑줄)로 바꿔 이 문제를 해결합니다.

이 도구에서 URL-safe 옵션을 켜면 그 변형을 만들어 내며, 등호 또한 URL에서 이스케이프가 필요하므로 끝에 붙는 = 패딩도 함께 떼어 냅니다. 그 결과는 쿼리 매개변수, 경로 구획, 쿠키, 파일 이름에 곧바로 들어맞습니다. JWT와 많은 웹 API가 사용하는 인코딩이 바로 이것입니다. 다만 URL-safe 입력은 URL-safe 디코더로 복호화해야 한다는 점만 기억하세요. - 와 _ 문자는 표준 알파벳에서는 유효하지 않기 때문입니다.

Base64는 인코딩이지 암호화가 아닙니다

이것은 Base64에 관해 가장 중요하면서도 가장 흔히 오해되는 단 하나의 사실입니다. 인코딩은 데이터를 오직 맨눈에 대해서만 가릴 뿐, 기밀성을 전혀 제공하지 않습니다. 키도 없고 비밀도 없으므로, 이 도구를 포함한 어떤 도구로든 누구나 Base64 문자열을 즉시 복호화할 수 있습니다. Base64를 비밀번호나 API 키, 개인 정보를 숨기는 수단으로 여기는 것은 심각한 보안 실수입니다.

Base64는 비밀의 문제가 아니라 전송의 문제를 해결합니다. 텍스트 전용 채널을 통해 바이너리를 안전하게 옮길 수 있게 해 줄 뿐입니다. 실제 보호가 필요하다면 먼저 AES 같은 진짜 알고리즘으로 데이터를 암호화하고, 그 암호문이 텍스트로 이동해야 할 때에 한해서만 그것을 Base64로 인코딩하세요. 인코딩과 암호화는 서로 다른 일입니다.

흔한 실수와 실전 팁

가장 빈번한 오류는 문자 집합 혼동입니다. Base64 자체는 바이트만 알 뿐이므로, 텍스트를 인코딩하려면 먼저 그 텍스트가 어떻게 바이트가 되는지를 정해야 합니다. 이 도구는 UTF-8을 사용하며, 그래서 악센트가 붙은 글자와 이모지가 정확히 왕복합니다. 같은 문자열을 다른 곳에서 다른 문자 집합으로 인코딩하면 다른 Base64가 나옵니다. 또 다른 흔한 함정은 공백입니다. 일부 인코더가 삽입하는 줄바꿈(MIME은 76자에서 줄을 접습니다)은 데이터의 일부가 아니므로 복호화 전에 제거해야 하지만, 엄격한 디코더는 이를 거부할 수도 있습니다.

그 밖의 함정으로는 표준 알파벳과 URL-safe 알파벳을 섞어 쓰는 것, 패딩이 없는 문자열은 엄격한 디코더가 받아들이기 전에 패딩을 복원해야 할 수 있다는 점을 잊는 것, 그리고 Base64가 공간을 아껴 준다고 넘겨짚는 것이 있습니다. Base64는 결코 공간을 아끼지 않으며, 언제나 페이로드를 약 3분의 1만큼 늘립니다. 여기서 복호화가 실패하면, 먼저 끼어든 공백 하나, 빠진 등호 하나, 또는 URL-safe 알파벳에 속하는 - 나 _ 가 있는지 확인하세요.

자주 묻는 질문

여기서 인코딩과 디코딩의 차이는 무엇인가요?

인코딩은 일반 텍스트를 Base64 표현으로 변환하고, 디코딩은 Base64 문자열을 받아 원래 텍스트로 복원합니다. Mode 토글로 둘 사이를 전환할 수 있습니다.

URL-safe 옵션은 무슨 역할을 하나요?

URL-safe Base64는 + 와 / 문자를 - 와 _ 로 바꾸고 끝의 = 패딩을 제거하므로, 결과를 URL, 쿼리 문자열, 파일명에 별도 이스케이프 없이 바로 넣을 수 있습니다.

이모지와 영어가 아닌 문자도 처리하나요?

네. 텍스트는 변환 전에 UTF-8로 인코딩되므로, 악센트 문자, 비라틴 문자, 이모지가 인코딩과 디코딩 과정에서 정확하게 보존됩니다.

디코딩 중 잘못된 Base64를 붙여넣으면 어떻게 되나요?

잘못된 형식의 Base64를 감지해 깨진 결과 대신 입력 오류 메시지를 표시하여, 오타를 확인하거나 Encode 모드로 전환하도록 안내합니다.

내 데이터가 어딘가로 전송되나요?

아니요. 변환기는 JavaScript로 브라우저 안에서만 실행되므로 텍스트와 Base64 문자열이 기기를 벗어나지 않아, 민감하거나 독점적인 데이터에도 안전합니다.