> base64 인코더 | text | file <

위의 입력 영역에 텍스트를 입력하거나 붙여넣으세요. 자동 인코딩이 기본 활성화되어 있으므로 입력하는 동안 Base64 결과가 출력 상자에 나타납니다. [ENCODE] 버튼을 클릭하거나 Ctrl/Cmd + Enter를 눌러 수동으로 인코딩을 트리거할 수 있습니다. Base64가 사용될 위치(JWT, OAuth, URL → 둘 다 켜기)에 따라 --url-safe 또는 --no-padding을 전환하세요. 모든 것은 브라우저에서 로컬로 실행됩니다: 업로드, 로그, 입력과 관련된 네트워크 요청 없음.

입력 영역 아래의 [파일 업로드] 버튼을 클릭하고 최대 100MB의 파일을 선택하세요. 인코더는 FileReader.readAsArrayBuffer로 파일을 읽고, btoa를 통해 32KB 청크로 바이트를 스트리밍하며(대용량 파일이 브라우저를 다운시키지 않도록), 전체 Base64를 출력 상자에 씁니다. 더 큰 파일의 경우 명령줄 인코더를 사용하세요: base64 < input.bin > output.txt (macOS/Linux), 또는 PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

Base64를 Data URI 형식(예: data:image/png;base64,...)으로 원한다면 출력 앞에 MIME 타입과 ;base64,를 추가하거나, 전용 이미지 → Base64 도구를 사용하세요. PNG, JPG, GIF, WebP 및 SVG용 붙여넣기 준비가 된 Data URI를 출력합니다.

세 가지 모두 RFC 4648에 정의되어 있습니다:

• 표준 Base64 (§4)는 = 패딩과 함께 A-Z a-z 0-9 + / 알파벳을 사용합니다. 출력 길이는 항상 4의 배수입니다. MIME, HTTP Basic Auth, JSON 문자열 값에 안전합니다.

• URL-safe Base64 (§5)는 +를 -로, /를 _로 대체합니다. Base64가 URL 경로, 쿼리 매개변수, 파일명 또는 JWT 세그먼트에 배치될 때 필요합니다 — 표준 +/ 문자는 그렇지 않으면 퍼센트 인코딩이 필요합니다.

• 패딩 없음(§4 및 §5 모두, base64url unpadded)은 끝의 = 문자를 제거합니다. 길이는 더 이상 4의 배수가 아니지만 디코더는 나머지 mod 4에서 원래 길이를 계산할 수 있습니다. JWT(RFC 7515에 따른 base64url), WebAuthn, 일부 CBOR/COSE 구현에서 사용됩니다.

디코더는 어떤 변형을 기대해야 하는지 알려야 합니다 — 우리의 Base64 디코더는 세 가지 모두 자동 감지합니다.

모든 주요 언어와 런타임에 Base64 인코딩이 기본 탑재되어 있습니다. 복사하여 바로 사용할 수 있는 스니펫:

JavaScript (브라우저):
btoa('Hello') // SGVsbG8=
// UTF-8의 경우:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 safe

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-safe, 패딩 없음

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-safe 패딩 없음

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (패딩 없음)
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=. Linux에서 76열 줄바꿈을 억제하려면 base64 -w 0을 사용하세요.

Base64 출력은 입력보다 약 33% 큽니다: 입력 3바이트마다 출력 4문자가 됩니다. 정확한 공식: 패딩 포함 ceil(n / 3) × 4, 패딩 없이는 ceil(n × 4 / 3). 76열(MIME) 또는 64열(PEM)로 줄바꿈하면 몇 바이트의 추가 오버헤드가 발생합니다.

예시:
• 1KB 바이너리 → ~1.37KB Base64
• 100KB 이미지 → ~137KB Data URI
• 1MB PDF → JSON에서 ~1.37MB Base64

Base64를 피해야 할 때:
• 대용량 파일 전송: HTML에 Base64로 내장된 10MB 이미지는 13.7MB의 파싱된 텍스트가 되어 메인 스레드를 차단하고 별도로 캐시할 수 없습니다. <img src="/assets/photo.png">를 선호하세요.
• 성능이 중요한 API: JSON의 500KB Base64 payload는 동등한 바이너리 엔드포인트보다 파싱이 ~2-3배 느립니다.
• 보안 조치로서: Base64는 암호화가 아닙니다 — 누구나 디코딩할 수 있습니다. 기밀성을 위해서는 AES-GCM이나 유사한 것을 사용하세요.
• 데이터베이스 BLOB: 원시 바이트를 Base64 텍스트가 아닌 BLOB/BYTEA로 저장하여 33% 저장 공간을 절약하고 인코딩/디코딩 왕복을 피하세요.

JWT(RFC 7515)와 OAuth PKCE(RFC 7636)는 모두 종종 base64url이라 불리는 패딩 없는 URL-safe Base64를 사용합니다. 이 도구에서 만들려면: --url-safe와 --no-padding 체크박스를 모두 활성화한 다음 텍스트를 인코딩하세요.

프로그램 등가물:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

base64url이 필요한 일반적인 JWT 필드: 점으로 구분된 세 세그먼트(header, payload, signature), OAuth PKCE code_verifier/code_challenge, WebAuthn challenge, Web Push p256dh/auth 키, Google의 Request.state 매개변수.

흔한 버그는 표준 Base64(+/)로 JWT를 보내는 것입니다 — API는 전송 중 +가 공백으로 URL 디코딩되기 때문에 잘못된 형식으로 거부합니다.

