JPEG, PNG ve WebP sıkıştırma aynı problem değildir

Doğru sıkıştırma stratejisi görsel biçimine ve korunması gereken özelliğe bağlıdır. JPEG genellikle daha küçük dosya karşılığında bir miktar görsel sadakat kaybeder, PNG çoğu zaman pikseller değişmeden optimize edilebilir ve WebP kaynak ile kodlayıcıya göre kayıplı veya kayıpsız veri içerebilir.

Son teknik inceleme: 2026-09-19

Temel çıkarımlar

Daha küçük bir görsel otomatik olarak özgün görselle eşdeğer değildir.
Piksel boyutları, alfa şeffaflığı, dosya biçimi ve meta veriler ayrı özelliklerdir ve açık kararlar gerektirir.
Yeniden kodlama genişlik ve yükseklik korunurken bile özgün meta verileri çoğu zaman kaldırır.
Doğrulanmış bir sıkıştırıcı çıktısını sunmadan önce kendi çıktısını çözmeli veya incelemelidir.

JPEG: sınırlı kayıplı yeniden sıkıştırma

JPEG fotoğrafik görüntüler için tasarlanmıştır ve yaygın olarak kayıplı sıkıştırma kullanır. Daha düşük kaliteyle yeniden kodlama aynı piksel boyutlarını koruyarak bayt tasarrufu sağlayabilir ama görsel bilginin bir kısmı atılır.

Tekrarlanan JPEG sıkıştırmaları artefaktları biriktirebilir; bu nedenle sıkıştırıcı sınırlı bir kalite stratejisi kullanmalı ve sonsuza kadar kalite düşürmemelidir.

PNG: kayıpsız pikseller ve yapısal seçimler

PNG kayıpsız görüntü verisini ve alfa şeffaflığını destekler. Kayıpsız optimize edici scanline düzenini veya filtreleri değiştirerek çözülmüş piksel değerlerini değiştirmeden daha verimli temsil sağlayabilir.

Her PNG çeşidi aynı kolaylıkta işlenmez. Paletler, interlace, yüksek bit derinlikleri ve alışılmadık chunk yapıları ayrı destek gerektirebilir.

WebP: biçim desteği ve kodlayıcı davranışı önemlidir

WebP şeffaflık dahil birden fazla kodlama modunu destekler. Tarayıcıdaki kodlayıcının meta veri davranışı kaynaktan farklı olabilir ve her WebP özelliğinin korunduğu anlamına gelmez.

Odaklı bir sıkıştırıcı desteklenen girdileri tanımlamalı, gerekli boyut ve alfa davranışını korumalı ve çıktının gerçekten WebP olduğunu doğrulamalıdır.

ZAMAZY araçları neden ayırır?

ZAMAZY tek bir genel sıkıştırma düğmesi yerine JPEG, PNG ve WebP için ayrı araçlar kullanır. Her aracın kendi destek ve doğrulama kuralları vardır.

JPEG aracı kayıplı yeniden sıkıştırmayı açıkça kabul eder, PNG yolu kayıpsız piksel korumaya odaklanır ve WebP çıktısı desteklenen alt kümede beklenen boyut ve şeffaflıkla WebP olarak doğrulanır.

Örnek ve karar rehberi

Bir fotoğraf, küçük metinli ekran görüntüsü ve şeffaf logo farklı önceliklere sahiptir. Bir miktar kayıp kabul ediliyorsa JPEG fotoğraflara uygun olabilir; çözülmüş pikseller ve alfa tam olarak korunacaksa kayıpsız PNG yararlıdır. WebP birden fazla modu destekler ancak ZAMAZY WebP sıkıştırıcı biçimin izin verdiği her modu değil, sınırlı kayıplı yeniden kodlama akışını kullanır.

Mevcut dosya biçimine uygun sıkıştırıcıyı seçin. Bu odaklı araçlar biçim dönüştürücü veya yeniden boyutlandırma araçları değildir. Sonuçta metin kenarlarını, gradyanları, rengi ve şeffaf sınırları karşılaştırın. Aynı genişlik ve yükseklik aynı RGB piksellerini kanıtlamaz. Kalite değeri kodlayıcı ayarıdır; evrensel görsel puan veya tarayıcılar arasında taşınabilir yüzde değildir.

Bu yaklaşımın uygun olmadığı durumlar

Alfayı korumak renk profilleri, animasyon veya her meta veri alanının korunduğunu kanıtlamaz. Zaten iyi sıkıştırılmış girdi kabul edilebilir daha küçük sonuç vermeyebilir. Tam piksel, animasyon, baskı renk akışı veya belirli yeni biçim gerekiyorsa yalnızca uzantı destekleniyor diye kayıplı sıkıştırıcı kullanmayın.

