이미지를 Base64로 변환하면 데이터 URI(data URI)가 나옵니다. data:image/png;base64,iVBORw0KGgo… 같은 문자열로, HTML src나 CSS url()에 그대로 붙여넣을 수 있습니다. 브라우저는 그 자리에서 디코딩해 별도 다운로드 없이 그림을 보여 줍니다. 호스팅할 파일도, 추가 요청도 필요 없습니다.
그러면 그렇게 해야 할까요? 규칙은 간단합니다. 이미지가 약 2 KB 미만으로 작고, 거의 바뀌지 않으며, HTTP 요청 하나라도 줄이고 싶다면 Base64로 인라인하세요. 작은 아이콘이나 로고를 떠올리면 됩니다. 큰 이미지, 여러 페이지에서 재사용되거나 브라우저가 캐시해 두기를 바라는 이미지라면 일반 이미지 파일로 두는 편이 낫습니다. 다만 Base64는 파일을 약 33% 더 크게 만들고, 그 텍스트가 HTML이나 CSS에 한번 박히면 더 이상 단독으로 캐시될 수 없습니다.
특정 파일의 정확한 수치가 궁금하다면 Image to Base64 변환기가 브라우저 안에서 인코딩을 수행하고 용량 증가분을 정확히 보여줍니다. 어림짐작 대신 실제 데이터로 판단할 수 있습니다. 이어지는 글에서는 데이터 URI가 무엇인지부터 시작해 용량 부담의 계산, 인라인 여부를 가르는 기준, 그리고 그냥 일반 파일이 나은 경우까지 짚어 갑니다.
”이미지를 Base64로” 변환하면 실제로 나오는 것: 데이터 URI
이미지를 Base64로 변환하면 파일이 나오지 않습니다. RFC 2397에 정의된 데이터 URI 형식을 따르는 긴 문자열 하나가 나옵니다(MDN의 data: URL 참조 참고). 이 문자열은 세 부분으로 이루어집니다.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytesMIME 타입은 브라우저가 어떤 종류의 이미지를 디코딩하는지 알려줍니다. 이미지에서 흔한 것은 image/png, image/jpeg, image/gif, image/webp, image/svg+xml, 그리고 파비콘용 image/x-icon입니다. ;base64, 표시는 뒤따르는 페이로드가 일반 텍스트가 아니라 Base64라는 뜻입니다. 쉼표 뒤의 모든 것이 출력 가능한 ASCII로 다시 표현된 이미지입니다.
마지막 부분은 프라이버시 측면에서 중요합니다. 변환은 브라우저 안에서 FileReader API의 readAsDataURL로만 이루어지고, 서버로 올라가는 것은 아무것도 없습니다. 출시 전 스크린샷이나 내부 다이어그램, 미공개 아트워크를 도구에 떨어뜨려 놓고 Network 탭이 빈 채로 있는 것을 직접 확인할 수 있습니다. 원시 바이트가 어떻게 ASCII 문자열이 되는지는 understanding Base64에서 인코딩을 바닥부터 다루고, complete Base64 guide는 같은 데이터 URL 개념을 폰트, PDF, 그 밖의 파일 타입으로 넓힙니다.
실제 예시: 68바이트 투명 PNG
가장 작은 실용적 사례입니다. 디스크에서 68바이트인 1×1 투명 PNG를 완전한 데이터 URI로 표현하면 이렇습니다.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==이것을 브라우저 주소창에 붙여넣으면(투명하니 보이지는 않겠지만) 네트워크 활동 없이 유효한 이미지가 렌더링됩니다. 끝에 붙은 ==를 눈여겨보세요. 패딩이고, 잠시 후 다룹니다. 텍스트 Base64가 어떻게 생겼는지도 그대로 드러나는데, 텍스트 대신 이미지 바이트에 적용했을 뿐입니다. 일반 텍스트 문자열만 인코딩하거나 디코딩하면 된다면 Base64 encode/decode 도구가 그 일을 처리합니다.
33% 용량 부담 (그리고 그것이 누적되는 이유)
Base64는 고정된 그룹 단위로 작동합니다. 바이너리 3바이트마다 4개의 ASCII 문자가 됩니다. 4/3은 약 1.33이고, 여기서 +33%라는 수치가 나옵니다. 패딩 한두 바이트와 data:image/png;base64, 접두사까지 더하면 아주 작은 파일에서는 오버헤드가 조금 더 높습니다. 예를 들어 9 KB PNG는 약 12 KB의 텍스트가 됩니다.
왜 정확히 3 대 4일까요? Base64는 64자 알파벳을 사용합니다. A–Z, a–z, 0–9, 그리고 +와 /입니다. 64개 기호는 문자당 6비트의 정보입니다. 바이너리 바이트는 각각 8비트입니다. 6과 8의 최소공배수는 24비트이고, 이는 3바이트 또는 4개의 Base64 문자에 해당하므로, 인코더는 이미지를 한 번에 24비트씩 훑어 나갑니다. 이미지 길이가 3의 깔끔한 배수가 아닐 때는 한두 개의 = 문자가 마지막 그룹을 채웁니다. 그것이 계산이고, 고정되어 있습니다. 33%를 줄여 주는 인코더 설정은 없습니다.
그 33%는 눈에 보이는 비용입니다. 정작 “그냥 인라인해라”라는 조언이 대부분 건너뛰는 숨은 비용은, 이 부담이 계속 쌓인다는 점입니다.
- 컨테이너 파일이 바뀔 때마다 이미지가 다시 다운로드됩니다. 외부
logo.png는 그 자체로 하나의 리소스입니다. 이것을styles.css에 인라인하면, 색상을 조정하거나 규칙을 추가하느라 스타일시트를 편집할 때마다 이미지의 캐시까지 함께 무효화됩니다. 방문자는 이미 가지고 있던 그림을 다시 받게 됩니다. - 독립적으로 캐시할 수 없습니다. 일반 이미지 파일은 한 번 가져오면 모든 페이지, 모든 방문에서 재사용됩니다. 인라인된 데이터 URI는 문서의 일부이므로, 그것을 담은 모든 페이지에서, 그 문서의 캐시가 빗나갈 때마다 다시 전송됩니다.
- CSS는 렌더링을 차단합니다. 브라우저는 CSS를 확보하기 전까지 화면을 그리지 않습니다. 큰 데이터 URI를 스타일시트에 끼워 넣으면 렌더링 차단 리소스가 그만큼 커지고, 페이지 전체의 첫 페인트가 늦어집니다.
gzip이나 brotli가 33%를 상쇄해 줄까요?
부분적으로는 그렇지만 완전히는 아닙니다. Base64 텍스트는 반복성이 높아 gzip과 brotli가 잘 압축하고, 전송 구간에서 부풀려진 분량의 상당 부분을 되찾아 줍니다. 그래도 두 가지는 여전히 남습니다. 압축된 Base64는 보통 압축된 원본 바이너리보다 조금 더 큰데, 압축기에 더 비효율적인 출발점을 건넸기 때문입니다. 그리고 더 중요한 점으로, 압축은 캐싱이나 렌더링 차단을 해결해 주지 못합니다. 전송 구간에서 더 작아진 데이터 URI라도 여전히 호스트 파일과 함께 다시 다운로드되고, 여전히 단독으로 캐시될 수 없습니다.
다시 말해 압축은 인라인 비용을 없애는 것과 다릅니다. 최소화(minify), gzip, brotli의 차이가 모호하다면, code minification guide가 이 계층들이 어떻게 쌓이는지, 그리고 바이트를 짜내는 일이 왜 인라인이 만들어 내는 캐싱 문제를 풀어 주지 못하는지 설명합니다.
Base64 이미지를 사용할 때 (결정 매트릭스)
전체 결정은 몇 가지 요소로 귀결됩니다. 나란히 놓고 보면 이렇습니다.
| 요소 | 인라인(Base64) 쪽으로 | 일반 파일 쪽으로 |
|---|---|---|
| 크기 | 약 2 KB 미만 (초록) | 약 10 KB 초과 (빨강); 2–10 KB는 판단의 영역 (노랑) |
| 재사용 | 한 페이지, 한두 곳 | 여러 페이지에 걸쳐 반복 |
| 변경 빈도 | 거의 바뀌지 않음 | 자주 편집됨 |
| 맥락 | HTML 이메일, 자체 완결형 위젯이나 북마클릿, JSON/API 페이로드, 요청 하나를 아낄 만한 핵심 above-the-fold 아이콘 | 콘텐츠 이미지, 공유되는 캐시 가능 자산 |
이 크기 임계값은 임의로 정한 값이 아니라 Image to Base64 변환기에 내장된 신호등 배지를 그대로 반영한 것입니다. 2 KB 미만은 초록, 10 KB까지는 노랑, 그 위는 빨강입니다. 도구가 실제 파일을 읽어 어느 구간에 들어가는지 알려줍니다.
간단한 원칙
한 줄만 기억해야 한다면 이렇게 하세요. 약 2 KB 미만이고 한두 곳에서만 쓰인다면 인라인이 대개 이득이고, 약 10 KB를 넘거나 여러 페이지에서 재사용된다면 캐시되는 일반 파일이 거의 항상 낫습니다. 2–10 KB 중간 구간은 아낀 요청과 잃어버린 캐시를 상황에 맞게 저울질하는 영역입니다.
잘 맞는 경우 자세히
Base64가 제값을 하는 경우는 다음과 같습니다.
- HTML 이메일. 많은 이메일 클라이언트가 프라이버시를 위해 외부 호스팅 이미지를 기본 차단하는데, 그러면 원격 로고에 기대는 레이아웃이 깨집니다. 작은 인라인 데이터 URI는 서버 가져오기 없이 바로 렌더링됩니다. 다만 로고와 아이콘에만 쓰세요. 사진을 이메일에 인라인하지는 마세요.
- 자체 완결형 위젯과 북마클릿. 북마클릿이나 임베드 가능한 위젯은 외부 의존성 없이 동작해야 합니다. 아이콘을 인라인하면 모든 것이 떨어뜨려 쓸 수 있는 단일 파일 안에 담깁니다.
- JSON과 API 페이로드. 썸네일을 JSON 문서나 설정 파일 안에 실어 보내는 편이 가장 깔끔할 때가 있습니다. 왕복 한 번이면 끝나고, 따로 엮을 두 번째 요청이 없습니다.
- 핵심 above-the-fold 아이콘. 작은 로고가 Largest Contentful Paint를 좌우하고 핵심 경로에서 요청 하나를 줄이고 싶을 때 인라인이 도움이 될 수 있습니다. 작은 경우에 한해서입니다.
이 경우들에는 공통점이 하나 있습니다. 자산이 다른 무언가와 함께 이동하며, 그렇지 않았다면 별도의 전달 경로가 필요했을 상황이라는 점입니다. 이메일은 여러분의 CDN에 기댈 수 없고, 북마클릿에는 따로 가져올 두 번째 파일이 없으며, JSON 응답은 하나의 페이로드로 끝납니다. 이때 인라인의 대안은 “캐시된 파일”이 아니라 “사라진 이미지”이고, 이 차이가 판단을 통째로 바꿉니다. 좋은 Base64 적합 사례인지를 가르는 기준은 “작은가”가 아니라 “여기서 별도 파일이 애초에 선택지이긴 한가”입니다.
인라인하지 말아야 할 때: 캐싱, 지연 로딩, Core Web Vitals
반대편 이야기는 더 깁니다. 인라인이 브라우저가 잘하는 여러 일을 조용히 무력화하기 때문입니다.
독립적 캐싱을 잃습니다. 재방문자에게 가장 뼈아픈 부분입니다. 일반 이미지는 첫 방문 이후 캐시에 자리 잡아 이후로는 늘 즉시 로드됩니다. 인라인된 이미지는 독립적인 캐시 항목이 없어 매번 문서와 함께 따라다니므로, 재방문자가 그 바이트 비용을 매번 다시 치릅니다.
지연 로딩을 잃습니다. loading="lazy" 속성은 사용자가 가까이 스크롤하기 전까지 폴드 아래 이미지를 미뤄 두게 합니다. 데이터 URI는 HTML이 읽히는 순간 파싱되고 “다운로드”되므로 미룰 것 자체가 없습니다. 폴드 아래 이미지 열두 개를 인라인하면 그 전부를 초기 로드로 끌어다 놓은 셈입니다.
렌더링 차단 리소스를 키웁니다. 앞서 말했듯이 CSS 안의 데이터 URI는 첫 페인트를 막는 리소스를 부풀립니다. 그 스타일시트가 클수록 페이지는 더 오래 빈 채로 남습니다.
모바일에서는 디코딩 비용이 더 큽니다. data URI는 문서가 로드될 때마다 Base64 디코딩이 필요하며, 저사양 휴대폰에서는 이 CPU 작업이 쌓입니다. 게다가 그 바이트는 브라우저 디스크 캐시에 들어가지 않으므로, 무거운 인라인 이미지는 일반 파일처럼 한 번 캐시·디코딩되는 대신 방문할 때마다 다시 디코딩됩니다.
이 조언이 바뀌어 온 데에는 역사적 배경이 있습니다. 인라인을 옹호하던 원래 논거는 HTTP/1.1 시대에 요청 수를 줄인다는 것이었습니다. 당시에는 연결 하나가 한 번에 리소스 하나만 가져올 수 있었으므로, 작은 아이콘 40개가 있는 페이지는 왕복을 40번 치렀습니다. HTTP/2가 여러 요청을 단일 연결로 다중화하면서 이 그림이 바뀌었고, 작은 파일을 하나 더 두는 비용이 싸졌습니다. 인라인의 가장 큰 보상이던 요청 감소는 대부분 사라졌지만 비용은 그대로 남았습니다. 캐싱이 사라지고, 지연 로딩을 못 하며, 렌더링 차단 파일이 커집니다. Base64 스프라이트를 예찬하는 오래된 글을 읽는다면, 오늘날 여러분 사이트가 실제로 쓰는 프로토콜에 비추어 다시 가늠해 보세요.
Core Web Vitals 관점
인라인은 LCP(Largest Contentful Paint)에서 양날의 검입니다. LCP 요소인 작은 above-the-fold 이미지라면 요청을 없애는 것이 LCP를 조금 앞당길 수 있습니다. 하지만 큰 이미지를 인라인하면 정반대가 되어, 그 이미지를 담은 문서나 스타일시트를 지연시키고 페이지 전체의 LCP를 뒤로 밉니다. 어느 쪽으로 갈지는 크기 임계값이 가릅니다.
CLS(Cumulative Layout Shift)에서는 인라인이 핵심 규칙을 바꾸지 않습니다. 이미지에는 여전히 명시적인 width와 height(또는 aspect-ratio 박스)가 필요하고, 그래야 브라우저가 렌더링 전에 공간을 예약합니다. 치수가 없는 데이터 URI는 치수가 없는 원격 이미지와 똑같이 레이아웃을 흔듭니다.
인라인보다 나은 지렛대는 보통 원본을 줄이는 쪽입니다. 인코딩하기 전에 이미지를 압축하면 파일도, 그 결과로 나오는 데이터 URI도 함께 작아집니다. browser vs Node image compression guide는 이를 클라이언트 측이나 빌드 단계에서 하는 방법을 다루고, WebP vs AVIF vs JPEG는 애초에 작은 포맷을 고르는 데 도움을 줍니다.
HTML, CSS, Markdown, JSON에서 이미지를 인라인하는 방법
데이터 URI를 손에 넣었다면, 각 맥락에 어떻게 들어가는지가 다음과 같습니다. 모두 Image to Base64 변환기가 만들어 주는, 붙여넣기만 하면 되는 스니펫입니다.
HTML — URI를 아무 src에나 붙여넣습니다.
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">CSS — background-image에 쓰려면 url()로 감쌉니다. CSS에서 base64 이미지를 다루는 정석 패턴입니다.
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}Markdown — 파일을 호스팅할 수 없는 README, GitHub 이슈, 노트북을 위한 자체 완결형 이미지 링크입니다.
JSON — API나 설정 페이로드 안에 임베드된 자산입니다.
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }네 가지 모두 URL이 허용되는 곳이라면 어디서든 동작합니다. img src, CSS background, mask-image, 심지어 파비콘 <link>까지요. 최신 브라우저는 모두 data: 스킴을 지원합니다.
이것들을 빠르게 생성하기
이것들을 손으로 만들면 오류가 나기 쉽습니다. MIME 타입 하나만 틀리거나 줄바꿈 하나가 섞여도 이미지가 소리 없이 렌더링에 실패합니다. 파일을 Image to Base64 변환기에 떨어뜨리면 각각 복사 버튼이 달린 네 가지 스니펫을 한꺼번에 만들어 주고, 용량 증가분도 정확히 알려 주므로 그 자산이 애초에 인라인에 어울리는지 미리 가늠할 수 있습니다.
SVG: Base64가 대개 지는 특수한 경우
SVG는 일반적인 논리를 깨뜨립니다. SVG는 바이너리가 아니라 텍스트이기 때문입니다. Base64는 바이너리 데이터를 텍스트로 안전하게 만들려고 존재하는데, SVG는 이미 XML 텍스트입니다. 이것을 Base64로 인코딩하면 인코딩이 필요 없던 문자열을 부풀리기만 하고, 그 과정에서 사람이 읽지 못하게 만듭니다. 그래서 SVG에 한해서는 Base64가 거의 항상 잘못된 선택입니다.
같은 아이콘을 인라인하는 세 가지 방법을 비교해 보겠습니다.
/* 1. Base64 데이터 URI — 인코딩이 필요 없던 텍스트에 33% 부담을 더한다 */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. URL 인코딩된 데이터 URI — 소수의 문자만 퍼센트 인코딩, 33% 부담 없음 */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. HTML에 <svg>를 직접 인라인 — CSS로 완전히 스타일링 가능 */<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="24" height="24">
<path d="M12 2 L22 22 H2 Z" fill="currentColor" />
</svg>옵션 2(URL 인코딩)는 보통 옵션 1보다 작고 사람이 읽을 수 있는 상태를 유지하며 압축도 더 잘됩니다. URI를 깨뜨리는 문자, 즉 <, >, #, 따옴표만 퍼센트 인코딩하고 나머지는 읽을 수 있게 둡니다. URL encoder/decoder 방식은 도구 자체에 설명되어 있습니다. Base64 SVG는 빌드 파이프라인이 특별히 요구할 때에만 쓰세요.
인라인 <svg>가 Base64 PNG 아이콘을 자주 이기는 이유
Base64로 인코딩한 PNG 아이콘과 인라인 <svg> 사이에서 고른다면 SVG가 대체로 모든 면에서 앞섭니다. 어떤 크기로도 흐려짐 없이 확대되고, 33% 부담이 없으며, 다른 데이터 URI와 달리 CSS로 스타일링하거나 애니메이션을 주거나 currentColor로 다시 색칠할 수 있습니다. 반면 Base64 PNG는 한번 인코딩하면 손댈 수 없는 고정 해상도 덩어리입니다. 래스터 Base64는 사진이나 래스터 스크린샷을 정말 인라인해야 하는 경우를 위해 아껴 두세요.
반대 방향 디코딩: Base64에서 이미지로
반대 문제도 그만큼 흔합니다. API 응답이나 로그 한 줄, 데이터베이스 컬럼, 디버깅 중인 스타일시트에서 가져온 Base64 문자열이 있고 실제 그림을 봐야 하는 경우입니다.
여기서 사람들이 잘 걸려 넘어지는 지점이 둘 있습니다. 하나는 원시 Base64와 완전한 데이터 URI의 차이입니다. 완전한 데이터 URI(data:image/png;base64,…)는 자체 MIME 타입을 지니지만 헐벗은 페이로드(iVBORw0KGgo…)는 그렇지 않습니다. 헐벗은 페이로드를 렌더링하려면 올바른 data: 접두사를 앞에 붙이거나, 도구가 앞쪽 바이트에서 포맷을 추론하게 하면 됩니다. iVBORw0KGgo는 PNG, /9j/는 JPEG, R0lGOD는 GIF입니다.
다른 하나는 줄바꿈입니다. 이메일이나 오래된 도구에서 나온 Base64는 RFC 2045에 따라 76자마다 줄바꿈되는 경우가 많습니다. 이 줄바꿈은 디코딩 전에 제거해야 하고, 그러지 않으면 HTML 속성이나 url()에서 문자열이 무효가 됩니다.
브라우저에서는 완전한 데이터 URI를 <img>에 그대로 건넬 수 있습니다.
<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">서버에서는 Node가 페이로드로부터 파일을 재구성합니다.
import { writeFileSync } from "node:fs";
const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // 원시 페이로드, data: 접두사 없음
writeFileSync("output.png", Buffer.from(b64, "base64"));코드를 쓰지 않는 경로라면 Base64 to Image 변환기에 문자열을 붙여넣으세요. 접두사가 있든 없든, 줄바꿈이 섞여 있어도 미리 보고 치수와 MIME 타입을 읽은 다음 실제 PNG, JPG, GIF, SVG로 다운로드할 수 있습니다. 도구가 공백을 제거하고 누락된 접두사를 허용하며 매직 바이트로 포맷을 자동 감지합니다.
디코딩한 이미지에는 간단히 해 볼 만한 점검이 하나 있습니다. 보고된 치수를 보세요. 여러 개가 들어 있던 파일에서 문자열 하나를 꺼냈는데 결과가 1×1이라면, 원하던 자산 대신 추적 픽셀을 집었을 가능성이 높습니다. 그리고 디코딩은 순전히 기계적이고 손실이 없습니다. Base64 PNG는 재압축 없이 한 바이트도 다르지 않은 똑같은 PNG로 돌아오고, 그 과정에서 바뀌는 것은 컨테이너뿐입니다. 나갈 때는 텍스트 문자열, 돌아올 때는 바이너리 파일입니다.
FAQ
제 이미지를 Base64로 변환해야 하나요?
그럴 만한 가치가 있을 때만 하세요. 약 2 KB 미만으로 작고 거의 바뀌지 않는 아이콘이나 로고이면서 HTTP 요청 하나를 줄이는 게 중요한 경우, 그리고 HTML 이메일이나 자체 완결형 위젯, JSON 페이로드가 그렇습니다. 큰 이미지나 여러 페이지에서 재사용되는 이미지는 거의 항상 일반 파일로 둬야 캐싱과 지연 로딩을 유지할 수 있습니다.
Base64는 이미지를 얼마나 더 크게 만드나요?
약 +33%입니다. Base64는 바이너리 3바이트마다 4개의 ASCII 문자로 인코딩하고, 여기에 약간의 패딩과 data: 접두사가 더해집니다. 9 KB PNG는 대략 12 KB의 텍스트가 됩니다. 파일별 증가분을 정확히 보고 싶다면 이미지를 Base64로 변환하세요. 도구가 메타데이터 바에 정확한 수치를 보여줍니다.
Base64가 이미지를 더 빨리 로드하게 하나요?
아주 작은 above-the-fold 아이콘이라면 요청 한 번의 왕복을 아껴 그럴 수 있습니다. 더 크거나 재사용되는 이미지에는 보통 더 느립니다. 독립적 캐싱을 잃고 지연 로딩을 못 하며, CSS에 인라인하면 렌더링 차단 리소스가 커집니다. 결국 크기가 가른다고 보면 됩니다.
CSS에서 Base64 이미지를 사용할 수 있나요?
네: background-image: url("data:image/png;base64,…"). 아주 작은 아이콘에는 괜찮습니다. 다만 데이터 URI가 스타일시트의 일부가 되므로, CSS가 바뀔 때마다 파일 전체가 다시 다운로드되고, 이미지는 그것과 별도로 캐시될 수 없다는 점을 기억하세요.
아이콘에 SVG를 써야 하나요, Base64를 써야 하나요?
인라인 <svg>나 URL 인코딩된 SVG 데이터 URI를 쓰세요. SVG는 텍스트라 깔끔하게 확대되고 33% 부담이 없어 보통 Base64 PNG보다 작으며 CSS로 스타일링할 수 있습니다. Base64는 래스터 아이콘이 특별히 필요할 때에만 쓰세요.
Base64 문자열을 다시 이미지로 어떻게 변환하나요?
브라우저에서는 완전한 data:image/…;base64,… URI를 <img src>에 떨어뜨리세요. 서버에서는 Buffer.from(b64, "base64")로 파일을 씁니다. 원시 페이로드는 data: 접두사를 추가해야 하고, 줄바꿈된 문자열은 먼저 줄바꿈을 제거해야 합니다. Base64 to Image 도구가 그 모든 것을 처리하고 결과를 다운로드하게 해 줍니다.