예, 한 가지 주의사항이 있습니다. 이 인코더는 Data URI의 Base64 부분을 생성합니다 — ;base64, 이후 부분. 완전한 Data URI를 만들려면 앞에 추가하세요:

data:<mime-type>;base64,<encoded-output>

일반적인 MIME 타입:
• data:image/png;base64,... — PNG 이미지
• data:image/jpeg;base64,... — JPEG 이미지
• data:image/svg+xml;base64,... — SVG(또는 Base64 없이 data:image/svg+xml;utf8,를 사용 — 보통 더 작음)
• data:application/pdf;base64,... — PDF 파일
• data:application/font-woff2;base64,... — 폰트 임베드
• data:text/plain;charset=utf-8;base64,... — Base64로 감싼 텍스트

이미지와 SVG의 경우 이미지 → Base64 도구는 CSS background-image, 인라인 <img src="..."> 또는 <object data="..."> 태그에 붙여넣을 준비가 된 완전한 Data URI를 출력합니다.

크기 경고: 20-30KB를 초과하는 Data URI는 브라우저가 미리 로드할 수 없으므로 LCP(Largest Contentful Paint)를 저하시킵니다 — 인라인 Base64 이미지는 작게 유지하고, 더 큰 에셋에는 loading="lazy"가 있는 일반 <img>를 선호하세요.

예 — 아무것도 브라우저를 떠나지 않습니다. 인코더는 네이티브 btoa(), TextEncoder, FileReader API를 사용하여 완전히 JavaScript에서 실행됩니다. 입력 내용에 대한 네트워크 호출, 원격 측정, 로깅, 인코딩하는 내용에 대한 타사 분석이 없습니다. 인코딩하는 동안 DevTools의 네트워크 탭을 열고 관련 요청이 0인 것을 관찰할 수 있습니다.

그러나 Base64는 암호화가 아닙니다 — 되돌릴 수 있는 인코딩이며, 출력을 가진 누구나 디코딩할 수 있습니다. 그러므로:
• 프로덕션 시크릿을 붙여넣지 마세요 채팅, 스크린샷, 로그에 인코딩된 형태라도.
• HTTP Basic Auth의 경우 Base64 Authorization: Basic 헤더는 TLS(HTTPS)에서만 안전합니다. 평문 HTTP에서는 쉽게 스니핑됩니다.
• 실제 기밀성을 위해서는 AES-GCM, age, sops 또는 KMS를 사용하고, 필요하다면 전송을 위해 암호문을 Base64로 인코딩하세요.

엄격한 데이터 유출 방지 정책의 경우 이 페이지를 오프라인으로 저장하세요(Cmd/Ctrl + S). 서버 종속성이 없으므로 한 번 로드 후 인코더는 완전히 에어갭으로 작동합니다.

인코더는 파일 핸들러의 하드 제한을 통해 최대 100MB 파일을 지원합니다 — 대부분의 이미지, PDF, ZIP 아카이브, 심지어 짧은 비디오에도 충분합니다. 성능 목표:

• < 1MB: 인코딩이 <50ms에 완료, UI 멈춤 없음.
• 1 – 10MB: CPU에 따라 100-500ms. 32KB 청크로 인코딩하므로 브라우저가 반응성을 유지합니다.
• 10 – 100MB: 2-15초. 그런 거대한 Base64 문자열을 붙여넣기/스크롤할 때 출력 텍스트 영역이 약간 지연될 수 있습니다. 필요시 DevTools에서 출력을 .txt 파일로 다운로드하는 것을 고려하세요.
• > 100MB: 차단됨 — 브라우저 메모리 오버헤드(입력 바이트 + 바이너리 문자열 + Base64 문자열 ≈ 파일 크기의 3-4배)가 탭 충돌 위험이 있습니다. 사용하세요:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

스트리밍/다중 GB 워크플로우의 경우 모든 것을 메모리에 로드하지 않는 Node.js/Python 청크 접근 방식은 Base64로 대용량 파일 인코딩을 참조하세요.

이 인코더는 현대 웹, JSON, Linux, macOS 및 거의 모든 프로그래밍 언어가 기본으로 사용하는 UTF-8을 사용합니다. 내부적으로 텍스트는 항상 UTF-8 바이트를 생성하는 new TextEncoder().encode(input)을 통과한 후에야 Base64로 인코딩됩니다.

왜 중요한가: 오래된 JavaScript btoa() 함수는 Latin-1만 처리하며 é, 中 또는 😀 같은 문자에 InvalidCharacterError를 던집니다. 우리의 래퍼는 UTF-8 변환을 처리하므로 이모지, 중국어, 일본어, 한국어, 아랍어, 키릴 문자 및 모든 유니코드 코드 포인트가 올바르게 인코딩됩니다.

다른 인코딩이 필요하다면:
• UTF-16 LE(Windows 기본): 드묾 — 보통 레거시 상호운용의 신호입니다. 어쨌든 new TextEncoder({ fatal: true }).encode(s)를 사용하고 상류에서 변환하세요.
• ISO-8859-1 / Latin-1: 인코딩 전에 코드 포인트 0-255를 바이트로 수동 매핑하세요.
• GB18030, Shift_JIS, EUC-KR: Node.js에서 iconv-lite 같은 라이브러리로 먼저 트랜스코드하세요.

미묘한 함정: 소스 데이터가 이미 UTF-8이 아닌 인코딩(예: 레거시 MySQL 덤프 읽기)인 경우, 먼저 올바른 코덱으로 디코드한 다음 Base64 전에 UTF-8로 재인코드하세요 — 그렇지 않으면 디코딩된 Base64가 mojibake를 보존합니다.