Editoryal örnek, benchmark değildir. Ek içerik inceleme tarihi: 2026-09-19

Kaynaklar ve kanıt sınırları

Bu kaynaklar biçimleri ve yöntemleri açıklar. ZAMAZY’yi sertifikalandırmaz; ZAMAZY’nin desteklenen gerçekleri ve sınırları ilgili araç sayfasında belirtilir.

MDN: Image file type and format guide — Biçimlerin artı ve eksileri; biçim yetenekleri araç desteği anlamına gelmez.
W3C: PNG Specification, Third Edition — PNG pikselleri, alfa ve chunk yapıları; her PNG çeşidinin kabul edildiği iddiası değildir.
Google: WebP Container Specification — WebP modları, alfa, animasyon ve meta veri kapsayıcıları.
MDN: HTMLCanvasElement.toBlob() — Kodlama biçimi ve kalite parametreleri; sertifikalı meta veri kaldırma iddiası değildir.

Birinci taraf üretici çalışması: kayıpsız PNG koruması

Durum: doğrulandı. ZAMAZY, üç sabit ve tamamen sentetik PNG dosyasını değişmemiş PNG motoruyla işledi; ardından her sonucu yeniden çözüp yapısal olarak karşılaştırdı.

Bu bir birinci taraf üretici çalışmasıdır; bağımsız sertifikasyon değildir. Bilinçli olarak kolay sıkıştırılan girdiler zlib sıkıştırma seviyesi 0 ile oluşturulduğundan tipik bir sıkıştırma benchmarkı değildir.

PNG kanıt akışı diyagramı: sentetik PNG dosyaları gerçek ZAMAZY PNG motoruyla işlenir, yeniden çözülür ve scanline, chunk ve alfa değerleri karşılaştırılır. — Tekrarlanabilir çalışmanın akışı. Medya yalnızca sentetik test verisi içerir.

Üç sentetik PNG vakasında gözlenen sonuçlar
Fixture	Boyutlar	Girdi	Çıktı	Doğrulanmış koruma
`rgb-flat-v1`	256 × 64	49.284 B	252 B	Scanline değerleri aynı; IDAT dışı chunk değerleri aynı; daha küçük çıktı oluşmadığında ikinci geçiş reddedildi
`rgba-pattern-v1`	64 × 32	8.292 B	4.700 B	Scanline değerleri aynı; IDAT dışı chunk değerleri aynı; alfa aynı; daha küçük çıktı oluşmadığında ikinci geçiş reddedildi
`gray-metadata-v1`	64 × 32	2.199 B	158 B	Scanline değerleri aynı; IDAT dışı chunk değerleri aynı; daha küçük çıktı oluşmadığında ikinci geçiş reddedildi

Negatif vakalar

Doğrulanmış ortamda kesilmiş zlib verisi, geçersiz Adler-32 sağlama toplamı ve zlib akışından sonraki ek veriler reddedildi.

truncated-zlib: reddedildi
invalid-adler32: reddedildi
trailing-zlib-data: reddedildi

Yöntem ve sınırlar

Çalışma optimizasyon öncesi ve sonrası çözülmüş scanline değerlerini, geometriyi ve tüm IDAT dışı chunk yapılarını karşılaştırdı; RGBA vakasında alfa açıkça kontrol edildi. Ayrı kontrol dekompresyonu Node zlib kullandı ve bağımsız harici doğrulayıcı değildir.

Kanıt yalnızca belgelenmiş fixture’lar ve belirtilen motor sürümü için geçerlidir. Tüm PNG çeşitlerini, tarayıcı ağ davranışını, cihaz desteğini, tipik sıkıştırma oranlarını veya rastgele kullanıcı dosyalarının güvenliğini kanıtlamaz.

Çalışma png-preservation-v1 · inceleme tarihi2026-09-18 · Node 22.22.3 / zlib 1.3.1-e00f703 / linux x64 ·motor commit’i a12415a3a19f

Sık sorulan sorular

PNG her zaman JPEG’den daha mı büyüktür?

Hayır. Görsele bağlıdır. Fotoğraflar çoğu zaman JPEG ile daha iyi sıkışırken düz grafikler, metin benzeri görseller ve şeffaflık PNG’yi avantajlı yapabilir.

Aynı boyutları korumak görselin kayıpsız olduğu anlamına mı gelir?

Hayır. Genişlik ve yükseklik aynı kalırken JPEG veya kayıplı WebP kodlaması görsel bilgi atabilir.

Sıkıştırmadan sonra meta veriler neden kaybolabilir?

Tarayıcı yeniden kodlaması çoğu zaman özgün kapsayıcı meta verisini kopyalamak yerine yeni bir görüntü akışı üretir. EXIF, GPS ve diğer meta verilerin korunması açık destek ister.