01
문자 집합과 패딩은 별개입니다
표준은 +와 /, URL-safe Base64는 -와 _를 씁니다. 끝의 = 포함 여부는 따로 설정합니다. 디코딩은 자동 감지를 하지 않으므로 입력이 사용한 문자 집합을 직접 선택하세요.
인코딩과 이스케이프
Base64 인코딩및 엄격한 UTF-8 디코딩
하나의 텍스트에 적용할 방향, 문자 집합, 패딩 규칙을 선택하세요.
Base64 인코딩 작업 도구
입력
결과
현재 브라우저에서만 변환하며 입력을 업로드하지 않습니다.
인코딩 옵션
UTF-8만 처리합니다. 디코딩은 완전한 패딩 또는 패딩 전체 생략을 허용하며, 0이 아닌 미사용 비트는 거부합니다. 선택한 문자 집합과 UTF-8 바이트를 엄격히 검사합니다.
입력은 UTF-16 코드 단위 1,000,000개, 출력은 4,000,000개까지입니다. 빈 입력도 유효합니다. 붙여넣을 때 줄바꿈 형식이 바뀔 수 있습니다.
텍스트를 입력하거나 예제를 불러오세요. 빈 입력은 빈 결과가 됩니다.
확인 후 최신 결과를 입력으로 옮기고 방향을 바꿉니다. 결과가 입력 한도를 넘으면 사용할 수 없습니다.
설정값이나 API 데이터에 한글이 들어 있다면 글자 수와 바이트 수를 구분해야 합니다. Base64 인코딩은 텍스트를 먼저 UTF-8 바이트로 바꾸고, 그 바이트를 ASCII 문자로 표현합니다. 한글과 이모지도 같은 과정으로 처리합니다.
외부에서 받은 문자열은 읽을 만한 결과가 나온다고 해서 올바른 값은 아닙니다. 이 Base64 변환기는 문자 집합과 끝부분 구조를 먼저 검사하고 UTF-8 바이트까지 확인합니다. 손상된 입력을 대체 문자로 채워 성공한 것처럼 보여 주지 않습니다.
Base64 인코딩을 확인하며 사용하는 이유
한글도 바이트를 거쳐 정확히 변환
한글 한 글자를 한 바이트로 가정하면 결과를 잘못 해석할 수 있습니다. Base64 인코딩은 UTF-8을 거치므로 여러 바이트를 쓰는 문자도 처리합니다. 결과를 역변환해 설정에 넣기 전에 원문과 비교할 수 있습니다.
형식 오류와 텍스트 오류를 구분
문자 집합이 맞아도 그 안의 바이트가 UTF-8은 아닐 수 있습니다. 패딩과 문자를 검사한 뒤 텍스트 해석 단계에서 별도로 오류를 냅니다. 입력이 잘렸는지, 원래 바이너리 데이터인지를 구분할 단서가 됩니다.
받는 시스템의 규칙부터 확인하세요
02
변경 후 결과가 갱신되는 시점을 확인하세요
자동 변환은 마지막 수정 후 350밀리초가 지나면 실행됩니다. 끄면 변환 버튼이 나타나고 Ctrl/Cmd+Enter도 사용할 수 있습니다. 입력이나 옵션이 바뀌면 이전 결과를 즉시 내보낼 수 없게 됩니다.
03
입력 교체는 미리보기 후 적용하세요
예제, 비우기, 역변환은 교체 내용과 코드 단위 수를 먼저 보여 줍니다. 적용 후에는 입력·옵션·결과를 한 번 되돌릴 수 있습니다. 긴 결과는 앞의 20,000단위만 표시하지만 복사와 저장은 전체를 사용합니다.
텍스트 변환에 필요한 확인 항목
문자 조합을 바꾸지 않는 UTF-8 처리
결합 문자를 임의로 합치거나 Unicode 정규화를 하지 않습니다. 한글, 악센트, 이모지를 바이트로 변환하며 처음의 U+FEFF도 유지합니다. 인코딩 시 새 BOM을 추가하지 않습니다.
두 문자 집합을 엄격하게 분리
표준 디코더는 -와 _를, URL 안전 디코더는 +와 /를 거부합니다. 두 형식을 섞거나 자동으로 고치지 않습니다. 인코딩의 패딩은 양쪽에서 독립적으로 선택할 수 있습니다.
근거가 있는 위치만 표시
잘못된 문자, 패딩, 짝이 없는 서로게이트는 원본 입력의 행과 UTF-16 열을 알려 줍니다. 디코딩된 UTF-8 바이트 오류에는 확인할 수 없는 입력 위치를 붙이지 않습니다.
허용할 공백을 직접 선택
Base64 디코딩에서 일반 공백, 탭, CR, LF만 무시할 수 있고 제거한 개수도 표시합니다. 옵션을 끄면 이 문자도 오류로 처리하므로 줄바꿈 없는 값이 필요한 시스템을 점검할 수 있습니다.
입력 범위와 거부 기준
- 텍스트 전용이며 파일을 가져오지 않음
- 파일·이미지 업로드, URL 읽기, Data URI 및 PEM 해석은 제공하지 않습니다. 바이너리 파일 복원이나 문자 인코딩 자동 감지도 없습니다. 머리말과 기호를 알아서 제거하지 않습니다.
- 패딩은 완전하게 넣거나 전부 생략
- Zg==와 Zg는 모두 f가 됩니다. Zg=처럼 일부만 넣은 패딩, 중간의 =, 과도한 =, 데이터 길이를 4로 나눈 나머지가 1인 값은 거부합니다. 패딩 체크박스는 인코딩에만 영향을 줍니다.
- 끝의 미사용 비트는 0이어야 함
- 느슨한 디코더는 Zh==를 f로 돌려줄 수 있지만 여기서는 거부합니다. 이는 이 도구가 선택한 정규형 검사 정책입니다. RFC 4648이 모든 디코더에 동일한 거부 동작을 의무화한 것은 아닙니다.
- 잘못된 바이트를 복구하지 않음
- /w==는 Base64 구조는 맞지만 유효한 UTF-8이 아니므로 실패합니다. 인코딩도 짝 없는 UTF-16 서로게이트를 거부합니다. 디코딩한 내용의 맨 앞 BOM은 여러 개 있어도 유지합니다.
- 무시하는 공백은 네 종류뿐
- SP, TAB, CR, LF만 대상입니다. NBSP, 폼 피드, 수직 탭, 인코딩 문자열에 붙은 BOM은 거부합니다. 일반 텍스트를 인코딩할 때는 공백과 줄바꿈도 내용입니다. 엔진은 CRLF를 유지하지만 붙여넣기 과정에서는 줄바꿈이 달라질 수 있습니다.
- 한도 초과 시 일부만 내보내지 않음
- 입력은 공백 제거 전 UTF-16 코드 단위 1,000,000개, 출력은 4,000,000개가 한도입니다. 빈 문자열은 유효합니다. MIME 줄바꿈, 줄별 배치, 암호화, JWT 검증 및 초안 저장은 지원하지 않습니다.
Base64 인코딩 자주 묻는 질문
Unicode와 이모지도 올바르게 처리하나요?
유효한 Unicode 텍스트를 UTF-8로 바꿔 처리합니다. 따라서 Base64 인코딩은 한글과 이모지도 지원합니다. 짝이 없는 UTF-16 서로게이트는 손상된 텍스트로 보고 오류를 내며, 임의의 대체 문자로 바꾸지 않습니다.
URL-safe Base64는 무엇인가요?
표준의 +와 / 대신 -와 _를 사용하는 변형으로 Base64URL이라고도 합니다. 패딩 생략 여부는 받는 시스템의 규칙을 따라야 합니다. 여기서는 문자 집합을 바꿔도 = 포함 설정을 자동으로 바꾸지 않습니다.
패딩이 있는 경우와 없는 경우는 어떻게 다른가요?
바이트 수가 3의 배수가 아니면 마지막 묶음을 채우기 위해 =가 필요합니다. 일부 규약은 이를 생략합니다. 이 도구는 완전한 패딩 또는 전체 생략을 디코딩하며, 일부만 남긴 값은 오류로 처리합니다.
PDF나 이미지 파일도 인코딩할 수 있나요?
이 페이지는 텍스트만 받습니다. PDF나 이미지를 업로드하거나 바이너리로 복원할 수는 없습니다. 파일의 Base64 문자열이 문법상 맞더라도 내용이 UTF-8이 아니면 실패하므로 파일 전용 도구를 사용하세요.
공백이나 줄바꿈 때문에 디코딩이 실패할 수 있나요?
일반 공백·탭·CR·LF는 무시 옵션을 켜면 허용합니다. 다른 공백은 계속 거부합니다. 그래도 실패하면 선택한 문자 집합과 끝의 패딩을 확인하세요. 값을 잘못 잘랐거나 UTF-8이 아닌 바이트라면 공백을 지워도 해결되지 않습니다.
설명에 없는 변환 문제가 있나요?