PNG → WEBP dönüştürücü

PNG’den WEBP’ye geçiş, modern webin en temiz format takaslarından biri. PNG’yi JPEG’e çevirirken saydamlık kayboluyor ve bir zemin seçmek zorunda kalıyorsun; WEBP’ye geçişte böyle bir karar yok, çünkü WEBP tam alfa kanalı taşıyor — saydam bir PNG, hiçbir şey kaybetmeden saydam bir WEBP olarak çıkıyor. Boyut kazancı haliyle başlığa çıkıyor; arayüz öğeleri, ikonlar ve illüstrasyonlar genellikle yüzde 30 ila 50 daha hafif geliyor, PNG’nin sıkıştırmakta özellikle zorlandığı dosyalarda bu fark daha da açılıyor. Daha ilgi çekici nokta ise, ilk başta PNG’ye uzanmana yol açan keskinliği bırakmadan tüm bu kazancı elde edebilmen. Kayıpsız WEBP modu kaynaktaki her pikseli aynen koruyor.

İşin asıl ilginçleştiği yer, kayıpsız mı kayıplı mı sorusu. Kayıpsız WEBP; tek bir kenarın yumuşamasıyla bile kötü hissedeceğin her şey için doğru tercih: uygulama ikonları, UI sprite’ları, logolar, içinde metin geçen ekran görüntüleri, grafikler, line‑art ve pixel‑art. Çıktı, kaynağın byte‑bayt korunmuş hâli; sadece PNG’ye göre çok daha verimli depolanıyor. Kayıplı WEBP ise dosya boyutunun keskin kenarlardan değil yumuşak geçişlerden domine edildiği saydam illüstrasyonlar ve alfalı fotoğrafımsı görseller için doğru seçenek. Kayıplı 85–90 aralığında görsel fark pratikte yok denecek kadar az, ama dosya boyutu kayıpsızın indirebileceğinin epey altına iniyor.

Bazı PNG dosyaları aslında yanlış formata düşmüş fotoğraflar. Ürün fotoğrafının arkasındaki saydam gölge, fotoğraf ağırlıklı bir sayfanın ekran görüntüsü, hafif bir vignette ile kaydedilmiş bir film karesi — bunlar PNG olarak devasa, çünkü PNG’nin sıkıştırması bu tip içeriğe pek bir şey sunamıyor; aynı dosyalar kayıplı WEBP olarak çarpıcı şekilde küçülüyor. Pratik kural çoğu zaman tutuyor: PNG bir megabaytın üzerindeyse ve görünür içerik ağırlıklı olarak fotoğrafsa, kalite 85’te kayıplı WEBP, normal bir ekranda kimsenin fark etmeyeceği bir şekilde dosyayı küçültüyor.

Alfa davranışı ayrı bir başlık hak ediyor; çünkü çıktıyla ilgili kafanın en çok karıştığı yer burası. WEBP saydamlığı hem kayıpsız hem kayıplı modda koruyor; ama kayıplı modda saydamlık, renk verisinden ayrı bir kanalda saklanıyor. Bu da kalite ayarının renk görünümünü etkilerken saydamlık kenarlarının keskin kalması anlamına geliyor. Yumuşak bir gölgeye sahip bir logo, kayıplı 80’de kaydedildiğinde gölgenin kenarı hâlâ temiz hissediliyor, içindeki renk değerleri sıkıştırılmış olsa bile. Bu, WEBP’ye özel bir özellik — JPEG bunu yapamaz, PNG ise ancak çok daha büyük bir dosyayla aynı sonucu yakalayabilir.

WEBP için tarayıcı desteği bu noktada artık evrensel sayılır. Chrome, Edge, Firefox, Safari, Opera ve büyük mobil tarayıcıların hepsi, eskiden alıştığımız picture etiketi geri dönüş dansı olmadan WEBP’yi sorunsuz açıyor. Geride kalan istisnalar; eski iç araçlar, bazı e‑posta istemcileri (özellikle Windows üzerinde Outlook) ve uzun süredir güncellenmemiş bir CMS eklenti kuyruğu. Kamuya açık siteler, pazarlama sayfaları ve ürün galerileri için JPEG geri dönüşü olmadan doğrudan WEBP’ye geçmek artık güvenli bir karar; bilinen bir istemci karışımına hizmet veren kurum içi portallarda ise karar vermeden önce bir kontrol değer.

Build süreçlerinde fazla konuşulmayan bir kazanç da var. Kayıpsız WEBP dosyaları, kayıplı moda hiç girilmeden bile genellikle eşdeğer PNG’den yaklaşık yüzde 25 daha küçük; yani daha önce 80 MB PNG ikon yayınlayan bir statik site build’i, hiçbir görsel fark olmadan 60 MB’a düşebiliyor. CDN bant genişliği faturaları, edge cache verimliliği ve mobil veride “site hızlı yüklendi” algısı bundan sessizce yararlanıyor. Karşılığında build süreleri marjinal olarak uzuyor; çünkü WEBP kodlaması PNG’ninkinden yavaş, ama çoğu sitenin işlediği ölçekte bu fark birkaç saniyeden ibaret.

Bilinmesi gereken birkaç tuhaflık. Animasyonlu PNG, nadir de olsa var ve bu dönüştürücüden sağ çıkmıyor — WEBP çıktısına yalnızca ilk kare yansıyor. Kaynak, döngüsünü korumak isteyen bir APNG’yse doğrudan animasyonlu WEBP üretebilen bir aracı tercih etmek lazım. Renk profili dönüşüm boyunca sRGB olarak korunuyor; her modern tarayıcının zaten varsaydığı uzay bu. PNG’nin bazen taşıdığı EXIF / metadata parçaları yol üzerinde düşürülüyor — kamuya açık webe gidecek dosyalar için doğru varsayılan tam olarak bu.

