파일 업로드
  1. base64hub
  2. 텍스트 도구
  3. Base64 검사기

Base64 검사기

문자열을 붙여넣으면 올바른 Base64인지, 아니라면 정확히 어디서 왜 틀렸는지 보여 줍니다. 잘못된 문자, 그 행과 열, 필요한 패딩까지 나옵니다. 점수로 그것이 Base64이긴 한지도 추정합니다.

무료 가입 없음, 제한 없음 로컬 업로드 없음 위치 문제마다 행, 열, 오프셋 표시 업데이트 2026. 10. 27.

브라우저에서 처리됩니다. 이 페이지는 데이터를 어디로도 보낼 수 없습니다 – 확인 방법

Base64 문자열을 검사하는 방법

  1. 검사할 Base64에 문자열을 붙여넣으세요. 줄 바꿈, PEM 경계 줄, data: 접두사는 그대로 두어도 됩니다. 발견 사항으로 보고되고 나머지는 계속 분석됩니다.
  2. 맨 위의 판정을 읽으세요. 문제마다 위치가 표시됩니다. 예: “3행 17열(169번째 문자)”.
  3. 입력 내용과 문제 위치 표시에서 문제가 되는 문자가 제자리에 표시된 것을 확인하세요.
  4. 어떤 Base64 변형에 맞을까요? 에서 표준, 패딩 없음, URL-safe, MIME, PEM Base64 중 어디에 맞는지, 맞지 않는 곳은 왜 그런지 확인하세요.
  5. 고치기를 누르면 문자열을 정리하는 복구 모드로 전환됩니다.

검사기가 확인하는 것

  • 알파벳 밖의 문자: 유니코드 코드 포인트와 함께 표시하므로, 줄 바꿈 없는 공백(U+00A0)이나 폭 없는 공백(U+200B) 같은 보이지 않는 문자도 드러납니다.
  • 섞인 알파벳: 한 문자열에 표준 Base64의 +, /와 Base64URL의 -, _가 함께 있는 경우.
  • 중간의 =: 거의 항상 인코딩된 값 두 개가 붙어 있다는 뜻입니다.
  • 불가능한 길이: 패딩을 뺀 길이를 4로 나눈 나머지가 1이면 어떤 인코더에서도 나올 수 없습니다. 문자가 하나 빠졌거나 남습니다.
  • 패딩: 누락, 과다, 또는 데이터 길이와 맞지 않는 경우.
  • 마지막 문자의 비정규 끝 비트 (RFC 4648 §3.5).
  • 공백과 줄 바꿈: 공백과 탭, 줄 너비, 줄 끝이 CRLF인지 LF인지 섞였는지.

세부 정보에는 길이, 길이 mod 4, 패딩 상태, 알파벳, 디코딩 크기, 감지된 내용 유형이 추가로 나옵니다. 문제 위치를 표시한 입력 사본은 처음 20,000자까지만 보여 주지만, 분석은 항상 문자열 전체를 대상으로 합니다.

같은 문자열, 다른 디코더

“올바르다"는 누가 묻느냐에 따라 달라집니다. 다음 문자열 다섯 개를 흔히 쓰는 디코더 네 개(Python 3.13, Node.js 24, WHATWG atob, GNU coreutils 9.7)로 처리했습니다.

입력문제Python b64decode(s, validate=True)Node Buffer.from(s, "base64")atob(s)base64 -d
SGVsbG8gd29ybGQ= 누락오류Hello worldHello worldHello world
SGVsbG9=비정규 마지막 문자HelloHelloHello오류
SGVsbG8=V29ybGQ=값 두 개가 붙음오류Hello (나머지는 버려짐)오류HelloWorld
SGVsbG8gd나머지 1오류Hello오류오류
SGVs bG8=공백오류HelloHello오류

