Base64 인코딩·디코딩 온라인 — 텍스트, 파일, 데이터 URL

텍스트나 파일을 Base64로 인코딩하고, 이미지를 CSS·<img> 코드와 함께 data URI로 바꾸고, Base64를 미리보기 가능한 파일로 디코딩하세요. 어떤 데이터도 브라우저 밖으로 나가지 않습니다.

URL-safe(RFC 4648 §5, 패딩 없음) 줄마다 따로 처리(일괄)

인코딩할 텍스트

Base64

RnJlZVRvb2xzRm9yV2ViIOKAlCBCYXNlNjTripQg66y47J6Q6rCAIOyVhOuLiOudvCDrsJTsnbTtirjrpbwg7J247L2U65Sp7ZWp64uI64ukLiDsnbTrqqjsp4Drj4Qg65Cp64uI64ukOiDwn4yy

입력 111 B → 148자(+33%)

모든 작업이 브라우저에서 실행됩니다. 입력한 내용은 전송되거나 저장되지 않습니다. 모든 무료 도구 보기.

문제를 발견하셨거나 개선할 점이 있나요? 모든 메시지를 읽고 빠르게 고칩니다.

이 무료 Base64 인코더·디코더는 브라우저에서 텍스트와 파일을 Base64로, 또 그 반대로 변환합니다. UTF-8을 올바르게 처리하므로 악센트 문자, 한글·한자, 이모지도 손상 없이 왕복 변환되는데, 간단한 온라인 변환기 대부분이 바로 이 부분에서 조용히 실패합니다. 이미지나 글꼴을 놓으면 data URI와 함께 바로 쓸 수 있는 CSS 배경·<img> 코드가 나오고 크기 증가량도 표시됩니다. 반대로 data URI나 Base64 문자열만 붙여 넣으면 이미지를 미리 보고 파일로 다운로드할 수 있습니다. 파일이 여러 개라면 최대 50개를 한꺼번에 놓아 data URI 표를 만들고 복사하거나 JSON·CSV로 다운로드할 수 있으며, 텍스트 모드에서는 목록을 줄 단위로 인코딩하거나 디코딩할 수 있습니다.

Base64는 암호화도 압축도 아닙니다. JSON, 이메일, URL처럼 텍스트만 받는 채널로 바이너리 데이터를 전달하는 방법이며, 그 대가로 바이트 수가 약 33% 늘어납니다. 이것만 알아도 언제 써야 할지 대부분 알 수 있고, 나머지는 아래 설명에서 다룹니다.

사용 방법

인코딩 또는 디코딩을 선택하세요. 인코딩할 때는 텍스트를 입력하거나 붙여 넣으면 입력하는 대로 Base64가 표시됩니다.
값을 URL이나 JWT에 넣을 때는 URL-safe를 켜세요. +와 /가 -와 _로 바뀌고 패딩이 제거됩니다.
파일을 인코딩하려면 “파일 → Base64 / data URI” 탭을 열고 파일을 선택하거나 끌어다 놓으세요. 원시 Base64, data URI, CSS·<img> 코드를 복사할 수 있습니다.
Base64를 다시 파일로 바꾸려면 “Base64 / data URI → 파일” 탭을 열고 붙여 넣으세요. 형식은 data: 접두사에서 읽거나 바이트로 감지하며, 이미지와 미디어는 미리 볼 수 있고, 다운로드를 누르면 올바른 확장자로 저장됩니다.
크기 표시줄을 확인하세요. 인코딩 결과가 메가바이트 단위로 커진다면 일반 파일로 참조하는 편이 거의 항상 더 나은 설계입니다.

자주 묻는 질문

여러 파일이나 여러 줄을 한 번에 Base64로 변환할 수 있나요?

네. 파일 탭에서 최대 50개 파일(총 25 MB)을 선택하거나 끌어다 놓으면 각 파일이 형식, 크기, Base64, data URI가 있는 행이 되며, 하나씩 복사하거나 JSON·CSV로 한꺼번에 다운로드할 수 있습니다. 텍스트 탭에서 “줄마다 따로 처리(일괄)”를 체크하면 목록의 모든 줄을 개별적으로 인코딩하거나 디코딩합니다. 유효한 Base64가 아닌 줄은 표시되고 비워지며 다른 줄에는 영향을 주지 않습니다.

Base64는 안전한가요? 데이터를 숨기는 데 쓸 수 있나요?

아니요. Base64는 암호화가 아닌 인코딩이라 이 페이지를 포함해 누구나 즉시 디코딩할 수 있습니다. 바이너리 데이터를 텍스트로 안전하게 전달하기 위해 존재합니다. 기밀성이 필요하다면 먼저 암호화하고, 텍스트 채널이 필요하면 그 암호문을 Base64로 인코딩하세요.