Pratikte iş tek bir sürükle bırak. PNG’yi koy, WEBP’yi al; kayıpsız ya da kayıplı seçenekleri ile yalnızca kayıplı modda anlam kazanan kalite kaydırıcısı orada. Dosyalar geçici depolamada işleniyor, indirme bağlantıları kısa sürede geçersizleşiyor; hesap açma yok, filigran yok, arka planda tıkır tıkır işleyen kota da yok. Birden fazla dosya arka arkaya geçebiliyor; tek bir hero görseli yerine bütün bir ikon setini ya da asset klasörünü göç ettirirken bu önemli oluyor. Çoğu dosya bir saniyenin altında dönüyor; çok megabayttı PNG’lerin kayıpsız dönüşümü, kodlayıcının her pikseli eşlemek için daha fazla iş yapması nedeniyle biraz daha uzun sürüyor ama yine tek seferde bitiyor.

GitHub README dosyalarında ve dokümantasyon platformlarında render davranışı bu dönüşümün küçük ama belirleyici bir kullanım alanını oluşturuyor. GitHub web arayüzünde README içindeki WEBP görselleri sorunsuz açıyor; ama repoyu klonlayıp yerel bir editörde okuyan herkes — VS Code’un dahili markdown önizlemesi, JetBrains IDE’lerinin önizleme paneli, Vim’in markdown eklentileri — WEBP’yi inline gösteremeyen bir uzun kuyruğa çarpıyor. README ekran görüntülerinin sayısı çoksa bunları WEBP’ye çevirmek depo boyutunu hissedilir biçimde küçültüyor, ama bu yalnızca repoyu okuyan herkes sonucu gerçekten görebiliyorsa anlamlı. Pratik yol şu: README görsellerini PNG olarak tutmak (herkes render ediyor), Vercel’de yayınlanan dokümantasyon sitesi, Docusaurus, MkDocs gibi render hattının modern olduğu bilinen yerlerde WEBP’ye geçmek. Bu ikilik, repo görünümünü bozmadan teslimat hattında kazanç sağlıyor.

Tasarım sistemi yöneten ekipler için bu dönüşümün ayrı bir yeri var. Storybook ya da benzeri bileşen kütüphanelerinde her bir UI komponenti için yan yana saklanan görseller genelde PNG olarak başlıyor; sistem büyüdükçe ve yüzlerce, hatta binlerce ikon birikince bu klasörün toplam boyutu git deposunu yavaşlatacak ölçüye geliyor. Tasarım token’ları ve componentler PNG’den WEBP’ye topluca çevrildiğinde hem repo boyutu hem de geliştiricinin bilgisayarında lokal build süresi belirgin biçimde düşüyor — özellikle Mac dışında çalışan ekiplerde Windows üzerinde Node’un binlerce küçük PNG’yi tek tek okumakta yaşadığı yavaşlık ortadan kalkıyor. Tek bir tasarımcının küçük bir setini değil, paylaşılan bir kütüphanenin bütününü düşününce, bu dönüşümün getirisi yalnızca son kullanıcıya değil, ekibin günlük çalışma temposuna da yansıyor.

Kurumsal iletişim ve e‑posta imzaları tarafında genelde gözden kaçan bir küçük ayrıntı var. Türk şirketlerinin önemli bir kısmı e‑posta imzalarında PNG logo kullanıyor ve bu imzalar her gönderilen e‑postaya bir asset olarak ekleniyor; günde yüz e‑posta gönderen bir çalışan, ayda binlerce kez aynı PNG’yi tekrar tekrar internete yolluyor. Bu logoyu kayıpsız WEBP’ye çevirmek imza boyutunu yarıya düşürüyor ve uzun vadede şirketin çıkış trafiğinde gerçek bir fark yaratıyor — özellikle iletişim hattı sınırlı kurumlarda bu hesaba değiyor. Outlook’un eski versiyonlarının WEBP imzayı render etmediği gerçeği bir engel gibi görünebilir, ama imzanın yedeğini PNG olarak tutup çift varyant gönderen kurumsal yapılandırmalar bu sorunu çoktan çözüyor; tasarım tarafında WEBP, fallback tarafında PNG.

Önemli bir ayrım daha var: çok küçük PNG dosyaları için bu dönüşüm aslında işe yaramıyor. UI sprite’larında kullanılan ve 5 KB altında olan ikonlar WEBP’ye geçtiğinde anlamlı şekilde küçülmüyor; çünkü formatın dosya başı ek yükü o ölçekte görsel verisinin kendisiyle yarışmaya başlıyor. Hatta bazen WEBP versiyonu, yerini aldığı PNG’den daha büyük çıkıyor — çoğu kişinin beklediğinin tam tersi bir sonuç ve dosya boyutlarını manuel karşılaştırmadan fark edilmesi zor. Dürüst cevap, küçük grafikler için PNG’nin doğru format olarak kalması ve bunların hepsini birden WEBP’ye çevirmenin toplam kazancının sıfıra yakın olması. Çabayı gerçek tasarrufun yattığı büyük dosyalara odaklamak, ikon tozunu PNG olarak bırakmak en pragmatik karar.