Hoe verklein ik een JPG tot onder de 100 KB?

De gemeten kwaliteitsladder voor één foto van 538,6 KB, waarom de schuifregelaar vastloopt op 131 KB en waarom het snijden van pixels de hefboom is die daadwerkelijk een bytebudget raakt.

August 9, 2026 · Updated August 21, 2026

Een uploadformulier zegt maximaal 100 KB. Je foto is 538,6 KB. De reflex is om de kwaliteitschuif te pakken en naar links te slepen, en voor een grote foto zal die reflex je daar niet brengen. We hebben één bestand genomen en de hele ladder doorlopen: texture.jpg op 3840x2160, 538,6 KB op schijf. Zelfs bij kwaliteit 30 komt het uit op 131 KB, en de afbeelding is dan zichtbaar beschadigd.

Het getal dat daadwerkelijk de JPEG-grootte controleert, is het aantal pixels. Baseline JPEG codeert de afbeelding in blokken van 8x8, dus het halveren van beide dimensies laat een kwart van de blokken over om op te slaan. Als je alleen de schuifregelaar hebt, zul je rond de 131 KB vastlopen bij een bestand van deze grootte. Elk cijfer hieronder komt uit onze eigen compressor en resizer, die draait in een browsertabblad. Er is geen uploadstap om op te wachten.

Waarom brengt de kwaliteitschuif me niet naar 100 KB?

Hier is de ladder, elke keer dezelfde bronbestand, uitgevoerd in de afbeeldingscompressor in handmatige modus. Slimme modus kiest de standaardinstelling van elke encoder, die 80 is voor JPEG en WebP, 63 voor AVIF en verliesloos voor PNG.

Zestig punten van de schuif leverden 216,8 KB op. De laatste stretch, van 60 naar 30, gaf veel zichtbare details op voor 81,4 KB. Een foto van 3840x2160 heeft 8,3 miljoen pixels om te beschrijven, en er is een vloer onder het aantal bytes dat ze bij die grootte kan beschrijven. De vloer is reëel.

Waarom is kwaliteit 30 niet echt 30?

Dit verwart mensen, en het is aan ons om het uit te leggen. Wanneer de bron een JPEG is, leest onze compressor de kwantisatietabellen uit de eerste 64 KB van het bestand en schat de kwaliteit waarop het is opgeslagen. Je schuif regelt vervolgens die schatting. Een foto opgeslagen bij kwaliteit 60, met de schuif op 80, codeert bij 48. Het herschalen voorkomt dat een tweede doorgang kwaliteit claimt die de pixels niet kunnen leveren, omdat het opnieuw coderen van een kwaliteit-60 bestand bij 90 gewoon bytes uitgeeft voor het beschrijven van schade die al is ingebakken. De encoder eronder is MozJPEG. Eén ding dat het waard is om te weten: compressie verwijdert elk stukje metadata, EXIF, GPS, ICC-profiel en ingesloten miniatuur. Oriëntatie overleeft.

Waarom komt de schatting naast de schuif niet overeen met het resultaat?

Omdat het een curve is, geen codering. Het paneel drukt dat nummer af voordat er iets draait, alleen op basis van twee dingen: je bestandsgrootte en de schuifpositie. Het is de oorspronkelijke bytes vermenigvuldigd met de schuif gedeeld door 100, verheven tot de macht van 1,8. Het ziet nooit een pixel van je afbeelding, en het weet ook niets over het herschalen hierboven, dus in het voorbeeld van kwaliteit 60 drukt het een cijfer voor 80 af terwijl de encoder op het punt staat 48 te gebruiken.

Bij hetzelfde testbestand van 538,6 KB is de kloof groot, en het verandert van richting over het bereik. Bij schuif 90 voorspelde het paneel 445,5 KB tegen een werkelijke 347,8 KB, 28% te hoog. Bij schuif 30 voorspelde het 61,7 KB tegen een werkelijke 131 KB, 53% te laag. Lees dat tweede nog eens als je op een limiet van 100 KB mikt: de schatting zegt dat je het met 38 KB hebt gehaald op het moment dat de encoder op het punt staat het met 31 KB te missen. De KB op de resultaatkaart is het enige nummer waar je op moet handelen. In de palet PNG-modus is er helemaal geen schatting, en het paneel drukt een waarschuwing in plaats daarvan af.

Hoe krijg ik eigenlijk een JPG onder de 100 KB?

