Base64를 붙여 넣었는데 변환되지 않는다면 먼저 오류가 문자열 형식에 관한 것인지, 디코딩한 바이트를 텍스트로 읽는 문제인지 구분하세요. Decodex는 UTF-8 텍스트용 도구이므로 유효한 Base64라도 이미지나 다른 문자 인코딩은 읽을 수 없습니다.
1. 문자와 끝부분의 패딩 확인
입력 앞뒤의 따옴표나 쉼표는 값 자체에 포함된 문자인지 확인하고, 포장된 값이라면 Base64 부분만 복사하세요. 문자열 중간에 =가 있거나 내용이 잘렸다면 원본을 다시 가져오는 편이 안전합니다. Base64 표준에서 패딩은 끝부분에 붙습니다.
| 입력 | 결과 또는 해결 방법 |
|---|---|
SGVsbG8= | Hello로 변환됩니다. |
SGVsbG8 | 끝의 패딩 생략은 이 도구에서 자동 처리합니다. |
Zg= | 패딩이 불완전합니다. 원본이 f라면 올바른 값은 Zg==입니다. |
A | 이 길이로는 완전한 데이터를 표현할 수 없습니다. 원본 누락 여부를 확인하세요. |
Decodex는 공백과 줄바꿈을 무시하고 Base64URL의 -, _도 처리합니다. 다른 도구나 API의 허용 규칙은 다를 수 있습니다. 패딩을 추가해도 잘린 본문은 복구되지 않습니다.
2. URL·JSON·data URL에서 가져온 값
"SGVsbG8="처럼 JSON 값 전체를 복사했다면 따옴표를 제외한 내용을 사용하세요. data:text/plain;base64,SGVsbG8=라면 쉼표 뒤의 SGVsbG8=만 넣습니다. 이미지 data URL의 본문은 텍스트 변환 대상이 아닙니다.
%3D 같은 퍼센트 이스케이프가 있으면 Base64를 적용하기 전에 URL 디코딩이 필요한 값일 수 있습니다. 일부 전송 과정에서는 +가 공백으로 바뀌기도 합니다. 이 경우 원본과 비교하세요. 공백을 무조건 +로 바꾸면 실제 줄바꿈이나 공백까지 훼손할 수 있습니다.
점으로 나뉜 토큰 전체도 하나의 Base64 문자열이 아닙니다. 어떤 필드를 디코딩하려는지 먼저 확인하세요.
3. “바이너리 데이터이거나 올바른 UTF-8 텍스트가 아닙니다”
이 메시지는 Base64를 바이트로 읽은 뒤 UTF-8 텍스트로 해석하지 못했다는 뜻입니다. 예를 들어 /w==는 유효한 Base64지만 결과 바이트는 유효한 UTF-8 텍스트가 아닙니다.
- 원본이 이미지·PDF·압축 파일이면 해당 파일 형식을 다루는 도구가 필요합니다.
- 원본이 EUC-KR 또는 CP949 텍스트이면 원래 문자 인코딩에 맞는 디코더가 필요합니다. Decodex는 UTF-8을 사용합니다.
- 원본이 UTF-8이었다면 복사나 전송 과정에서 문자열이 손상되었는지 확인하세요.
한글 변환 원리는 한글·이모지 Base64 변환 안내에서 더 자세히 설명합니다.
4. 정상 예시부터 확인하기
- 디코더에
SGVsbG8=를 넣어Hello가 나오는지 확인합니다. - 정상 예시는 되는데 자신의 값만 실패하면 원본 형식과 문자 인코딩을 확인합니다.
- 입력 중 잠깐 오류가 뜬다면 전체 값을 붙여 넣거나 자동 변환을 끄고 수동 버튼을 누릅니다.
- 크기 제한 메시지가 나오면 더 작은 텍스트로 확인합니다. 이 도구의 변환 한도는 5 MiB(5 × 1024 × 1024바이트)입니다.
문제가 계속되면 문의 페이지에 브라우저와 오류 메시지를 알려주세요. 비밀번호나 토큰 대신 공개해도 되는 짧은 예시를 사용하세요.