디코딩한 텍스트에 이상한 문자가 보이는 이유는 무엇인가요?

대개 원본이 UTF-8이 아니었거나, Base64를 만든 도구가 UTF-8 바이트 대신 각 문자의 코드 포인트를 인코딩했기 때문입니다(고전적인 btoa() 버그). 이 도구는 항상 UTF-8 바이트로 인코딩하고 디코딩합니다. 원본이 Latin-1이나 UTF-16이었다면 바이트는 여전히 올바르고 텍스트 표시만 달라집니다.

URL-safe Base64란 무엇인가요?

표준 Base64는 URL 안에서 의미를 가지는 +와 /를 사용하고, URL 인코더가 망가뜨리는 =로 패딩합니다. URL-safe 변형(RFC 4648 섹션 5)은 이를 -와 _로 바꾸고 보통 패딩을 생략합니다. JWT, OAuth state 값, 많은 API 토큰이 이 방식을 씁니다. 이 디코더는 두 형식을 모두 받아들입니다.

이미지를 Base64 데이터 URL로 삽입해야 하나요?

아주 작은 에셋(몇 KB 미만의 아이콘, 작은 인라인 SVG, 글꼴 서브셋)이라면 데이터 URL로 요청 한 번을 줄일 수 있어 그럴 가치가 있습니다. 그보다 크다면 아닙니다. 파일이 3분의 1만큼 커지고, 페이지와 별도로 캐시할 수 없으며, 포함된 HTML이나 CSS의 파싱을 막습니다. 대략 5~10 KB를 넘으면 일반 파일 참조가 낫습니다.

업로드되는 것이 있나요?

아니요. 텍스트는 브라우저의 TextEncoder와 btoa/atob로 변환하고, 파일은 File API로 로컬에서 읽습니다. 서버로 전송되는 것은 없습니다.

Base64를 다시 이미지로 어떻게 바꾸나요?

문자열을 “Base64 / data URI → 파일” 탭에 붙여 넣으세요. data:image/png;base64로 시작하면 그 접두사에서 형식을 가져오고, 접두사 없는 Base64라면 첫 바이트(PNG, JPEG, GIF, WebP, AVIF, SVG, PDF, MP3, MP4 등 일반적인 시그니처)를 읽어 판단합니다. 이미지가 페이지에 미리 표시되고, 다운로드를 누르면 일반 파일로 저장됩니다.

Base64의 원리 한 문단 정리

입력의 3바이트(24비트)마다 6비트 그룹 4개로 나누고, 각 그룹을 A–Z, a–z, 0–9, +, / 의 64개 문자 중 하나로 씁니다. 그래서 출력 길이는 항상 4의 배수이고 입력의 약 4/3이며, 입력이 3바이트의 배수가 아닐 때 = 패딩이 붙습니다. 디코딩은 이를 정확히 거꾸로 수행하므로 손실이 없습니다.

Base64를 만나는 곳

• HTTP 기본 인증: Authorization 헤더가 user:password를 Base64로 담습니다(암호화가 아니므로 HTTPS가 필요합니다).

• JWT: 헤더와 페이로드가 URL-safe Base64로 인코딩된 JSON입니다. JWT 디코더로 디코딩해 보세요.

• 이메일 첨부 파일(MIME)과 HTML 이메일에 삽입된 이미지.

• CSS와 HTML의 데이터 URL, 일부 JSON API의 이미지 필드.

• 바이트 유형이 없는 JSON과 XML의 바이너리 값.

data URI 구조와 크기 증가량

data URI는 data:[미디어 유형][;base64],데이터 형식입니다. data:image/png;base64,iVBORw0…는 PNG를 담고 있으며, ;base64가 없으면 데이터는 퍼센트 인코딩된 텍스트로, SVG의 경우 이쪽이 더 작은 경우가 많습니다. 브라우저는 미디어 유형을 보고 렌더링하므로 잘못된 유형(JPEG 바이트에 image/png)을 쓰면 일부 환경에서 이미지가 표시되지 않을 수 있습니다.

Base64는 3바이트를 4문자로 바꾸므로 페이로드가 3분의 1(33.3%, 패딩 문자 최대 2개 추가)만큼 커지고 data: 접두사가 조금 더 붙습니다. HTML이나 CSS에 gzip이나 Brotli를 적용하면 일부는 만회하지만 전부는 아닙니다. 이 도구는 파일의 정확한 수치를 보여 주므로 인라인할 가치가 있는지 판단할 수 있습니다. 5~10 KB를 넘는 이미지 대부분은 그럴 가치가 없습니다.