Kiedy konwertujesz obraz na Base64, otrzymujesz data URI, czyli ciąg w rodzaju data:image/png;base64,iVBORw0KGgo…, który można wkleić wprost do atrybutu src w HTML albo do url() w CSS. Przeglądarka dekoduje go na miejscu i pokazuje obrazek bez osobnego pobierania. Żadnego pliku do hostowania, żadnego dodatkowego żądania.
Czy zatem warto to robić? Oto krótka reguła. Osadzaj obraz jako Base64, gdy jest mały (poniżej około 2 KB), rzadko się zmienia, a Ty chcesz pominąć jedno żądanie HTTP, czyli przy drobnych ikonach i logotypach. We wszystkich pozostałych przypadkach (duże obrazy, cokolwiek używanego wielokrotnie na wielu stronach, cokolwiek, co przeglądarka ma buforować) zostań przy zwykłym pliku obrazu. Haczyk polega na tym, że Base64 powiększa plik o około 33%, a gdy ten tekst trafi już do Twojego HTML lub CSS, nie da się go dłużej buforować samodzielnie.
Jeśli potrzebne są dokładne liczby dla konkretnego pliku, konwerter obrazu na Base64 wykonuje kodowanie w przeglądarce i pokazuje precyzyjny przyrost rozmiaru. Decyzję można wtedy oprzeć na realnych danych zamiast na regule kciuka. Ten przewodnik wyjaśnia, czym właściwie jest data URI i jaka matematyka kryje się za przyrostem rozmiaru, podaje macierz decyzyjną na sytuacje, gdy osadzanie się opłaca, oraz przypadki, w których lepiej zostać przy zwykłym pliku.
Co naprawdę powstaje z „obrazu na Base64”: data URI
Konwersja obrazu na Base64 nie daje Ci pliku. Daje jeden długi ciąg znaków w formacie data URI zdefiniowanym w RFC 2397 (zobacz dokumentację adresów data: URL w MDN). Ciąg ma trzy części:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytesMIME mówi przeglądarce, jaki rodzaj obrazu dekoduje. Najczęstsze są image/png, image/jpeg, image/gif, image/webp, image/svg+xml oraz image/x-icon dla favikon. Znacznik ;base64, informuje, że ładunek, który po nim następuje, jest zapisany w Base64, a nie zwykłym tekstem. Wszystko po przecinku to obraz wyrażony ponownie jako drukowalny ASCII.
Ta ostatnia część ma znaczenie dla prywatności. Konwersja działa w całości w przeglądarce dzięki metodzie readAsDataURL z API FileReader, więc nic nie trafia na serwer. Można wrzucić do narzędzia zrzut ekranu sprzed premiery, wewnętrzny diagram albo niepublikowaną grafikę i sprawdzić, że karta Network pozostaje pusta. Mechanikę tego, jak surowe bajty stają się tym ciągiem ASCII, omawia od podstaw understanding Base64, a pełny przewodnik po Base64 rozszerza tę samą ideę data URL na czcionki, pliki PDF i inne typy plików.
Prawdziwy przykład: przezroczysty PNG o rozmiarze 68 bajtów
Oto najmniejszy praktyczny przypadek — przezroczysty PNG 1×1, 68 bajtów na dysku, jako kompletne data URI:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==Po wklejeniu tego do paska adresu przeglądarki widać prawidłowo wyrenderowany obraz (no, nie widać — jest przezroczysty) przy zerowej aktywności sieciowej. Warto zwrócić uwagę na końcowe ==: to dopełnienie, do którego jeszcze wrócimy. Tak samo wygląda tekstowy Base64, tyle że zastosowany do bajtów obrazu zamiast tekstu. Do kodowania lub dekodowania samych zwykłych ciągów tekstowych służy narzędzie koder/dekoder Base64.
Podatek 33% od rozmiaru (i dlaczego się kumuluje)
Base64 działa w stałych grupach: każde 3 bajty danych binarnych stają się 4 znakami ASCII. Cztery trzecie to mniej więcej 1,33 i stąd bierze się liczba +33%. Po doliczeniu bajtu lub dwóch dopełnienia oraz przedrostka data:image/png;base64, narzut jest dla maleńkich plików nieco wyższy. Konkretny przykład: PNG o rozmiarze 9 KB staje się około 12 KB tekstu.
Dlaczego dokładnie 3 do 4? Base64 używa 64-znakowego alfabetu — A–Z, a–z, 0–9 plus + i /. Sześćdziesiąt cztery symbole to 6 bitów informacji na znak. Bajty binarne mają po 8 bitów. Najmniejsza wspólna wielokrotność 6 i 8 to 24 bity, czyli 3 bajty lub 4 znaki Base64, więc koder przemierza obraz po 24 bity naraz. Gdy długość obrazu nie jest czystą wielokrotnością 3, jeden lub dwa znaki = dopełniają ostatnią grupę. Taka jest matematyka i jest niezmienna. Nie istnieje ustawienie kodera, które zmniejszyłoby te 33%.
Te 33% to koszt widoczny. Koszt ukryty polega na tym, że się kumuluje, i tę część większość porad w stylu „po prostu to osadź” pomija:
- Obraz jest pobierany ponownie za każdym razem, gdy zmienia się plik, który go zawiera. Zewnętrzny
logo.pngto osobny zasób. Osadź go wstyles.css, a teraz każda edycja tego arkusza stylów, choćby poprawka koloru czy nowa reguła, unieważnia w pamięci podręcznej także obraz. Odwiedzający pobierają ponownie obrazek, który już mieli. - Nie da się go buforować niezależnie. Zwykły plik obrazu pobiera się raz i wykorzystuje ponownie na każdej stronie i przy każdej wizycie. Osadzone data URI jest częścią dokumentu, więc wędruje znów na każdej stronie, która je zawiera, i przy każdym nietrafieniu tego dokumentu w pamięci podręcznej.
- CSS blokuje renderowanie. Przeglądarka nie zacznie malować, dopóki nie ma CSS. Wepchnij duże data URI do arkusza stylów, a powiększysz zasób blokujący renderowanie, opóźniając pierwsze malowanie całej strony.
Czy gzip albo brotli niweluje te 33%?
Częściowo, nie w pełni. Tekst Base64 jest na tyle powtarzalny, że gzip i brotli kompresują go dobrze, odzyskując sporą część przyrostu na łączu. Pozostają jednak dwie rzeczy. Po pierwsze, skompresowany Base64 jest zazwyczaj wciąż nieco większy niż skompresowany oryginał binarny, bo dostarczyłeś kompresorowi mniej efektywny punkt wyjścia. Po drugie, i to ważniejsze, kompresja nie robi nic z buforowaniem ani blokowaniem renderowania. Mniejsze na łączu data URI nadal pobiera się ponownie wraz z plikiem-gospodarzem i nadal nie da się go buforować samodzielnie.
Innymi słowy, kompresja to nie to samo, co wyeliminowanie kosztu osadzania. Jeśli różnica między minifikacją, gzipem a brotli jest niejasna, przewodnik po minifikacji kodu pokazuje, jak te warstwy się nakładają i dlaczego ściskanie bajtów nigdy nie naprawia problemu buforowania, który tworzy osadzanie.
Kiedy używać obrazu w Base64 (macierz decyzyjna)
Cała decyzja sprowadza się do garstki czynników. Oto one zestawione obok siebie:
| Czynnik | Skłaniaj się ku osadzaniu (Base64) | Skłaniaj się ku zwykłemu plikowi |
|---|---|---|
| Rozmiar | Poniżej ~2 KB (zielony) | Powyżej ~10 KB (czerwony); 2–10 KB to kwestia oceny (bursztynowy) |
| Wielokrotne użycie | Jedna strona, miejsce lub dwa | Powtarzany na wielu stronach |
| Częstość zmian | Prawie nigdy się nie zmienia | Często edytowany |
| Kontekst | E-mail HTML, samodzielny widżet lub bookmarklet, ładunek JSON/API, krytyczna ikona nad linią załamania warta jednego oszczędzonego żądania | Obrazy treści, współdzielone zasoby do buforowania |
Te progi rozmiaru nie są przypadkowe. Odzwierciedlają plakietkę sygnalizacji świetlnej wbudowaną w konwerter obrazu na Base64: zielony poniżej 2 KB, bursztynowy do 10 KB, czerwony powyżej. Narzędzie czyta Twój faktyczny plik i podpowiada, do którego kubełka trafia.
Prosta reguła kciuka
Jeśli masz zapamiętać jedną linijkę, niech to będzie ta: poniżej ~2 KB i używany tylko w jednym lub dwóch miejscach, osadzanie zwykle się opłaca; powyżej ~10 KB lub używany na wielu stronach, niemal zawsze wygrywa zwykły, buforowany plik. Środek 2–10 KB to obszar, gdzie ważysz oszczędzone żądanie wobec utraconego buforowania dla swojej konkretnej sytuacji.
Dobre dopasowania w szczegółach
Kilka przypadków, w których Base64 naprawdę się sprawdza:
- E-mail HTML. Wiele klientów poczty domyślnie blokuje obrazy hostowane zewnętrznie ze względu na prywatność, co psuje każdy układ zależny od zdalnego logo. Małe osadzone data URI renderuje się natychmiast, bez pobierania z serwera. Ogranicz to do logotypów i ikon; nigdy nie osadzaj fotografii w e-mailu.
- Samodzielne widżety i bookmarklety. Bookmarklet lub osadzalny widżet musi działać przy zerowych zewnętrznych zależnościach. Osadzenie jego ikon trzyma wszystko w jednym, gotowym do przeciągnięcia pliku.
- Ładunki JSON i API. Wysłanie miniatury wewnątrz dokumentu JSON lub pliku konfiguracyjnego bywa najczystszą opcją: jedna podróż w obie strony, jeden obiekt, brak drugiego żądania do podłączenia.
- Krytyczna ikona nad linią załamania. Gdy maleńkie logo jest częścią Twojego Largest Contentful Paint, a Ty chcesz ściąć jedno żądanie ze ścieżki krytycznej, osadzanie może pomóc. Nacisk na maleńkie.
Jeden wzorzec łączy te przypadki: w każdym zasób podróżuje razem z czymś innym i inaczej potrzebowałby własnego kanału dostarczania. E-mail nie może polegać na Twoim CDN. Bookmarklet nie ma drugiego pliku do pobrania. Odpowiedź JSON to pojedynczy ładunek. W każdym z nich alternatywą dla osadzania nie jest „buforowany plik”, tylko „brakujący obraz”, co całkowicie zmienia rachunek. Dobre dopasowanie do Base64 poznaje się więc nie tylko po tym, czy plik jest mały, ale po tym, czy osobny plik jest tu w ogóle opcją.
Kiedy NIE osadzać: buforowanie, leniwe ładowanie i Core Web Vitals
Lista powodów przeciw jest dłuższa, bo osadzanie po cichu wyłącza kilka rzeczy, które przeglądarka robi dobrze.
Tracisz niezależne buforowanie. Boli to najbardziej powracających odwiedzających. Zwykły obraz po pierwszej wizycie siedzi w ich pamięci podręcznej i odtąd ładuje się błyskawicznie na zawsze. Osadzony obraz nie ma niezależnego wpisu w pamięci podręcznej. Jedzie wraz z dokumentem za każdym razem, więc powracający odwiedzający płaci za bajty raz za razem.
Tracisz leniwe ładowanie. Atrybut loading="lazy" pozwala przeglądarce odroczyć obrazy poniżej linii załamania, aż użytkownik przewinie w ich pobliże. Data URI jest parsowane i „pobierane” w chwili odczytania HTML, więc nie ma czego odraczać. Osadź tuzin obrazów spod linii załamania, a wymusisz wczytanie ich wszystkich już na starcie.
Powiększasz zasoby blokujące renderowanie. Jak wspomniano wcześniej, data URI wewnątrz CSS rozdyma zasób, który blokuje pierwsze malowanie. Im większy arkusz stylów, tym dłużej strona pozostaje pusta.
Dekodowanie kosztuje więcej na telefonie. Data URI jest dekodowany z Base64 przy każdym wczytaniu dokumentu, a na słabszych telefonach ta praca CPU się kumuluje; co gorsza, bajty nigdy nie trafiają do pamięci podręcznej dysku przeglądarki, więc ciężki osadzony obraz jest dekodowany ponownie przy każdej wizycie, zamiast raz zostać zbuforowanym i zdekodowanym jak zwykły plik.
Jest też historyczny powód, dla którego ta porada się zmieniła. Pierwotny argument za osadzaniem, popularny w erze HTTP/1.1, dotyczył redukcji żądań: każde połączenie mogło pobierać jeden zasób naraz, więc strona z 40 małymi ikonami płaciła 40 podróżami w obie strony. HTTP/2 to zmieniło, multipleksując wiele żądań w jednym połączeniu, przez co dodatkowe małe pliki stały się tanie. Główny zysk z osadzania, czyli mniej żądań, w większości zniknął, a koszty (utracone buforowanie, brak leniwego ładowania, większe pliki blokujące renderowanie) zostały. Starsze artykuły zachwalające sprite’y w Base64 warto czytać z poprawką na protokół, na którym witryna faktycznie dziś działa.
Aspekt Core Web Vitals
Przy LCP (Largest Contentful Paint) osadzanie potrafi zadziałać w obie strony. Dla małego obrazu nad linią załamania, który jest elementem LCP, usunięcie żądania może przesunąć LCP wcześniej. Ale osadź duży obraz, a zrobisz coś przeciwnego: opóźnisz dokument lub arkusz stylów, w którym się znajduje, i przesuniesz LCP całej strony później. O tym, w którą stronę to pójdzie, rozstrzyga próg rozmiaru.
Przy CLS (Cumulative Layout Shift) osadzanie nie zmienia nic w kluczowej regule: obraz nadal potrzebuje jawnej width i height (albo ramki o ustalonym aspect-ratio), aby przeglądarka mogła zarezerwować miejsce, zanim go wyrenderuje. Data URI bez wymiarów przesuwa układ dokładnie tak samo jak zdalny obraz bez wymiarów.
Lepszym sposobem niż osadzanie jest zwykle zmniejszenie źródła. Skompresowanie obrazu przed zakodowaniem czyni mniejszym i sam plik, i wynikowe data URI. Przewodnik po kompresji obrazów w przeglądarce kontra Node omawia, jak zrobić to po stronie klienta albo w kroku budowania, a WebP kontra AVIF kontra JPEG pomaga wybrać format, który od początku jest mały.
Jak osadzać obrazy w HTML, CSS, Markdown i JSON
Gdy masz już data URI, oto jak wpada do każdego kontekstu. To cztery gotowe do wklejenia fragmenty, które generuje dla Ciebie konwerter obrazu na Base64.
HTML — wklej URI do dowolnego src:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">CSS — owiń je w url() dla background-image (to kanoniczny wzorzec base64 image in CSS):
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}Markdown — samodzielny odnośnik do obrazu dla plików README, zgłoszeń na GitHubie i notatników, gdzie nie da się hostować pliku:
JSON — osadzony zasób wewnątrz ładunku API lub konfiguracji:
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }Wszystkie cztery działają wszędzie tam, gdzie akceptowany jest URL: img src, CSS background, mask-image, a nawet favikona w <link>. Każda nowoczesna przeglądarka obsługuje schemat data:.
Szybkie generowanie
Budowanie tego ręcznie jest podatne na błędy: jeden zły MIME albo zabłąkany podział wiersza i obraz po cichu się nie renderuje. Wrzuć plik do konwertera obrazu na Base64, a wytworzy wszystkie cztery fragmenty z osobnymi przyciskami kopiowania, plus dokładny przyrost rozmiaru, byś z góry wiedział, czy zasób w ogóle pasuje do osadzenia.
SVG: szczególny przypadek, w którym Base64 zwykle przegrywa
SVG wymyka się zwykłej logice, bo SVG to tekst, nie dane binarne. Base64 istnieje po to, by uczynić dane binarne bezpiecznymi w tekście, a SVG jest już tekstem XML. Zakodowanie go jako Base64 jedynie rozdyma ciąg, który nie potrzebował kodowania, i przy okazji czyni go nieczytelnym. Dlatego konkretnie dla SVG Base64 jest niemal zawsze złym wyborem.
Porównaj trzy sposoby osadzenia tej samej ikony:
/* 1. Base64 data URI — dodaje podatek 33% do tekstu, który go nie potrzebował */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. URL-encoded data URI — percent-encode a handful of characters, no 33% tax */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. Inline <svg> directly in the HTML — fully styleable with 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>Opcja 2 (kodowanie URL) jest zwykle mniejsza niż opcja 1, pozostaje czytelna dla człowieka i lepiej się kompresuje. Kodujesz procentowo tylko te znaki, które zepsułyby URI, czyli <, >, # i cudzysłowy, a resztę zostawiasz czytelną. Podejście kodera/dekodera URL jest udokumentowane w samym narzędziu; po Base64 dla SVG sięgaj tylko wtedy, gdy potok budowania wyraźnie tego wymaga.
Dlaczego osadzone <svg> często bije ikonę PNG w Base64
Jeśli wybierasz między ikoną PNG zakodowaną w Base64 a osadzonym <svg>, SVG zwykle wygrywa na każdej osi. Skaluje się do dowolnego rozmiaru bez rozmycia, nie niesie podatku 33%, a w przeciwieństwie do dowolnego data URI możesz go stylizować w CSS, animować i przebarwiać przez currentColor. PNG w Base64 to blob o stałej rozdzielczości, którego po zakodowaniu nie tkniesz. Rastrowy Base64 zostaw na przypadki, gdy naprawdę potrzebujesz osadzonej fotografii lub rastrowego zrzutu ekranu.
Dekodowanie w drugą stronę: z Base64 z powrotem do obrazu
Problem odwrotny jest równie częsty: masz ciąg Base64 wyciągnięty z odpowiedzi API, linii logu, kolumny bazy danych albo z debugowanego arkusza stylów i musisz zobaczyć faktyczny obrazek.
Dwa szczegóły bywają tu kłopotliwe. Po pierwsze, surowy Base64 kontra pełne data URI. Kompletne data URI (data:image/png;base64,…) niesie własny MIME; goły ładunek (iVBORw0KGgo…) nie. By wyrenderować goły ładunek, albo dopisujesz na początku poprawny przedrostek data:, albo pozwalasz narzędziu wywnioskować format z początkowych bajtów: iVBORw0KGgo oznacza PNG, /9j/ oznacza JPEG, R0lGOD oznacza GIF.
Po drugie, zawijanie wierszy. Base64 z e-maili lub starszych narzędzi bywa zawijany co 76 znaków zgodnie z RFC 2045. Te znaki nowej linii trzeba usunąć przed dekodowaniem, bo inaczej ciąg jest nieprawidłowy w atrybucie HTML albo w url().
W przeglądarce możesz podać kompletne data URI wprost do <img>:
<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">Na serwerze Node odtwarza plik z ładunku:
import { writeFileSync } from "node:fs";
const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // raw payload, no data: prefix
writeFileSync("output.png", Buffer.from(b64, "base64"));Po ścieżkę bez kodowania sięgnij do konwertera Base64 na obraz: wklejasz ciąg (z przedrostkiem lub bez, ze wszystkimi podziałami wierszy), podglądasz go, odczytujesz jego wymiary i MIME oraz pobierasz prawdziwy plik PNG, JPG, GIF lub SVG. Narzędzie usuwa białe znaki, toleruje brak przedrostka i automatycznie wykrywa format z magicznych bajtów.
Jedno sprawdzenie warto wykonać na zdekodowanym obrazie: spójrz na jego zgłoszone wymiary. Jeśli wyciągnąłeś jeden ciąg z pliku, który zawierał ich kilka, a wynik to 1×1, prawdopodobnie złapałeś piksel śledzący zamiast zasobu, którego chciałeś. Warto też pamiętać, że dekodowanie jest czysto mechaniczne i bezstratne: PNG w Base64 wraca jako dokładnie ten sam PNG, bajt w bajt, bez ponownej kompresji. Po drodze zmienia się tylko pojemnik, czyli ciąg tekstowy w jedną stronę i plik binarny z powrotem.
FAQ
Czy powinienem konwertować moje obrazy na Base64?
Tylko gdy to się opłaca: małe (poniżej ~2 KB), rzadko zmieniające się ikony lub logotypy, gdzie pominięcie jednego żądania HTTP ma znaczenie, plus e-mail HTML, samodzielne widżety i ładunki JSON. Duże obrazy albo cokolwiek używanego wielokrotnie na wielu stronach powinno niemal zawsze pozostać zwykłymi plikami, żeby zachować buforowanie i leniwe ładowanie.
O ile Base64 powiększa obraz?
O około +33%. Base64 koduje każde 3 bajty danych binarnych jako 4 znaki ASCII, plus odrobina dopełnienia i przedrostek data:. PNG o rozmiarze 9 KB staje się mniej więcej 12 KB tekstu. Aby skonwertować obraz na Base64 i zobaczyć dokładny przyrost dla swojego pliku, narzędzie podaje precyzyjną liczbę na pasku metadanych.
Czy Base64 sprawia, że obrazy ładują się szybciej?
Dla bardzo małej ikony nad linią załamania może, oszczędzając podróż w obie strony jednego żądania. Dla większych lub wielokrotnie używanych obrazów jest zwykle wolniej: tracisz niezależne buforowanie, nie możesz go leniwie załadować, a osadzenie go w CSS powiększa zasób blokujący renderowanie. Rozmiar jest czynnikiem rozstrzygającym.
Czy mogę użyć obrazu w Base64 w CSS?
Tak: background-image: url("data:image/png;base64,…"). Dla drobnych ikon jest w porządku. Pamiętaj tylko, że data URI staje się częścią arkusza stylów, więc cały plik pobiera się ponownie, ilekroć zmienia się CSS, a obrazu nie da się buforować osobno od niego.
Powinienem użyć SVG czy Base64 dla ikon?
Preferuj osadzone <svg> albo data URI z SVG zakodowanym w URL. SVG to tekst, skaluje się czysto i nie niesie podatku 33%, więc zwykle jest mniejszy niż PNG w Base64, a możesz go stylizować w CSS. Po Base64 sięgaj tylko wtedy, gdy konkretnie potrzebujesz ikony rastrowej.
Jak przekonwertować ciąg Base64 z powrotem na obraz?
W przeglądarce wrzuć pełne URI data:image/…;base64,… do <img src>. Na serwerze użyj Buffer.from(b64, "base64"), aby zapisać plik. Goły ładunek wymaga dodania przedrostka data:, a ciągi zawijane wierszami wymagają najpierw usunięcia znaków nowej linii. Narzędzie Base64 na obraz obsługuje to wszystko i pozwala pobrać wynik.