🚀 빠른 시작

텍스트(일반 텍스트 또는 Base64 문자열)를 입력칸에 입력합니다
‘인코딩’ 또는 ‘디코딩’을 눌러 처리합니다
입력과 결과는 동일한 영역을 사용합니다. 한 번의 클릭으로 복사/지우기 가능합니다
검증 시: 인코딩 후 디코딩으로 전환하여 왕복 확인합니다

📌 자주 쓰는 활용 사례

URL/JWT: URL‑safe 변형(−/_ ) 권장. 필요 시 끝의 '=' 패딩 생략하여 이스케이프 문제를 피함
메일/MIME: 줄바꿈이 필요하면 MIME 76열(CRLF)을 사용; 웹에서는 보통 줄바꿈하지 않습니다. 이 도구는 76열 줄바꿈과 LF/CRLF 전환을 제공합니다
여러 줄 텍스트: 줄 단위 인코딩을 켜 각 줄을 독립적으로 인코딩
MIME/PEM: 76열 줄바꿈 활성화; 필요 시 LF 줄바꿈도 켜기
Data URL: 임베드 시 data:[mime];base64,… 생성. 디코더가 쉼표 이후를 자동 추출
왕복 검증: 인코딩 후 즉시 디코딩해 동일성 확인

🎛️ 인코딩 매개변수 및 변형

URL‑safe 출력
줄 단위 인코딩(각 줄 독립)
MIME 76열로 줄바꿈(CRLF)
줄바꿈에 LF 사용(\n)
패딩 자동 보정: 길이를 4의 배수로 맞춥니다. 잘못된 길이는 오류로 처리합니다
공백 허용: 디코딩 시 줄바꿈과 공백을 자동 제거합니다

🧭 활용 팁

문자 깨짐 방지를 위해 UTF‑8 사용을 권장합니다
기본값은 URL‑safe. 표준 Base64가 필요하면 비활성화
시스템 간 전달 시 줄바꿈/공백을 제거하고, 표시 목적일 때만 추가합니다
Base64 인코딩 후 용량이 약 33% 증가합니다. 대용량에는 적합하지 않습니다
레거시용 표준 Base64: URL‑safe 비활성화( +/ 및 = 유지 )
줄 단위 인코딩은 이미 인코딩된 Base64를 다시 인코딩합니다. 변형 변환만 필요하면 끄고 실행
76열 줄바꿈은 표시만 변경; 디코더는 줄바꿈/공백을 무시

⚠️ 제한 사항 및 호환성

매우 긴 텍스트는 성능에 영향을 줄 수 있으므로 분할을 권장합니다
바이너리: 본 UI는 텍스트 중심입니다. 바이너리는 Data URL 또는 CLI 사용을 권장합니다
브라우저 메모리에 따라 최대 처리 크기가 제한됩니다

🔒 개인정보 보호 및 보안

모든 처리는 브라우저 내에서 이루어지며, 데이터는 기기를 떠나지 않습니다
보안 안내: Base64는 인코딩이며 암호화가 아닙니다. 민감 정보는 먼저 암호화한 뒤 인코딩하세요

❓ 자주 묻는 질문

Base64란? 왜 “인코딩”이 필요한가?

Base64는 임의의 이진 데이터를 인쇄 가능한 텍스트 문자로 안전하게 표현하는 방식입니다. 1990년대 이메일 MIME 표준(RFC 1521/2045)에서 시작되어 RFC 4648로 통합되었습니다. 목적은 “암호화”가 아니라 텍스트 중심의 경로에서 바이트를 안정적으로 운반하는 것입니다. 원리: 3바이트(24비트)를 6비트×4 블록으로 나누고 A–Z, a–z, 0–9, +, / 64문자에 매핑합니다. 길이가 3의 배수가 아니면 “=”로 패딩합니다. 크기는 약 33% 증가합니다. 변형과 선택: RFC 4648은 URL‑safe 변형을 정의하며 “+”“/” 대신 “-”“_”를 사용하고 끝의 “=”는 생략할 수 있습니다. URL/Cookie/JWT에서는 URL‑safe를 권장하고, 레거시/MIME 도구 연계에는 표준 Base64(+/ 및 = 유지)를 사용합니다. 이 도구는 기본적으로 URL‑safe를 출력하며, 디코더는 두 가지 모두를 허용합니다. 예시: ??? → 표준 Pz8/, URL‑safe Pz8_; ~~~ → 표준 fn5+, URL‑safe fn5‑. Data URL: 임베딩 시 data:[mime];base64,… 형식을 사용하며, 디코딩 시 쉼표 뒤의 부분을 추출합니다(도구가 자동 처리). 이력(요약): 1993 RFC 1521(MIME v1, Ned Freed & Nathaniel Borenstein) → 1996 RFC 2045(MIME 업데이트) → 2003 RFC 3548(Simon Josefsson, Base16/32/64 추상화) → 2006 RFC 4648(Simon Josefsson, 통합 및 Base64URL 정의, 3548 폐지). 또한 1993 RFC 1421(PEM, J. Linn)은 Radix‑64를 사용. 보안: Base64는 되돌릴 수 있는 포맷 변환이며 기밀성/무결성을 제공하지 않습니다. 민감한 데이터는 먼저 암호화한 뒤 인코딩하세요.

Base64는 안전한가요?

아닙니다. 누구나 디코딩할 수 있습니다. 기밀이 필요하면 암호화 후 인코딩하세요

‘유효하지 않은 Base64 형식’ 오류가 나오는 이유는?

문자열에 A–Z, a–z, 0–9, +, /, =만 포함되고 길이가 올바른지 확인하세요

도구마다 결과가 다른 이유는?

차이는 줄바꿈 처리, '=' 패딩 유지 여부, URL‑safe 변형(−/_), 구현 차이 등에서 옵니다. UTF‑8을 사용하고 줄바꿈을 끄며 URL‑safe 사용과 패딩 유지 여부를 미리 결정하세요

왜 용량이 커지나요?

Base64는 8비트를 6비트로 표현하므로 약 33% 증가가 고유 특성입니다

이모지 등 특수 문자는 처리되나요?

UTF‑8 기준 지원됩니다. 비텍스트 바이너리는 디코딩 후 깨져 보일 수 있습니다