PNG vs JPG: welke moet je eigenlijk opslaan?
Verliesvrij versus verlieslatend, het alpha-kanaal dat JPG niet heeft en de chroma subsampling die tekst vervaagt, met gemeten bestandsgroottes van beide formaten.
PNG en JPG verschillen op één vraag: onthoudt het bestand elke pixel precies? PNG doet dat. JPG laat details weg die het menselijk oog moeilijk kan waarnemen, en het wordt veel kleiner in ruil daarvoor. Die enkele splitsing bepaalt bijna elke situatie die je tegenkomt, en het valt de ene kant op voor een strandfoto en de andere kant op voor een screenshot van een spreadsheet.
Elk getal hieronder komt uit de eigen tools van LeanImg die draaien in een browsertabblad, op twee testbestanden: texture.jpg op 3840x2160 en 538,6 KB, plus alpha.png op 900x606 en 942,4 KB met een transparante achtergrond. We hebben deze tools gebouwd zonder API-routes en zonder serveracties, zodat het bestand nooit je machine verlaat. De meeste sites in deze categorie uploaden je afbeelding naar een server en beloven die een uur later te verwijderen. Hier is niets te verwijderen, wat de reden is dat onze privacy pagina kort is.
Welke moet ik kiezen, PNG of JPG?
Foto's gaan naar JPG. Screenshots, logo's, grafieken, lijntekeningen en alles wat transparantie nodig heeft, gaat naar PNG. MDN's formatgids trekt dezelfde lijn. In slimme modus nam onze compressor texture.jpg van 538,6 KB naar 286,1 KB met MozJPEG op kwaliteit 80, een vermindering van 47%. Sleep de schuifregelaar naar 60 en dezelfde foto komt uit op 212,4 KB. Bij 30 is het 131 KB, een daling van 76%.
Die splitsing komt voort uit hoe elk formaat comprimeert. Het ontwerp van JPG gaat ervan uit dat aangrenzende pixels in elkaar overlopen, wat geschikt is voor verlopen en filmkorrel. Een screenshot doorbreekt die aanname bij elke tekstrand. PNG voorspelt elke pixel op basis van zijn buren en reduceert vervolgens het verschil, zodat het zijn beste werk levert op de vlakke delen van identieke kleur waar een gebruikersinterface uit bestaat.
Wat doet verliesvrije compressie eigenlijk met de bestandsgrootte?
Verliesvrij betekent dat de gedecodeerde pixels bit voor bit identiek terugkomen, wat de PNG-specificatie vereist. Het betekent niet dat het bestand niet kan krimpen. De PNG-modus van onze compressor draait oxipng op niveau 3, en het nam alpha.png van 942,4 KB naar 383,9 KB. Dat is 59% minder met elke pixelwaarde behouden.
De "kleinere bestandsgrootte" PNG-optie is een ander verhaal. Het draait imagequant, dat de afbeelding reduceert tot een kleurenpalet voordat de PNG wordt geschreven, en alpha.png kwam uit op 98,3 KB. Dat is 90% minder. Het is een verlieslatend resultaat, ongeacht wat de .png-extensie impliceert, dus houd het origineel vast als die afbeelding een masterkopie is.