Snijd eerst pixels, en comprimeer dan. Open de resizer en gebruik de percentagevoorkeursinstellingen, die 25, 50 en 75 zijn. Vijftig procent brengt 3840x2160 terug naar 1920x1080, een kwart van de pixels. Vijfentwintig procent brengt het naar 960x540, een zestiende. Er zijn ook 15 sociale voorkeuren met vaste afmetingen, van een 1080x1080 Instagram vierkant tot een 2560x1440 YouTube-banner, plus een exacte-pixels modus met de modi bedekken, bevatten en uitrekken. Die exacte-pixels modus is hoe een 600 x 600 pasfoto vierkant zonder het vervormen van een gezicht wordt ingevoerd. Als je mikt op 100 KB vanuit een 4K foto, begin dan bij 25% en werk omhoog.

Twee dingen over de resizer zijn het waard om eerst te weten. PNG-uitvoer blijft verliesloos, en elke andere indeling wordt standaard opnieuw gecodeerd bij kwaliteit 90, dus een JPEG die door beide tools gaat, wordt twee keer gecodeerd. Geanimeerde bronnen komen eruit als één stilstaand beeld. En wanneer de uitvoer van de compressor groter zou zijn dan het bestand dat je hebt ingevoerd, geeft het je origineel ongewijzigd terug.

Zou WebP of AVIF me sneller daarheen brengen?

Lees die tabel twee keer. Bij dezelfde schuifpositie van 80 produceerde JPEG het kleinste bestand en AVIF het grootste, wat achterstevoren lijkt totdat je je de herschaling hierboven herinnert. JPEG's 80 was geschaald tegen de eigen geschatte kwaliteit van de bron, dus het was niet echt 80, terwijl WebP en AVIF het nummer letterlijk nemen. Verlaag ze naar AVIF's slimme standaard van 63 en de moderne codecs trekken vooruit: 200,6 KB voor WebP, 186,9 KB voor AVIF. Beide zijn nog steeds een lange weg van 100 KB bij 3840x2160, wat de hele bedoeling is. AVIF kostte ook ongeveer 10 tot 11 seconden per codering op deze machine, terwijl JPEG en WebP onmiddellijk terugkwamen, en browserondersteuning jonger is. Onze JPG naar WebP route is vergrendeld op 4:2:0 chroma, dus harde rode randen verzachten een beetje.

Wat als mijn bestand een PNG met transparantie is?

Helemaal een andere hefboom. We hebben alpha.png, 900x606 en 942,4 KB met een echte alfakanaal, door beide PNG-modi gedraaid. De optie "Geen compressie" is oxipng op niveau 3, volledig verliesloos, en het gaf 383,9 KB terug, een vermindering van 59% met elke pixel intact. De optie "Kleinere bestandsgrootte" draait libimagequant, die de afbeelding naar een palet reduceert, en het gaf 98,3 KB terug. Dat is 90% minder, en het haalt een budget van 100 KB zonder de afmetingen aan te raken. Paletten banderen soepele verlopen, dus controleer een lucht of een zachte schaduw voordat je het verzendt. Transparantie overleeft beide modi. Vraag om JPEG-uitvoer en het alfakanaal is verdwenen, gematteerd op wit.

Kan ik mijn weg naar 100 KB knippen?

Deels. Bijsnijden verwijdert pixels, dus het verwijdert bytes. Onze cropper neemt één bestand tegelijk tot 10 MB en biedt acht aspectvoorkeursinstellingen plus een aangepaste W:H-verhouding. Er is geen veld om een doelbreedte in pixels in te voeren, dus je kunt niet mikken op een exacte uitvoergrootte, en elke bijsnijding van een verliesformat wordt opnieuw gecodeerd bij een hardcoded kwaliteit van 92. Een GIF komt terug als een enkel-frame PNG. Voor het halen van een bytebudget geven de percentagevoorkeursinstellingen van de resizer je een directere controle.

Uploadt dit iets van mijn foto?

Nee. Deze app heeft geen API-routes en geen serveracties, en de enige netwerkverzoeken die het doet, zijn same-origin fetches voor zijn eigen middelen en WASM-codecs. Je bestand wordt gedecodeerd naar een canvas en opnieuw gecodeerd door WASM in dezelfde tab. De meeste andere tools in deze categorie werken het tegenovergestelde: je afbeelding reist naar hun server en blijft in hun opslag totdat een retentietimer afgaat. Dat is het verschil dat onze privacypagina uitlegt. Het is ook waarom een batch hier is beperkt tot 10 bestanden en 50 MB, aangezien je eigen CPU het werk doet. Diezelfde limiet is waarom een map met 300 bestanden erin geen browserklus is.