Base64 디코딩은 Base64 인코딩의 역과정입니다: Base64로 인코딩된 ASCII 문자열을 원래의 이진 데이터나 텍스트로 변환합니다. 4개의 Base64 문자마다 원본 데이터의 3바이트로 디코딩됩니다. 디코더는 Base64 알파벳에서 각 문자를 찾고, 원래의 6비트 그룹을 재구성하여 8비트 바이트로 재조립합니다.
Base64로 인코딩된 데이터는 대소문자 알파벳, 숫자, +/(표준) 또는 -_(URL 안전) 문자를 사용하며, 끝에 한 개 또는 두 개의 패딩 문자 =가 붙는 것이 특징입니다. JWT 토큰, 이메일 첨부 파일, data URI, API 응답, 설정 파일 등 — 이진 또는 구조화된 데이터를 텍스트 전용 컨텍스트에 포함해야 하는 모든 곳에서 자주 등장합니다.
Curl, Postman, 브라우저 DevTools, 온라인 변환기 모두 Base64를 디코딩할 수 있습니다. 편의성은 다양하며, 일부는 데이터를 원격 서버로 전송합니다.
자주 묻는 질문
디코딩하면 왜 깨진 문자가 나오나요?
가장 일반적인 원인은 이진 데이터(이미지, 압축 파일)를 UTF-8 텍스트로 디코딩하는 것입니다 — 이진 바이트는 유효한 유니코드 시퀀스를 형성하지 않는 경우가 많습니다. 또 다른 원인은 +/를 기대하는 표준 디코더로 URL-safe Base64(-_)를 디코딩하는 것입니다. 소스가 어떤 변형을 사용하는지 확인하세요.
InvalidCharacterError란 무엇인가요?
atob()의 이 브라우저 오류는 입력에 URL-safe 문자(-또는_), 공백, 줄 바꿈, 비ASCII 문자 등 Base64 알파벳 외의 문자가 포함될 때 발생합니다. atob()를 호출하기 전에 공백을 제거하고 URL-safe 문자를 변환하세요.
내 Base64가 URL-safe인지 표준인지 어떻게 알 수 있나요?
- 또는 _ 문자를 찾으세요: 있으면 URL-safe Base64입니다. 표준 Base64는 +와 /를 사용합니다. URL-safe Base64는 일반적으로 패딩 문자 =도 생략합니다. JWT 토큰은 항상 URL-safe Base64를 사용합니다.
Base64 디코딩이 조용히 실패할 수 있나요?
네. 일부 디코더는 오류를 발생시키는 대신 잘못된 문자를 조용히 무시하여 잘못된 출력을 생성합니다. 디코더가 성공했다고 가정하지 말고 디코딩된 데이터가 예상 형식(JSON, 이미지 헤더 등)과 일치하는지 항상 확인하세요.
Base64 디코딩에 크기 제한이 있나요?
이 브라우저 기반 도구는 UI가 느려지기 전까지 수 메가바이트 크기의 Base64 문자열을 처리할 수 있습니다. 매우 큰 파일의 경우 CLI 도구나 서버 측 디코더를 사용하세요.
Base64가 한 개 또는 두 개의 = 기호로 끝나는 이유는?
=는 패딩 문자입니다. Base64는 3바이트를 4문자로 인코딩합니다. 원본 데이터 길이가 3의 배수가 아니면 총 출력 길이가 4의 배수가 되도록 한 개 또는 두 개의 = 문자가 추가됩니다. = 하나는 마지막 그룹에 2개의 입력 바이트가 있음을 의미하고, == 두 개는 1개의 입력 바이트를 의미합니다.
바이너리 파일, 이미지, PDF도 디코딩할 수 있나요?
네, 하지만 출력은 텍스트로 올바르게 표시되지 않을 수 있는 원시 이진 데이터입니다. 이진 콘텐츠의 경우 data URI를 '<'img'>' 또는 '<'a'>' 태그에서 직접 사용하거나, 스크립트를 사용하여 디코딩된 바이트를 파일로 저장하는 것이 좋습니다.
디코딩 크기 제한이 있나요?
이 도구는 서버 측 제한 없이 완전히 브라우저에서 실행됩니다. 실제 제한은 브라우저의 메모리에 따라 다릅니다. 매우 큰 Base64 문자열(수 MB 이상)은 base64 -d(Linux/macOS) 또는 certutil -decode(Windows)와 같은 CLI 도구로 처리하는 것이 좋습니다.