고급 옵션
줄바꿈 구분자
다양한 운영체제는 서로 다른 줄 바꿈 문자를 사용합니다. 예를 들어, Unix와 Windows는 동일한 줄 바꿈 기호를 사용하지 않습니다. 디코드 후, 출력의 모든 줄 바꿈 문자는 선택한 옵션으로 대체됩니다. 이 설정은 '각 줄을 개별적으로 디코드하기' 기능의 동작을 결정합니다.
각 줄을 개별적으로 디코드하기
이 옵션을 활성화하면 입력의 각 줄을 별도의 Base64 문자열로 처리하여 독립적으로 디코드합니다. 이는 줄 바꿈으로 구분된 여러 개의 개별 Base64 항목을 디코드해야 할 때 특히 유용합니다.
줄 바꿈 제거
MIME 형식의 Base64 데이터(예: 이메일에서)는 종종 76자마다 줄 바꿈이 포함됩니다. 디코드 전에 이러한 줄 바꿈을 제거하려면 이 옵션을 활성화하세요. 이를 통해 MIME 형식의 Base64 데이터가 올바르게 디코드됩니다.
URL 안전 인코딩 처리
입력이 URL 안전 Base64 변형(RFC 4648 / Base64URL)을 사용하는 경우 이 옵션을 활성화하세요. 이 경우, "-"는 "+", "_"는 "/"를 의미하며, 패딩은 생략될 수 있습니다. 이 옵션은 디코드 전에 입력을 표준 Base64로 변환합니다.
실시간 모드
실시간 모드가 켜지면 브라우저의 내장 JavaScript 기능을 사용하여 입력이 즉시 디코드되며, 데이터는 서버로 전송되지 않습니다. 현재 이 모드는 UTF-8 텍스트 출력만 지원합니다.
참고: 이미지, 문서 등의 바이너리 파일의 경우 데이터 손상을 방지하기 위해 결과를 복사하지 말고 저장하세요.
Base64 디코딩이란 무엇인가요?
Base64 디코딩은 Base64의 이진-텍스트 인코딩 방식을 역으로 수행하여 ASCII 문자열을 그것을 처음 만들어 낸 정확한 바이트 시퀀스로 되돌립니다. Base64는 고정된 64자 알파벳을 사용합니다 — 대문자 A–Z, 소문자 a–z, 숫자 0–9, 그리고 두 기호 +와 /, 거기에 마지막 패딩 문자인 =이 더해집니다. 이 형식은 RFC 4648 §4에 의해 정의되며, +와 / 대신 -와 _를 사용하는 URL 안전 변형인 Base64URL도 함께 기술합니다. 인코딩은 입력 바이트 3개(24비트)마다 Base64 문자 4개(4 × 6비트)에 매핑하므로 인코딩된 출력은 원본보다 항상 약 33 % 더 깁니다. 디코딩은 이 비율을 뒤집습니다: JWT 페이로드, MIME으로 인코딩된 이메일 첨부 파일, 인라인 data: URI 모두 같은 정확한 역연산을 통해 원래 바이트로 돌아갑니다.
Base64 디코딩은 어떻게 작동하나요?
Base64 디코딩은 인코딩 파이프라인을 기계적으로 뒤집습니다. 디코더는 한 번에 Base64 문자 네 개를 읽어, 각각을 64자 알파벳에서 찾아 6비트 값을 복원하고, 네 개의 6비트 값을 하나의 24비트 버퍼로 연결한 다음, 그 버퍼를 다시 세 개의 8비트 바이트로 나눕니다. 끝의 = 패딩은 마지막 그룹이 두 바이트(= 한 개)나 한 바이트(= 두 개)로만 디코딩됨을 나타냅니다. 표준 예시는 Base64 문자열 TWFu이며, 세 글자 ASCII 단어 Man으로 디코딩됩니다. 알고리즘을 따르면: T는 알파벳 색인 19 → 010011; W는 색인 22 → 010110; F는 색인 5 → 000101; u는 색인 46 → 101110. 이 비트들을 연결하면 010011 010110 000101 101110이 되고, 이를 다시 묶으면 바이트 시퀀스 01001101 01100001 01101110이 됩니다 — 즉 M, a, n의 ASCII 코드입니다.
- 입력 문자열을 64자 알파벳과 패딩 규칙에 따라 검증하고, 전송 과정에서 남아 있는 떠도는 공백이나 알파벳 외 문자를 거부합니다.
- 조회 테이블(또는
A–Z a–z 0–9 + /내 위치)을 사용해 각 Base64 문자를 6비트 값으로 변환합니다. - 6비트 값을 네 개씩 묶어 24비트 버퍼로 연결합니다.
- 각 24비트 버퍼를 다시 세 개의 8비트 바이트로 나누면, 그것이 원래의 이진 또는 ASCII 데이터가 됩니다.
- 끝의
=패딩을 존중하여 마지막 그룹에서 필요에 따라 한 개 또는 두 개의 바이트를 버립니다.
Base64 디코더를 사용하는 이유는 무엇인가요?
- 데이터 복구: 추가 처리 전에 텍스트 안전 Base64 페이로드에서 원래의 이진 바이트를 다시 가져옵니다. 예를 들어, PDF 영수증을 Base64로 저장한 데이터베이스 열을 디코딩하여 해당 바이트를 디스크에 다시 쓰고 다시 열 수 있도록 합니다.
- 이메일 첨부파일: 이진 부분을 Base64 줄로 감싸는 MIME 인코딩된 메시지 본문에서 파일과 이미지를 추출합니다. 첨부파일이 다운로드되지 않을 때 저장된
.eml파일 안의Content-Transfer-Encoding: base64블록에서 PNG를 꺼내는 것이 전형적인 사례입니다. - 웹 리소스: 포함된
data:URI를 원래 바이트로 변환하여 페이지가 실제로 무엇을 전달했는지 점검할 수 있습니다. 예를 들어, CSS 규칙에서data:image/svg+xml;base64,…URL을 붙여넣고 SVG 마크업을 복원하여 감사할 수 있습니다. - API 통합: 이진 필드가 원시 바이트로 전송될 수 없을 때 REST 및 GraphQL 서비스가 반환하는 Base64 페이로드를 처리합니다. 흔한 사례는 JWT 서명, OAuth 갱신 토큰 또는 S3의
Content-MD5헤더를 디코딩하여 요청을 끝에서 끝까지 검증하는 것입니다.
Base64 디코딩의 일반적인 활용 사례는 무엇인가요?
Base64 디코드는 다음과 같은 다양한 상황에서 필수적입니다:
- 이메일 처리: 전체 메일 클라이언트를 실행하지 않고도 MIME 인코딩된 메시지에서 첨부파일을 추출합니다. 엔지니어는 지원 큐에 들어온 잘못된 형식의 메시지를 분류할 때, 또는 원본 클라이언트가 더 이상 설치되어 있지 않은 상태에서 보관된
.mbox내보내기에서 파일을 복구할 때 이 작업을 수행합니다. - 웹 개발: 인라인 Base64
data:URI를 원래 바이트로 변환하여 해당 자산을 감사하거나 해시된 파일로 교체할 수 있습니다. 아이콘을data:image/svg+xml;base64,…형식으로 임베드한 스타일시트를 리팩터링할 때 흔히 수행하는 작업입니다. - API 디버깅: JSON 또는 XML 응답 내부의 Base64 필드를 디코딩하여 기저 값을 로그에서 사람이 읽을 수 있도록 만듭니다. 전형적인 예로는 JWT의
payload, MD5를 감싸는 S3의ETag, 또는 외부 제공자에서 되돌려준 웹훅 서명 헤더가 있습니다.
Base64 디코딩 예시는 어떻게 생겼나요?
Base64 문자열 TWFu를 디코드하면 단어 Man이 됩니다. 디코드 과정은 각 Base64 문자를 해당 6비트 값으로 변환하고, 이 비트들을 결합하여 원래의 ASCII 문자를 재구성합니다.
이 Base64 디코더는 무료이며 비공개인가요?
예 — 이 Base64 디코더는 완전히 무료이며, 계정이나 가입이 필요 없고 전적으로 브라우저 내부에서 실행됩니다. Base64 문자열을 붙여넣거나 파일을 떨어뜨리면, 디코딩은 표준 JavaScript API(atob는 텍스트용, FileReader와 타입드 배열 변환은 이진 콘텐츠용)를 통해 로컬에서 이루어집니다. 입력은 결코 기기 밖으로 나가지 않으며, 어떤 서버 로그에도 사본이 기록되지 않고, 디코딩한 내용에 텔레메트리가 부착되지 않으며, 속도 제한·문자 수 상한·저장된 기록도 없습니다. 페이지가 한 번 로드되면 도구를 오프라인에서도 사용할 수 있는데, 첫 방문 시 실행된 동일한 코드가 브라우저에 캐시되기 때문입니다. 폼 필드를 읽을 수 있는 서드파티 분석 스크립트도 사용하지 않습니다. 그 결과 이 도구는 JWT 베어러 토큰, data: URI에 임베드된 자격 증명, 구성 비밀, Base64로 감싼 인증서나 비공개 키 자료처럼 어디에도 업로드해서는 안 되는 민감한 페이로드를 다루기에 안전합니다.
저희 온라인 Base64 디코더 도구는 여러분의 Base64 데이터를 빠르고 안전하게 디코드하는 방법을 제공합니다. 웹페이지에서 포함된 이미지를 추출하거나 API 응답을 처리하는 등, Base64 디코드는 현대 웹 개발에 필수적인 도구입니다.