Base64 인코딩 / 디코딩

Base64란?#

Base64는 임의의 바이트 를 64개의 출력 가능한 ASCII 문자(A-Z, a-z, 0-9, +, /, 패딩용 =)만으로 적는 방법입니다. 컴퓨팅 세계의 상당 부분이 텍스트를 기준으로 설계되었기에 존재합니다. 이메일 본문, JSON 필드, HTTP 헤더, data-URI 접두어가 그것들이며, 원시 바이트, 특히 최상위 비트가 켜진 바이트나 제어 코드가 박힌 바이트에 걸립니다. Base64는 이진 모양의 데이터가 텍스트 전용 채널을 살아남아야 할 때 찾는 공통어입니다.

입력 바이트 세 개(24비트)가 네 개의 base64 문자(각 6비트를 인코딩)가 됩니다. 그래서 base64 출력은 항상 네 문자의 배수 길이이며, 원본 바이트보다 약 33% 더 큽니다. 이 중복이 출력 가능성의 대가입니다. 입력 길이가 3의 배수가 아닐 때, 끝에 = 패딩 문자 한두 개가 나타납니다.

이 페이지는 base64를 UTF-8과 안전하게 인코딩하고 디코딩합니다. 사람들이 계속 부딪히는 함정: 문자열을 그냥 btoa()에 넘기면 non-ASCII 문자(é, 中文, 이모지)가 들어있는 순간 InvalidCharacterError를 던집니다. 해결책은 텍스트를 먼저 UTF-8 바이트로 인코딩한 뒤 base64를 취하는 것이며, 이 도구가 정확히 그렇게 합니다. 그래서 café가 예외를 던지는 대신 올바로 왕복합니다.

사용 방법#

1. 도구 모음 왼쪽 위의 인코딩 / 디코딩 토글로 방향을 고르세요.
2. 왼쪽 입력 패널에 타이핑하거나 붙여넣으세요.
   • 인코딩 모드에서는 입력을 UTF-8 텍스트로 취급합니다.
   • 디코딩 모드에서는 입력이 base64 문자열이어야 합니다. 공백은 허용됩니다.
3. base64url 알파벳(+// 대신 -/_, 패딩 제거)이 필요하면 URL 안전 에 체크하세요. JWT와 많은 서명 URL 방식이 이것을 기대합니다.
4. 결과는 오른쪽 출력 패널에 실시간으로 나타납니다. 복사 로 가져가세요.
5. 예제 로 데모 쌍을 채우고, 지우기 로 양쪽 패널을 초기화하세요.

주요 기능#

• 양방향 모두 UTF-8 안전. 인코딩은 먼저 텍스트를 TextEncoder로 통과시켜 멀티바이트 문자가 폭발하지 않고, 디코딩은 바이트를 TextDecoder로 통과시켜 원래 텍스트가 정확히 복원됩니다.
• 표준과 URL 안전 알파벳. 체크박스 하나로 고전 base64(+/=)와 base64url(패딩 없는 -_)을 전환하며, 디코딩 시 올바르게 다시 패딩을 채웁니다.
• 순수 클라이언트 사이드. 변환은 브라우저에서만 실행됩니다. 백엔드도, 네트워크 요청도 없습니다. 민감한 토큰을 여기 붙여넣어도 어디에도 보내지 않습니다.
• 실시간 상태 줄. 패널 아래 바는 (예를 들어 % 모양이거나 잘린 입력에 대해) 인코딩/디코딩 오류를 조용히 쓰레기를 만드는 대신 보고합니다.

실전 예시#

인코딩 과 표준(URL 안전 아님) 모드에서, ASCII 텍스트 Hello, World!는 이렇게 됩니다.

SGVsbG8sIFdvcmxkIQ==

끝의 = 두 개는 13바이트 입력이 3의 배수가 아니었음을 보여줍니다. 실수가 아니라 예상된 것입니다.

UTF-8 처리는 ASCII를 벗어나는 즉시 중요해집니다. café(é는 UTF-8 바이트 두 개, c3 a9)를 인코딩하면:

Y2Fmw6k=

콘솔에서 btoa("café")를 직접 호출했다면 예외를 던졌을 것입니다. 이 도구는 그렇지 않은데, UTF-8 바이트를 먼저 인코딩하기 때문입니다.

URL 안전 모드는 알파벳을 다시 써서 출력이 URL이 오독할 문자를 결코 담지 않게 합니다. +는 -로, /는 _로, 끝의 = 패딩은 제거됩니다(디코딩 시 자동으로 다시 추가). 위의 표준 출력 SGVsbG8sIFdvcmxkIQ==을 보면 — URL 안전 모드에서 두 패딩 =가 벗겨져 SGVsbG8sIFdvcmxkIQ가 됩니다. +// → -/_ 교체는 그 문자들이 출력에 실제로 나타날 때만 의미가 바뀌는데, 이는 보통 해시 다이제스트나 무작위 토큰 같은 이진 페이로드에서 일어납니다. 바로 더 이상의 이스케이프 없이 URL 경로나 쿼리 매개변수에 끼워 넣을 데이터입니다.

FAQ#

디코딩한 텍스트가 깨져 보입니다. 무슨 일이 일어난 건가요?#

거의 항상, 디코딩한 base64가 UTF-8이 아니라 다른 문자 집합(보통 Latin-1이나 Windows-1252)으로 인코딩된 바이트였기 때문입니다. 이 도구는 바이트를 UTF-8로 디코딩하므로, Latin-1으로 인코딩된 é(0xe9, 홀로 선 바이트)는 올바른 UTF-8이 아니어서 깨져 보입니다. 반대편이 원래 텍스트를 어떻게 인코딩했는지 알아내거나, 먼저 UTF-8으로 다시 인코딩하세요.

표준 base64와 base64url 중 어느 쪽을 원하나요?#

표준(+/=)은 URL에 들어가지 않는 모든 것의 기본값입니다. 이메일 첨부, data: URI, 이진을 담는 JSON 필드. 출력이 URL 경로·쿼리 문자열·JWT 세그먼트에 놓일 것이라면 URL 안전 을 켜세요. 그 자리에서는 +, /, =가 파싱을 깨거나 전송 중에 망가집니다. 어느 형태든 디코딩은 자동으로 받아들여집니다.

왜 인코딩된 출력이 내 입력보다 길가요?#

버그가 아니라 본질적입니다. Base64는 문자마다 8비트가 아니라 6비트를 담으므로, 출력은 입력의 약 4/3 크기입니다. 대략 33% 오버헤드입니다. 매우 작은 입력에서는 고정 구조가 지배하므로 원본에 비해 상대적으로 더 커 보일 수 있습니다.

이 도구로 base64 문자열을 복호화하거나 크랙할 수 있나요?#

아니요. base64는 암호화가 아니라 인코딩 입니다. 설계상 완전히 가역적이며 키를 가지지 않습니다. 문자열을 가진 누구나 디코딩할 수 있습니다. 실제로 비밀성이 필요하다면 먼저 암호화하고(예: 인증된 암호화 방식) 그 다음 암호문을 전송을 위해 base64로 인코딩하세요.