암호가 아니라 인코딩
Base64가 존재하는 이유는 많은 기반 시설이 텍스트를 전제로 만들어졌기 때문입니다. 이메일 헤더, JSON 문자열, URL, 데이터 속성은 모두 출력 가능한 ASCII는 안정적으로 다루지만 임의의 바이트는 잘 다루지 못합니다. 그래서 이진 데이터를 안전한 64개 문자로 다시 표현해 여정을 견디게 합니다.
이 도구는 텍스트를 인코딩·디코딩하며, 필요한 곳을 위한 URL 안전 변형과 패딩 없는 변형을 제공합니다.
인코딩·디코딩 하는 방법
설정한 방향으로 입력하는 즉시 변환됩니다.
- 입력란에 텍스트를 붙여넣으세요.
- 방향을 고르세요. 텍스트를 base64로 인코딩할지, base64를 텍스트로 되돌릴지입니다.
- 결과가 URL이나 파일명에 들어간다면 URL 안전 옵션을 켜세요. `+`를 `-`로, `/`를 `_`로 바꿉니다.
- JWT 조각처럼 받는 쪽이 끝의 `=`를 기대하지 않는다면 패딩을 끄세요.
- 바이트 수를 확인하세요. Base64 출력은 입력보다 약 3분의 1 커지며, 카운터가 그것을 보여 줍니다.
- 결과를 복사하거나, 교체 버튼으로 출력을 다시 입력에 넣어 왕복이 맞는지 확인하세요.
인코딩이 작동하는 방식
Base64는 3바이트 즉 24비트를 가져와 6비트씩 네 묶음으로 다시 나누고, 각 묶음을 64개 문자 중 하나에 대응시킵니다. 3바이트가 들어가 4글자가 나오며, 여기서 약 33%의 크기 증가가 생깁니다. 입력 길이가 3의 배수가 아니면 마지막 묶음을 `=`로 채워 출력 길이를 4의 배수로 유지합니다.
이 도구는 base64 단계 전에 텍스트를 UTF-8로 인코딩하며, 이는 ASCII 밖의 모든 것에 중요합니다. 이모지 하나는 UTF-8에서 4바이트라 base64 8글자가 되고, 한글·중국어·일본어 문자는 보통 각 3바이트입니다. 바이트 카운터는 글자 수가 아니라 실제 입력 크기를 보여 주는데, ASCII를 벗어나면 둘이 크게 갈라지기 때문입니다.
변형과 쓰이는 곳
차이는 작고, 그 차이에 대해 사용처는 너그럽지 않습니다.
| 변형 | 62·63번 문자 | 패딩 | 주로 쓰이는 곳 |
|---|---|---|---|
| 표준 | + 와 / | 있음, = 사용 | 이메일, 데이터 URI, 일반 인코딩 |
| URL 안전 | - 와 _ | 흔히 생략 | URL, 파일명, JWT 조각 |
| 패딩 없음 | 어느 쪽이든 | 없음 | JWT, 일부 API, 짧은 토큰 |
표준 인코딩 문자열을 URL에 넣으면 대개 멀쩡히 지나갑니다. `+`가 공백으로 해석되거나 `/`가 경로를 쪼개기 전까지는요. 해당 값이 그 문자를 포함하느냐에 달렸기 때문에 이 고장은 간헐적으로 나타납니다.
Base64가 하는 일이 아닌 것
암호화가 아니며 어떤 기밀성도 제공하지 않습니다. 디코딩에는 키도 노력도 필요 없으므로, base64로 인코딩된 비밀번호는 한 단계가 더 붙은 평문 비밀번호입니다. HTTP 기본 인증에 등장하는 이유도 정확히 이것, 보호가 아니라 전송 인코딩, 이고, 그래서 기본 인증은 TLS 위에서만 허용됩니다.
압축 형식도 아닙니다. Base64는 데이터를 약 3분의 1 키우므로, 파일을 인코딩해 HTML이나 JSON에 심는 것은 대역폭을 편의와 맞바꾸는 일입니다. 작은 아이콘이라면 대개 남는 장사이고, 덩치가 있는 것이라면 피할 일입니다. 모든 처리는 브라우저에서 이루어지며 붙여넣은 내용은 전송되거나 저장되지 않습니다.