위험한 칸은 붙어 버린 입력에 대해 Node가 조용히 Hello를 돌려주며 오류 없이 데이터의 절반을 잃는 곳입니다. 그래서 이 도구는 내 디코더가 허용하는 것까지 포함해 모든 편차를 보고합니다. 그다음 변형 표가 문자열이 어떤 엄격한 형식을 만족하는지 알려 줍니다.

올바른 문자열이면 정말 Base64일까요?

abcd, test, 1234는 모두 올바른 Base64입니다. 각각 무작위처럼 보이는 3바이트로 디코딩됩니다. 그래서 도구는 정말 Base64일까요? 에도 0~100점의 점수와 그 근거로 답하며, 각 근거가 Base64 쪽인지 반대쪽인지 표시합니다.

  • 지지하는 근거: 올바른 패딩, 대문자·소문자·숫자가 섞임, 높은 문자 다양성, eyJ로 시작({"의 Base64로 JSON과 JWT에 전형적), 알려진 파일 형식이나 읽을 수 있는 텍스트로 디코딩되는 바이트.
  • 반대하는 근거: 영문자만 있음(단어일 수 있음), 16진수 숫자만 있음(hex 문자열일 수 있음), 숫자만 있음(아마 숫자), 대소문자 한 가지만, 매우 짧은 문자열.

점수는 힌트로만 받아들이세요. 휴리스틱이므로 짧은 문자열은 어느 방향으로든 속일 수 있습니다.

코드에서 Base64 검사하기

실무에서 가장 엄격한 검사는 왕복 변환입니다. 디코딩하고, 다시 인코딩하고, 비교합니다. 공백, 누락된 패딩, 비정규 끝을 한 번에 걸러 냅니다.

import base64

def is_canonical_base64(s):
    try:
        return base64.b64encode(base64.b64decode(s, validate=True)).decode() == s
    except ValueError:
        return False

Node.js에서는 같은 아이디어가 Buffer.from(s, "base64").toString("base64") === s입니다. ^(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$ 같은 정규식은 알파벳과 길이를 검사하지만 SGVsbG9=와 빈 문자열을 통과시킵니다. URL-safe 문자열은 먼저 변환하거나 맞는 알파벳을 쓰세요. Base64와 Base64URL 비교를 참고하세요. 언어별 오류 메시지는 Base64 오류에 모아 두었습니다.

자주 묻는 질문

문자열이 Base64인지 어떻게 알 수 있나요?

엄밀히 말해 A–Z, a–z, 0–9, +, /만 쓰고, 길이가 4의 배수이며, 끝에 =가 최대 두 개만 있으면 올바른 표준 Base64입니다. 일반 단어도 이 검사를 많이 통과하므로, 도구는 문자열의 생김새와 디코딩 결과를 바탕으로 0~100점의 점수를 더해 줍니다.

Base64가 한 언어에서는 디코딩되는데 다른 언어에서는 실패하는 이유는 무엇인가요?

디코더마다 엄격한 정도가 다릅니다. Node의 Buffer.from은 거의 무엇이든 받아들이고, Python의 b64decode(s, validate=True)는 누락된 패딩을 거부하며, GNU base64 -d는 비정규 마지막 문자를 거부합니다. 위 표에 같은 문자열 다섯 개를 디코더 네 개로 처리한 결과가 있습니다.

비정규(non-canonical) Base64란 무엇인가요?

마지막 문자에는 0이어야 하는 미사용 비트가 몇 개 있습니다. SGVsbG8=와 SGVsbG9=는 둘 다 Hello로 디코딩되지만 정규 형식은 첫 번째뿐입니다. RFC 4648은 디코더가 두 번째를 거부해도 된다고 하며, 다시 인코딩해도 결코 두 번째가 나오지 않습니다.

올바른 Base64 문자열은 디코딩해도 안전한가요?

올바르다는 것은 내용에 대해 아무것도 말해 주지 않습니다. 세부 정보에서 디코딩 크기와 감지된 내용 유형을 알맞은 디코더 링크와 함께 보여 주므로, 저장하기 전에 텍스트인지 이미지인지 다른 것인지 알 수 있습니다.