Bir görseli Base64’e dönüştürdüğünüzde bir data URI elde edersiniz. Bu, data:image/png;base64,iVBORw0KGgo… gibi bir karakter dizisidir ve onu doğrudan bir HTML src veya CSS url() içine yapıştırabilirsiniz. Tarayıcı bunu anında çözer ve resmi ayrı bir indirme olmadan gösterir. Barındırılacak dosya, ekstra istek olmaz.
Peki bunu yapmalı mısınız? Kısa kural şu: bir görseli Base64 olarak yalnızca küçükse (yaklaşık 2 KB altı), nadiren değişiyorsa ve bir HTTP isteğini atlamak istiyorsanız gömün. Minik simgeleri ve logoları düşünün. Geri kalan her şeyi, yani büyük görselleri, sayfalar arasında yeniden kullanılan ya da tarayıcının önbelleğe almasını istediğiniz şeyleri, normal görsel dosyası olarak tutun. Dikkat edilmesi gereken nokta şu: Base64 bir dosyayı yaklaşık %33 büyütür ve bu metin HTML veya CSS’inize gömüldüğünde artık kendi başına önbelleğe alınamaz.
Belirli bir dosya için kesin sayıları istiyorsanız, Görseli Base64’e dönüştürücü kodlamayı tarayıcınızda yapar ve tam boyut artışını gösterir; böylece bir yaklaşık kural yerine gerçek verilerle karar verebilirsiniz. Bu rehber, o data URI’nin gerçekte ne olduğunu, boyut vergisinin arkasındaki matematiği, gömmenin ne zaman değdiğine dair bir karar matrisini ve düz bir dosyanın kazandığı durumları sırayla ele alır.
”Görseli Base64’e” aslında ne üretir: data URI
Bir görseli Base64’e dönüştürmek size bir dosya vermez. Size RFC 2397’de tanımlanan data URI biçimini izleyen tek bir uzun karakter dizisi verir (MDN’in data: URL referansına bakın). Bu dizinin üç parçası vardır:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
└──┬─┘ └───┬───┘ └─┬──┘ └─────────┬──────────┘
data: MIME type marker the encoded image bytesMIME türü, tarayıcıya hangi tür görseli çözdüğünü söyler. Görseller için yaygın olanlar image/png, image/jpeg, image/gif, image/webp, image/svg+xml ve favicon’lar için image/x-icon’dur. ;base64, işareti, ardından gelen yükün düz metin değil Base64 olduğunu belirtir. Virgülden sonraki her şey, yazdırılabilir ASCII olarak yeniden ifade edilmiş görseldir.
O son parça gizlilik açısından önemlidir. Dönüştürme tamamen tarayıcınızda FileReader API’sinin readAsDataURL yöntemiyle çalışır; hiçbir şey bir sunucuya yüklenmez. Lansman öncesi bir ekran görüntüsünü, dahili bir diyagramı veya yayımlanmamış bir görseli araca bırakıp Network sekmesinin boş kaldığını izleyebilirsiniz. Ham baytların o ASCII dizisine nasıl dönüştüğünün temel mekaniği için Base64’ü anlamak kodlamayı en baştan ele alır; eksiksiz Base64 rehberi ise aynı data-URL fikrini fontlara, PDF’lere ve diğer dosya türlerine genişletir.
Gerçek bir örnek: 68 baytlık şeffaf bir PNG
İşte en küçük pratik durum: 1×1 şeffaf bir PNG, diskte 68 bayt, eksiksiz bir data URI olarak:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mNk+M9QDwADhgGAWjR9awAAAABJRU5ErkJggg==Bunu bir tarayıcının adres çubuğuna yapıştırın; sıfır ağ etkinliğiyle geçerli bir görselin oluştuğunu göreceksiniz (daha doğrusu görmeyeceksiniz, çünkü şeffaf). Sondaki == kısmına dikkat edin: bu, birazdan değineceğimiz dolgudur. Metin Base64’ü de tam olarak böyle görünür, yalnızca metin yerine görsel baytlarına uygulanmıştır. Yalnızca düz metin dizilerini kodlamanız veya çözmeniz gerekiyorsa, Base64 kodla/çöz aracı bu durumu halleder.
%33 boyut vergisi (ve neden katlanarak büyür)
Base64 sabit gruplar halinde çalışır: her 3 bayt ikili veri, 4 ASCII karakteri olur. Dörtte üç kabaca 1,33’tür; +%33 rakamı buradan gelir. Bir iki bayt dolgu ve data:image/png;base64, ön ekini de ekleyin; küçük dosyalar için fazlalık biraz daha yüksektir. Somut bir örnek: 9 KB’lik bir PNG yaklaşık 12 KB metin olur.
Neden tam olarak 3’e 4? Base64, 64 karakterlik bir alfabe kullanır: A–Z, a–z, 0–9, artı + ve /. Altmış dört sembol, karakter başına 6 bit bilgi demektir. İkili baytların her biri 8 bittir. 6 ile 8’in en küçük ortak katı 24 bittir; bu da 3 bayt ya da 4 Base64 karakteridir, yani kodlayıcı görselde 24 bit aralıklarla ilerler. Görsel uzunluğu 3’ün temiz bir katı olmadığında, son grubu bir veya iki = karakteri doldurur. Matematik budur ve sabittir; %33’ü küçülten bir kodlayıcı ayarı yoktur.
Bu, görünen maliyettir. Gizli maliyet ise katlanarak büyümesidir ve çoğu “sadece göm gitsin” tavsiyesinin atladığı kısım budur:
- Görsel, onu içeren dosya her değiştiğinde yeniden indirilir. Harici bir
logo.pngkendi kaynağıdır. Onustyles.cssiçine gömerseniz, o stil sayfasındaki her düzenleme (bir renk değişikliği, yeni bir kural) görselin önbelleğini de geçersiz kılar. Ziyaretçiler, zaten ellerinde olan resmi yeniden indirir. - Bağımsız olarak önbelleğe alınamaz. Normal bir görsel dosyası bir kez getirilir ve her sayfada, her ziyarette yeniden kullanılır. Gömülü bir data URI ise belgenin parçasıdır; bu yüzden onu gömen her sayfada ve o belgenin her önbellek ıskasında yeniden gönderilir.
- CSS oluşturmayı engeller. Tarayıcı, CSS elinde olana kadar boyamaz. Bir stil sayfasının içine büyük bir data URI tıkıştırırsanız, oluşturmayı engelleyen bir kaynağı büyütmüş olursunuz; bu da tüm sayfanın ilk boyamasını geciktirir.
gzip veya brotli %33’ü iptal eder mi?
Kısmen, ama tamamen değil. Base64 metni, gzip ve brotli’nin iyi sıkıştıracağı kadar tekrarlıdır ve şişkinliğin iyi bir kısmını hat üzerinde geri kazandırır. Yine de iki şey doğru kalır. Birincisi, sıkıştırılmış Base64 genellikle sıkıştırılmış orijinal ikiliden hâlâ biraz daha büyüktür, çünkü sıkıştırıcıya daha az verimli bir başlangıç noktası vermişsinizdir. İkincisi, ki daha önemli nokta budur, sıkıştırma; önbellekleme veya oluşturma engelleme konusunda hiçbir şey yapmaz. Hat üzerinde daha küçük bir data URI yine ana dosyasıyla birlikte yeniden indirilir ve yine kendi başına önbelleğe alınamaz.
Başka bir deyişle, sıkıştırma gömme maliyetini ortadan kaldırmaz. Küçültme, gzip’leme ve brotli arasındaki ayrım bulanıksa, kod küçültme rehberi bu katmanların nasıl üst üste bindiğini açıklar ve baytları sıkıştırmanın gömmenin yarattığı önbellek sorununu neden çözmediğini gösterir.
Bir Base64 görseli ne zaman kullanmalı (karar matrisi)
Tüm karar bir avuç faktöre iner:
| Faktör | Gömmeye eğilim (Base64) | Normal dosyaya eğilim |
|---|---|---|
| Boyut | ~2 KB altı (yeşil) | ~10 KB üstü (kırmızı); 2–10 KB bir takdir meselesidir (sarı) |
| Yeniden kullanım | Tek sayfa, bir iki yer | Birçok sayfada tekrar eder |
| Değişim sıklığı | Neredeyse hiç değişmez | Sık düzenlenir |
| Bağlam | HTML e-postası, kendine yeten widget veya bookmarklet, JSON/API yükü, kaydedilen bir isteğe değecek kritik bir üst-kıvrım simgesi | İçerik görselleri, paylaşılan önbelleklenebilir varlıklar |
Bu boyut eşikleri keyfi değildir; Görseli Base64’e dönüştürücü içine yerleştirilmiş trafik ışığı rozetini yansıtırlar: 2 KB altı yeşil, 10 KB’ye kadar sarı, üstü kırmızı. Araç gerçek dosyanızı okur ve hangi kovaya düştüğünü söyler.
Basit bir yaklaşık kural
Tek bir satır hatırlayacaksanız, bu olsun: ~2 KB altıysa ve yalnızca bir iki yerde kullanılıyorsa, gömme genellikle değer; ~10 KB üstüyse veya sayfalar arasında yeniden kullanılıyorsa, normal önbelleklenmiş bir dosya neredeyse her zaman kazanır. 2–10 KB orta aralığı, kaydedilen isteği kendi özel durumunuz için kaybedilen önbelleğe karşı tarttığınız yerdir.
Ayrıntılı olarak iyi uyan durumlar
Base64’ün gerçekten ekmeğini çıkardığı birkaç durum:
- HTML e-postası. Birçok e-posta istemcisi gizlilik için harici barındırılan görselleri varsayılan olarak engeller; bu da uzak bir logoya bağımlı her düzeni bozar. Küçük, gömülü bir data URI sunucu getirmesi olmadan anında oluşur. Bunları logolarla ve simgelerle sınırlayın; bir e-postaya asla bir fotoğraf gömmeyin.
- Kendine yeten widget’lar ve bookmarklet’ler. Bir bookmarklet veya gömülebilir bir widget, sıfır harici bağımlılıkla çalışmak zorundadır. Simgelerini gömmek her şeyi tek bir sürüklenebilir dosyada tutar.
- JSON ve API yükleri. Bir küçük resmi bir JSON belgesinin veya bir yapılandırma dosyasının içine göndermek bazen en temiz seçenektir; tek bir gidiş dönüş ve tek bir nesneyle iş biter, ayrıca bağlanacak ikinci bir istek kalmaz.
- Kritik bir üst-kıvrım simgesi. Minik bir logo Largest Contentful Paint’inizin parçasıyken ve kritik yoldan bir isteği kısmak istediğinizde, gömme yardımcı olabilir. Vurgu minik üzerinde.
Bu durumların hepsinde aynı desen var: varlık başka bir şeyle birlikte yolculuk ediyor ve aksi takdirde kendi teslim kanalına ihtiyaç duyardı. Bir e-posta CDN’inize güvenemez. Bir bookmarklet’in getirilecek ikinci bir dosyası yoktur. Bir JSON yanıtı tek bir yüktür. Her birinde gömmenin alternatifi önbelleklenmiş bir dosya değil, eksik bir görseldir; bu da hesabı tamamen değiştirir. İyi bir Base64 uyumunun gerçek ölçütü de budur: yalnızca “küçük mü” değil, “burada ayrı bir dosya bir seçenek bile mi”.
Ne zaman gömmemeli: önbellekleme, geç yükleme ve Core Web Vitals
Madalyonun diğer yüzü daha uzundur, çünkü gömme tarayıcının iyi yaptığı birkaç şeyi sessizce devre dışı bırakır.
Bağımsız önbelleklemeyi kaybedersiniz. Bu en çok geri dönen ziyaretçileri vurur. Normal bir görsel ilk ziyaretten sonra önbelleklerinde durur ve sonsuza dek anında yüklenir. Gömülü bir görselin bağımsız bir önbellek girişi yoktur; her seferinde belgeyle birlikte gider, böylece tekrar gelen bir ziyaretçi bayt maliyetini tekrar tekrar öder.
Geç yüklemeyi kaybedersiniz. loading="lazy" özniteliği, tarayıcının kıvrımın altındaki görselleri kullanıcı yakına kaydırana kadar ertelemesini sağlar. Bir data URI, HTML okunduğu anda ayrıştırılır ve “indirilir”, bu yüzden ertelenecek bir şey yoktur. Kıvrımın altındaki bir düzine görseli gömün; hepsini ilk yüklemeye zorlamış olursunuz.
Oluşturmayı engelleyen kaynakları büyütürsünüz. Daha önce belirtildiği gibi, CSS içindeki bir data URI, ilk boyamayı engelleyen bir kaynağı şişirir. O stil sayfası ne kadar büyükse, sayfa o kadar uzun süre boş kalır.
Mobilde çözme daha maliyetlidir. Bir data URI, belgesi her yüklendiğinde Base64’ten çözülür ve düşük donanımlı telefonlarda bu CPU işi birikir. Dahası, baytlar tarayıcının disk önbelleğine hiç girmez; bu yüzden ağır bir gömülü görsel, normal bir dosya gibi bir kez önbelleğe alınıp çözülmek yerine her ziyarette yeniden çözülür.
Bu tavsiyenin değişmesinin tarihsel bir nedeni de var. Gömmenin HTTP/1.1 döneminde yüksek sesle savunulan orijinal gerekçesi istek azaltmaydı: her bağlantı aynı anda tek bir kaynak getirebiliyordu, dolayısıyla 40 küçük simgeli bir sayfa 40 gidiş dönüş ödüyordu. HTTP/2 bunu, birçok isteği tek bir bağlantı üzerinden çoğullayarak değiştirdi; bu da ekstra küçük dosyaları ucuzlattı. Gömmenin büyük kazancı, yani daha az istek, büyük ölçüde buharlaştı; maliyetler ise (kaybedilen önbellekleme, geç yükleme yokluğu, daha büyük oluşturma engelleyen dosyalar) kaldı. Base64 sprite’ları hakkında hevesli eski makaleler okursanız, bunları sitenizin bugün gerçekte çalıştırdığı protokole karşı tartın.
Core Web Vitals açısı
Gömme, LCP (Largest Contentful Paint) üzerinde iki yönlü keser. LCP öğesi olan küçük, üst-kıvrım bir görsel için bir isteği kaldırmak LCP’yi öne çekebilir. Ama büyük bir görseli gömün, tersini yaparsınız: içinde yaşadığı belgeyi veya stil sayfasını geciktirir, tüm sayfa için LCP’yi sonraya iter. Hangi yöne gideceğine boyut eşiği karar verir.
CLS (Cumulative Layout Shift) için gömme, temel kural hakkında hiçbir şeyi değiştirmez: bir görsel hâlâ açık bir width ve height (veya bir en-boy oranı kutusu) ister ki tarayıcı oluşturmadan önce yer ayırabilsin. Boyutları olmayan bir data URI, boyutları olmayan uzak bir görselin tam olarak yaptığı gibi düzeni kaydırır.
Gömmeden daha iyi bir kaldıraç genellikle kaynağı küçültmektir. Bir görseli kodlamadan önce sıkıştırmak hem dosyayı hem de ortaya çıkan data URI’yi küçültür. Tarayıcı ve Node görsel sıkıştırma rehberi bunun istemci tarafında veya bir derleme adımında nasıl yapılacağını ele alır; WebP, AVIF ve JPEG karşılaştırması ise baştan küçük olan bir format seçmenize yardımcı olur.
HTML, CSS, Markdown ve JSON’da görseller nasıl gömülür
Bir data URI’niz olduğunda, her bağlama nasıl yerleştiği aşağıda. Bunlar, Görseli Base64’e dönüştürücünün sizin için ürettiği yapıştırmaya hazır dört parçacıktır.
HTML: URI’yi herhangi bir src içine yapıştırın:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…" alt="logo">CSS: bir background-image için onu url() içine sarın (bu, kanonik CSS’te base64 görseli desenidir):
.icon {
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…");
}Markdown: bir dosya barındıramayacağınız README’ler, GitHub issue’ları ve not defterleri için kendine yeten bir görsel bağlantısı:
JSON: bir API veya yapılandırma yükünün içindeki gömülü bir varlık:
{ "icon": "data:image/png;base64,iVBORw0KGgo…" }Dördü de bir URL’nin kabul edildiği her yerde çalışır: img src, CSS background, mask-image, hatta bir favicon <link>. Her modern tarayıcı data: şemasını destekler.
Bunları hızlıca üretmek
Bunları elle oluşturmak hataya açıktır: yanlış bir MIME türü veya başıboş bir satır sonu, görselin sessizce oluşmamasına yeter. Dosyanızı Görseli Base64’e dönüştürücüye bırakın; dördünü de kendi kopyalama düğmeleriyle üretir, ayrıca tam boyut artışını verir, böylece varlığın gömülü olmaya değip değmeyeceğini baştan bilirsiniz.
SVG: Base64’ün genellikle kaybettiği özel durum
SVG olağan mantığı bozar, çünkü SVG metindir, ikili değil. Base64, ikili veriyi metin açısından güvenli hale getirmek için vardır; oysa SVG zaten XML metnidir. Onu Base64 olarak kodlamak, kodlanmaya ihtiyacı olmayan bir dizeyi şişirir ve bu süreçte onu okunamaz hale getirir. Dolayısıyla özellikle SVG için Base64 neredeyse her zaman yanlış seçimdir.
Aynı simgeyi gömmenin üç yolunu karşılaştırın:
/* 1. Base64 data URI'si — gerek olmayan metne %33 vergi ekler */
.a { background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucz0i…"); }
/* 2. URL ile kodlanmış data URI'si — bir avuç karakteri yüzde ile kodla, %33 vergi yok */
.b { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…%3C/svg%3E"); }
/* 3. HTML'de doğrudan satır içi <svg> — CSS ile tamamen biçimlendirilebilir */<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>Seçenek 2 (URL kodlama) genellikle seçenek 1’den daha küçüktür, insan tarafından okunabilir kalır ve daha iyi sıkışır. Yalnızca URI’yi bozacak karakterleri (<, >, # ve tırnaklar) yüzde ile kodlar, geri kalanı okunaklı bırakırsınız. URL kodlayıcı/çözücü yaklaşımı aracın kendi içinde belgelenmiştir; Base64 SVG’ye yalnızca bir derleme hattı özellikle bunu talep ettiğinde başvurun.
Satır içi bir <svg> neden çoğu zaman bir Base64 PNG simgesini yener
Base64 ile kodlanmış bir PNG simgesi ile satır içi bir <svg> arasında seçim yapıyorsanız, SVG genellikle her eksende kazanır. Herhangi bir boyuta bulanıklaşmadan ölçeklenir, %33 vergi taşımaz ve herhangi bir data URI’nin aksine onu CSS ile biçimlendirebilir, canlandırabilir ve currentColor ile yeniden renklendirebilirsiniz. Bir Base64 PNG ise kodlandıktan sonra dokunamadığınız sabit çözünürlüklü bir blob’dur. Raster Base64’ü, gerçekten satır içi bir fotoğrafa veya raster ekran görüntüsüne ihtiyaç duyduğunuz durumlar için saklayın.
Diğer yöne çözme: Base64’ten görsele geri
Ters problem en az onun kadar yaygındır: elinizde bir API yanıtından, bir günlük satırından, bir veritabanı sütunundan veya hata ayıkladığınız bir stil sayfasından çekilmiş bir Base64 diziniz var ve gerçek resmi görmeniz gerekiyor.
İki ayrıntı insanları yanıltır. Birincisi, ham Base64 ile tam bir data URI arasındaki fark. Eksiksiz bir data URI (data:image/png;base64,…) kendi MIME türünü taşır; çıplak bir yük (iVBORw0KGgo…) taşımaz. Çıplak bir yükü oluşturmak için ya doğru bir data: ön eki eklersiniz ya da bir aracın baştaki baytlardan formatı çıkarmasına izin verirsiniz: iVBORw0KGgo PNG demektir, /9j/ JPEG demektir, R0lGOD GIF demektir.
İkincisi, satır kaydırma. E-postadan veya eski araçlardan gelen Base64, RFC 2045’e göre genellikle satır başına 76 karakterde kaydırılır. Bu satır sonları çözmeden önce çıkarılmalıdır, yoksa dize bir HTML özniteliğinde veya url() içinde geçersiz olur.
Tarayıcıda eksiksiz bir data URI’yi doğrudan bir <img> öğesine verebilirsiniz:
<img src="data:image/png;base64,iVBORw0KGgo…" alt="decoded">Sunucuda Node, dosyayı yükten yeniden oluşturur:
import { writeFileSync } from "node:fs";
const b64 = "iVBORw0KGgoAAAANSUhEUgAA…"; // raw payload, no data: prefix
writeFileSync("output.png", Buffer.from(b64, "base64"));Kodsuz bir yol istiyorsanız Base64’ten görsele dönüştürücüyü kullanın: bir dizeyi yapıştırın (ön ekle veya onsuz, satır sonlarıyla birlikte), önizleyin, boyutlarını ve MIME türünü okuyun, sonra gerçek bir PNG, JPG, GIF veya SVG indirin. Araç boşlukları kırpar, eksik bir ön eki tolere eder ve formatı sihirli baytlardan otomatik olarak algılar.
Çözülmüş bir görselde yapmaya değer bir kontrol var: bildirilen boyutlarına bakın. Bir dizeyi birkaç tane içeren bir dosyadan çektiyseniz ve sonuç 1×1 ise, muhtemelen istediğiniz varlık yerine bir izleme pikseli kapmışsınızdır. Şunu da unutmayın: çözme tamamen mekanik ve kayıpsızdır; bir Base64 PNG, bayt bayt, yeniden sıkıştırma olmadan aynı PNG olarak geri döner. Yol boyunca değişen tek şey kap olur: çıkışta bir metin dizisi, dönüşte bir ikili dosya.
SSS
Görsellerimi Base64’e dönüştürmeli miyim?
Yalnızca değdiğinde: bir HTTP isteğini atlamanın önemli olduğu küçük (~2 KB altı), nadiren değişen simgeler veya logolar, artı HTML e-postası, kendine yeten widget’lar ve JSON yükleri. Büyük görseller veya sayfalar arasında yeniden kullanılan herhangi bir şey neredeyse her zaman normal dosya olarak kalmalı, böylece önbellekleme ve geç yüklemeyi korursunuz.
Base64 bir görseli ne kadar büyütür?
Yaklaşık +%33. Base64, her 3 bayt ikiliyi 4 ASCII karakteri olarak kodlar; üstüne biraz dolgu ve data: ön eki gelir. 9 KB’lik bir PNG kabaca 12 KB metin olur. Bir görseli Base64’e dönüştürdüğünüzde araç, dosyanız için kesin artışı meta verisi çubuğunda bildirir.
Base64 görsellerin daha hızlı yüklenmesini sağlar mı?
Çok küçük bir üst-kıvrım simgesi için sağlayabilir, bir isteğin gidiş dönüşünü kaydederek. Daha büyük veya yeniden kullanılan görseller için genellikle daha yavaştır: bağımsız önbelleğe almayı kaybedersiniz, onu geç yükleyemezsiniz ve CSS’e gömmek oluşturmayı engelleyen bir kaynağı büyütür. Boyut belirleyici faktördür.
CSS’te bir Base64 görseli kullanabilir miyim?
Evet: background-image: url("data:image/png;base64,…"). Minik simgeler için sorunsuzdur. Yalnızca şunu unutmayın: data URI stil sayfasının parçası olur, bu yüzden CSS her değiştiğinde tüm dosya yeniden indirilir ve görsel ondan ayrı önbelleğe alınamaz.
Simgeler için SVG mi yoksa Base64 mi kullanmalıyım?
Satır içi bir <svg> veya URL ile kodlanmış bir SVG data URI’sini tercih edin. SVG metindir, temiz ölçeklenir ve %33 vergi taşımaz, bu yüzden genellikle bir Base64 PNG’den daha küçüktür ve onu CSS ile biçimlendirebilirsiniz. Base64’e yalnızca özellikle bir raster simgeye ihtiyacınız olduğunda başvurun.
Bir Base64 dizesini tekrar görsele nasıl dönüştürürüm?
Tarayıcıda, tam bir data:image/…;base64,… URI’sini bir <img src> içine bırakın. Bir sunucuda, dosyayı yazmak için Buffer.from(b64, "base64") kullanın. Ham bir yükün eklenmiş bir data: ön ekine ihtiyacı vardır ve satır kaydırmalı dizelerin önce satır sonlarının çıkarılması gerekir. Base64’ten görsele aracı bunların tümünü halleder ve sonucu indirmenize izin verir.