Waarom vervaagt JPG gekleurde tekst en dunne lijnen?
Omdat JPG kleur opslaat op een lagere resolutie dan helderheid. Het formaat houdt luma gescheiden van de twee chromakanalen, zoals gespecificeerd in ITU-T T.81, en encoders downsample meestal chroma zodat één kleurmonster een 2x2 blok pixels dekt. Op een 3840x2160 foto zoals texture.jpg zul je het niet opmerken. Op een één-pixel rode lijn tegen wit, wordt de kleur van die lijn gemiddeld met drie witte buren voordat er een kwaliteitsinstelling wordt toegepast, en geen enkele schuifpositie brengt het terug.
Screenshots zijn waar het pijn doet. Overschakelen naar WebP ontwijkt het niet, omdat WebP's verlieslatende modus vastzit op 4:2:0 chroma en dezelfde averaging toepast. PNG behoudt de exacte RGB-waarde van elke pixel, wat de reden is dat UI-captures, QR-codes en tekstoverlays daar thuishoren. Als de PNG nog steeds te zwaar is, kwantiseer het en behoud het formaat.
Wat gebeurt er met transparantie wanneer ik opsla als JPG?
Het wordt ingevuld. JPEG heeft geen alpha-kanaal in enige modus, dus er moet iets beslissen wat er achter je transparante pixels zit. Onze PNG naar JPG converter componeert ze op wit voordat ze worden gecodeerd, en de compressor doet hetzelfde telkens wanneer het doelformaat geen alpha heeft. Zonder die stap zouden ze zwart uitkomen, omdat een volledig transparante pixel meestal RGB 0,0,0 eronder heeft.
Je kunt die rondreis niet terugdraaien. Teruggaan via JPG naar PNG geeft je een PNG met een witte rechthoek waar de transparantie ooit was, plus welke JPG-artifacten de eerste keer zijn ingebakken. Comprimeren verwijdert ook elk stuk metadata: EXIF, GPS, ICC-profiel en ingesloten miniatuur verdwijnen allemaal, hoewel de oriëntatie behouden blijft. Bewaar de PNG-master; je zult het willen. Als je een onderwerp uit een foto snijdt, schrijft onze achtergrondverwijderaar altijd PNG met alpha om deze reden, wat ook de reden is dat een uitsnede zwaarder terugkomt dan de JPG die je erin hebt gedropt, en de icoongenerator stelt zijn achtergrondkleur standaard in op #ffffff, zodat een transparant logo op een witte vierkant landt totdat je dat veld wijzigt.
Waarom is mijn PNG zoveel groter dan de JPG?
Fotografisch ruis biedt PNG's voorspeller niets om mee te werken. Elke rij wordt geraden op basis van de rij erboven en het overgebleven verschil wordt verminderd, wat geweldig is op een vlakke knop en bijna nutteloos op korreligheid. Kijk naar de twee testbestanden. alpha.png is 900x606 en kwam uit op 942,4 KB, terwijl texture.jpg 3840x2160 is, meer dan vijftien keer het aantal pixels, en uitkwam op 538,6 KB. Paletkwantisatie is de hefboom die die kloof sluit, en het bracht alpha.png naar 98,3 KB.
Moet ik WebP of AVIF opslaan en de vraag overslaan?
Soms, hoewel het de moeite waard is om te meten. We hebben texture.jpg door de compressor gehaald met dezelfde schuifpositie van 80 voor alle drie de formaten, en vervolgens opnieuw op 63.
| Uitvoerformaat | Schuif 80 | Schuif 63 | Encodeertijd |
|---|---|---|---|
| JPEG (MozJPEG) | 286,1 KB | niet gemeten | direct |
| WebP | 290,3 KB | 200,6 KB | direct |
| AVIF | 312,7 KB | 186,9 KB | 10 tot 11 seconden |
AVIF die het grootste bestand produceert bij schuif 80 lijkt achteruit, en de oorzaak ligt in onze eigen code. Voor een JPEG-bron vermenigvuldigt de compressor je schuif met de kwaliteit die het leest uit de kwantisatietabellen van de bron, dus een bron die op 60 wordt geschat met de schuif op 80 encodeert eigenlijk op 48. WebP en AVIF nemen 80 voor waar aan. Bij 63, wat de slimme modus standaard is voor AVIF, draait de volgorde om: AVIF is 186,9 KB en WebP is 200,6 KB tegen die 538,6 KB bron. AVIF kostte ook 10 tot 11 seconden per encode waar JPEG en WebP direct klaar waren, en het is de moeite waard om browserondersteuning te controleren voordat je je verbindt. We hebben die vergelijking uitvoerig uiteengezet in het stuk over de vraag of WebP JPG echt verslaat.
Wat moet ik doen met het bestand dat voor me ligt?
Open de compressor. Voer je bestand twee keer uit. Als het een foto is, neem dan eerst de slimme modus, sleep dan de schuif naar 60 en vergelijk de twee uitvoer op volledige zoom. Als het tekst of transparantie heeft, blijf dan op PNG en probeer beide PNG-modi: verliesvrij kreeg alpha.png naar 383,9 KB en de paletmodus kreeg het naar 98,3 KB. Wijzig eerst de grootte wanneer de afbeelding naar een kolom van 800px gaat, aangezien de resizer PNG verliesvrij schrijft en alles anders standaard opnieuw encodeert op kwaliteit 90. En als de bestemming een document is, komt een JPG op een PDF-pagina opnieuw gecodeerd op kwaliteit 92, wat één extra generatie is om rekening mee te houden.