Base64 네 방향 변환 기준
Base64를 쓰는 이유와 이 도구의 범위
텍스트와 파일을 Base64 문자열로 인코딩하고, Base64 문자열을 다시 텍스트나 파일로 디코딩하는 도구입니다. 손에 있는 것이 원문인지 Base64 문자열인지, 그리고 그것이 텍스트인지 파일인지에 따라 네 개의 탭 중 하나를 고르면 됩니다. 모든 변환은 현재 브라우저에서 이뤄지며 입력한 텍스트와 파일은 서버로 보내지 않습니다.
탭을 골라 변환하는 순서
- 가진 것과 원하는 결과에 맞는 탭을 고릅니다. 원문 텍스트는 '텍스트 → Base64', 받은 Base64 문자열은 'Base64 → 텍스트', 이미지·문서 파일은 '파일 → Base64', 파일로 저장해야 할 Base64 문자열은 'Base64 → 파일'입니다.
- 텍스트나 Base64 문자열을 붙여넣거나, 파일 탭에서는 5MB 이하 파일을 선택합니다.
- 인코딩·디코딩·Base64 생성 버튼을 눌러 결과를 만듭니다.
- 결과를 복사합니다. 파일 탭에서는 결과를 TXT로 저장하거나 복원한 파일을 내려받습니다.
같은 값을 인코딩하고 되돌린 결과
- 입력
- Omneura
- 결과
- T21uZXVyYQ==
'텍스트 → Base64' 탭에서 영문 텍스트를 UTF-8 바이트로 바꾼 뒤 인코딩한 결과입니다. 이 문자열을 'Base64 → 텍스트' 탭에 넣으면 원문 Omneura가 그대로 돌아옵니다.
Base64 변환이 실제로 필요한 상황
- API 테스트용 문자열을 Base64로 만들거나 응답의 Base64 필드를 읽을 때
- 개발 로그나 설정값에 들어 있는 Base64 문자열의 원문을 확인할 때
- 작은 이미지나 아이콘을 데이터 URI로 만들어 HTML·CSS에 넣을 때
- API 응답이나 data URI에 담긴 이미지를 파일로 저장할 때
- 파일 데이터를 JSON 예제에 넣을 문자열로 준비할 때
- 다른 시스템이 만든 Base64 결과와 왕복 변환 결과를 비교할 때
탭별 입력 범위와 상한
- 텍스트 → Base64: UTF-8 텍스트, 공백과 줄바꿈 포함, 최대 8,192자
- Base64 → 텍스트: 표준 Base64 문자열, 공백·줄바꿈 포함 가능, 최대 8,192자
- 파일 → Base64: 브라우저가 읽을 수 있는 일반 파일, 파일당 최대 5MB, 이미지 미리보기
- Base64 → 파일: Base64 또는 data URI, 최대 8,388,608자, PNG·JPEG·GIF·WebP·BMP 형식 자동 감지
변환 전에 알아 둘 제약
- Base64는 암호화가 아니므로 누구나 원문으로 되돌릴 수 있습니다. 비밀 정보를 보호하지 않습니다.
- 문자 인코딩은 UTF-8만 지원합니다. EUC-KR처럼 다른 인코딩으로 만든 Base64는 한글이 깨져 보일 수 있습니다.
- Base64 결과는 원본 바이트보다 약 33% 커집니다.
- Base64 → 파일에서 data URI 정보도 없고 형식도 식별하지 못하면 확장자가 bin으로 제안됩니다.
Base64 대신 다른 방법이 나은 경우
네 개의 탭은 가진 것(원문·Base64 문자열)과 대상(텍스트·파일)의 조합이라 손에 있는 것으로 고르면 됩니다. 탭보다 먼저 따져 볼 것은 Base64가 이 작업에 맞는 방법인가입니다.
| 견주는 대상 | 닮은 점 | 이 도구를 고를 때 | 상대를 고를 때 |
|---|---|---|---|
| 터미널의 base64 명령 | 같은 표준을 따르므로 결과 문자열이 동일합니다. | 결과를 눈으로 확인하며 조금씩 바꿔 볼 때 | 스크립트에 넣어 반복 실행하거나 대용량을 처리할 때 |
| 브라우저 콘솔의 atob() | 같은 표준 디코딩을 수행합니다. | 한글이 섞여 있거나 결과를 바로 눈으로 확인할 때 | 이미 개발자 도구를 열어 둔 상태에서 영문 값을 한 번만 확인할 때 |
| 이미지 압축 | 둘 다 이미지 파일을 받아 다른 형태로 내보냅니다. | 파일을 코드나 설정 파일 안에 문자열로 심어야 할 때 | 파일을 파일로 유지하면서 용량만 줄이려 할 때 |
| 이미지를 서버에 올려 주소로 참조하기 | 둘 다 문서 안에서 이미지를 보여 줄 수 있습니다. | 파일 하나로 완결되어야 하거나 아주 작은 아이콘일 때 | 여러 페이지에서 재사용하거나 캐시가 필요할 때 |
| 보낸 사람에게 파일을 다시 요청하기 | 결국 같은 파일을 손에 넣는 방법입니다. | 문자열밖에 없고 즉시 확인해야 할 때 | 문자열이 중간에 잘렸을 가능성이 있을 때 |
변환 결과가 예상과 다를 때
| 증상 | 원인 | 조치 |
|---|---|---|
| 한글을 넣었더니 다른 사이트의 인코딩 결과와 다릅니다. | 상대가 UTF-8이 아닌 EUC-KR 같은 인코딩으로 바이트를 만들었습니다. | 이 도구는 UTF-8로만 변환합니다. 상대 도구의 문자 인코딩 설정을 UTF-8로 맞춰 비교합니다. |
| 텍스트를 붙여넣었더니 8,192자에서 잘립니다. | 텍스트 탭의 입력 상한에 걸렸습니다. | 원본을 텍스트 파일로 저장한 뒤 '파일 → Base64' 탭에서 처리합니다. 파일은 5MB까지 받습니다. |
| 결과 끝의 = 개수가 예제와 다릅니다. | 원본 바이트 수가 3의 배수인지에 따라 패딩이 달라집니다. | 정상입니다. 길이가 다르면 = 개수도 0개, 1개, 2개로 달라집니다. |
| '앞/뒤 공백 제거'를 켰는데도 결과가 바뀝니다. | 이 설정은 양끝 공백만 지웁니다. 문자열 안쪽의 줄바꿈이나 탭도 인코딩 대상 바이트입니다. | 원문을 그대로 보존해야 하는 값인지 먼저 확인하고, 아니라면 안쪽 공백까지 정리한 뒤 변환합니다. |
| 'Base64 → 텍스트'에서 유효하지 않은 문자열이라며 변환되지 않습니다. | '공백/줄바꿈 무시'가 꺼져 있거나, 옮기는 과정에서 Base64에 쓰이지 않는 문자가 섞였습니다. | '공백/줄바꿈 무시'를 켜고 다시 시도합니다. 그래도 안 되면 원본에서 문자열 전체를 다시 복사합니다. |
| 디코딩한 한글이 물음표나 깨진 기호로 나옵니다. | 보낸 쪽이 UTF-8이 아닌 인코딩으로 바이트를 만들었습니다. | 이 도구는 UTF-8로만 해석합니다. 보낸 쪽에 UTF-8로 다시 인코딩해 달라고 요청합니다. |
| 디코딩 결과가 알아볼 수 없는 기호 덩어리입니다. | 원본이 텍스트가 아니라 이미지나 압축 파일이었습니다. | 같은 문자열을 'Base64 → 파일' 탭에 넣어 저장한 뒤 해당 형식으로 엽니다. |
| 앞부분만 맞고 뒤가 잘립니다. | 복사할 때 문자열 끝의 = 를 포함한 마지막 조각이 빠졌습니다. | 원본에서 다시 전체를 복사합니다. 길이가 4의 배수인지 확인하면 빠짐을 빨리 찾습니다. |
| data:image/png;base64, 로 시작하는 값이 텍스트 탭에서 처리되지 않습니다. | 앞의 데이터 URI 머리말은 Base64 본문이 아닙니다. | 쉼표까지를 지우고 넣거나, 머리말을 자동으로 분리하는 'Base64 → 파일' 탭을 씁니다. |
| 큰 파일을 넣으니 화면이 잠시 멈춥니다. | 변환이 브라우저 안에서 이뤄지므로 파일 크기만큼 메모리를 씁니다. | 먼저 압축해 용량을 줄인 뒤 인코딩하거나, 다른 탭을 정리하고 다시 시도합니다. |
| 파일 인코딩 결과를 복사했는데 일부만 붙여넣어집니다. | 붙여넣는 편집기나 입력란이 길이 제한을 두고 있습니다. | 'TXT 저장'으로 결과를 파일로 내려받아 옮기거나, 길이 제한이 없는 편집기에 붙여넣습니다. |
| 만든 문자열을 HTML에 넣었더니 이미지가 안 보입니다. | data URI 머리말이 없거나 실제 형식과 다르게 적혔습니다. | 파일의 실제 형식에 맞춰 data:image/png;base64, 처럼 머리말을 붙입니다. |
| 복원한 파일이 손상되었다고 나옵니다. | 문자열이 중간에 잘렸습니다. 공백과 줄바꿈은 자동으로 지워지므로 원인이 아닙니다. | 원본에서 문자열 전체를 다시 복사해 복원합니다. |
| 확장자를 png로 바꿨는데 그림판이 못 엽니다. | 실제 내용은 JPEG나 다른 형식이었습니다. | data: 머리말이 있으면 그 형식을 따르고, 없으면 확장자를 바꿔가며 확인합니다. |
| 파일 다운로드가 시작되지 않습니다. | 브라우저가 자동 다운로드를 막아 두었습니다. | 주소창의 차단 안내를 허용으로 바꾸거나 다른 브라우저에서 시도합니다. |
텍스트와 파일이 처리되는 위치
텍스트 변환은 브라우저의 Web API로, 파일 읽기는 File API로 현재 브라우저 메모리에서 수행됩니다. 입력한 원문, 선택한 파일, 생성된 Base64와 복원한 파일은 변환을 위해 Omneura 서버로 업로드되지 않으며, 페이지를 닫으면 입력값도 함께 사라집니다.
네 가지 변환을 확인한 방법
한글·영문·숫자·줄바꿈이 섞인 텍스트를 UTF-8로 인코딩한 뒤 다시 디코딩해 원문이 복원되는지 확인합니다. PNG와 텍스트 파일은 Base64로 바꾼 뒤 다시 파일로 복원해 바이트 크기와 열림 여부를 비교하고, data URI와 형식을 알 수 없는 데이터를 넣었을 때 제안되는 확장자가 맞는지 확인합니다.
Base64 변환에서 자주 묻는 질문
Base64는 암호화인가요?
아닙니다. 정해진 규칙으로 바이트를 글자로 옮긴 표현 방식이라 누구나 디코딩할 수 있습니다. 보안 수단으로 사용하면 안 됩니다.
한글도 변환할 수 있나요?
가능합니다. 입력한 텍스트를 UTF-8 바이트로 처리합니다. 다만 UTF-8 외의 문자 인코딩은 지원하지 않으므로, 상대가 EUC-KR로 만든 Base64는 이 도구에서 한글이 깨져 보입니다.
결과 끝의 = 문자는 무엇인가요?
데이터 길이를 Base64의 4글자 단위에 맞추기 위한 패딩 문자입니다. 원본 바이트 수에 따라 0개에서 2개까지 붙으며 정상적인 결과입니다.
왜 결과가 원본보다 큰가요?
Base64는 3바이트를 4글자로 표현하므로 구조상 약 33% 커집니다. 용량이 문제라면 문자열로 바꿀 대상인지부터 다시 판단하는 편이 낫습니다.
공백이나 줄바꿈이 섞여 있어도 되나요?
'Base64 → 텍스트' 탭은 '공백/줄바꿈 무시'가 기본으로 켜져 있어 정리한 뒤 처리합니다. 'Base64 → 파일' 탭은 별도 설정 없이 Base64에 쓰이지 않는 문자를 자동으로 지운 뒤 복원합니다.
data: 로 시작하는 값도 넣을 수 있나요?
'Base64 → 파일' 탭은 data: 머리말과 MIME 정보를 자동으로 분리합니다. 'Base64 → 텍스트' 탭에는 쉼표 뒤의 Base64 본문만 넣어야 합니다.
확장자가 bin으로 나오는 이유는 무엇인가요?
문자열에 data URI의 MIME 정보가 없고, 파일 앞부분의 시그니처도 PNG·JPEG·GIF·WebP·BMP 중 어느 것과도 일치하지 않기 때문입니다. 내려받는 파일 이름은 decoded-file.bin으로 고정되므로, 원래 형식을 알고 있다면 내려받은 뒤 확장자를 그 형식으로 바꿔 여세요.
5MB보다 큰 파일도 인코딩할 수 있나요?
'파일 → Base64' 탭은 브라우저 메모리를 안정적으로 쓰기 위해 파일당 5MB 이하로 제한합니다. 그보다 큰 파일은 Base64로 옮기기보다 파일 그대로 전달하는 방법을 먼저 검토하세요.
같은 텍스트인데 매번 같은 결과가 나오나요?
같습니다. Base64는 규칙이 정해진 변환이라 무작위 요소가 없습니다. 결과가 달라졌다면 원문이나 앞뒤 공백 처리 중 하나가 바뀐 것입니다.
Base64 결과를 URL에 그대로 넣어도 되나요?
권장하지 않습니다. 표준 Base64는 + 와 / 를 쓰는데 둘 다 URL에서 다른 뜻을 가집니다. 주소에 실어야 한다면 받는 쪽이 URL 안전 변형을 지원하는지 확인하고, 아니면 퍼센트 인코딩을 한 번 더 거쳐야 합니다.
디코딩하면 원본이 100% 복원되나요?
문자열이 온전하다면 복원됩니다. Base64는 손실이 없는 표현 변환입니다. 결과가 원본과 다르다면 전달 과정에서 문자열이 손상된 것이지 변환이 값을 바꾼 것이 아닙니다.
받은 문자열이 Base64인지 어떻게 아나요?
A-Z, a-z, 0-9와 +, / 만 있고 길이가 4의 배수이며 끝에 = 가 0~2개 붙어 있으면 Base64일 가능성이 높습니다. 다만 형식이 맞아도 내용이 텍스트라는 보장은 없어서, 디코딩해 봐야 파일인지 글인지 알 수 있습니다.
문자열이 어떤 파일 형식인지 모를 때 확인할 방법이 있나요?
문자열 앞부분이 단서가 됩니다. iVBORw로 시작하면 PNG, /9j 로 시작하면 JPEG, JVBERi 로 시작하면 PDF인 경우가 많습니다. 확실하지 않으면 일단 저장한 뒤 확장자를 바꿔가며 열어 봅니다.
입력한 텍스트나 파일이 서버로 올라가거나 사이트에 남나요?
올라가지 않고 남지도 않습니다. 변환과 저장은 브라우저 안에서 끝나고, 복원한 파일은 사용자의 기기로 바로 내려갑니다. 네트워크 탭을 열어 두고 파일을 넣어 보면 업로드 요청이 없다는 것을 직접 확인할 수 있습니다.
어느 정도 크기의 파일까지 Base64로 쓰는 것이 실용적인가요?
수십 KB 이하의 작은 아이콘이나 로고 정도가 적당합니다. 그보다 크면 문자열이 코드 가독성을 해치고, 문서를 여는 쪽에서 캐시 이점도 사라집니다. 판단 기준은 파일 크기 자체보다 그 파일을 몇 곳에서 재사용하는지입니다.