Test av PDF-komprimering: metod, filstorlek och funktioner

Vad testades och vad testades inte?

Vi testade samma oförändrade komprimeringskod som PDF-komprimeraren på den här webbplatsen använder. Vid mätningen kördes den dock inte i webbläsaren, utan anropades direkt i Node.js. På så sätt kunde indata, inställningar och det sparade resultatet dokumenteras exakt för varje körning.

• Komprimeringsmodul: QPDF 12.2.0 som WebAssembly, wrapper-version 0.3.0. Wrapperns byggskript anger QPDF 12.2.0, och den installerade modulen rapporterar också 12.2.0 vid en versionsförfrågan.
• Miljö: Node.js 24.18.1 i Windows 11, versionsbygge 26200, x64.
• Omfattning: tre syntetiska indatafiler, nio komprimeringskörningar och en testfil med en signaturplatshållare som ska avvisas.
• Efterkontroll: tolv sparade PDF:er med sammanlagt 24 sidor, samtliga med strukturkontroll och renderad sidvy.

Följande ingår inte i denna mätning:

• bearbetningstiden; ingen tid mättes,
• beteendet i enskilda webbläsare eller på riktiga smarttelefoner och surfplattor,
• riktiga foton, skanningar, stora filer eller dokument från användare,
• andra komprimeringsprogram eller onlinetjänster,
• en genomsnittlig besparing som du kan förvänta dig för din fil.

Testfiler, inställningar och nedladdningar

Testet innehåller enbart PDF:er som vi har skapat själva. Det finns inga kunddokument, inga foton från verkligheten och inga signaturer från riktiga personer. Bilden i bildfilen är också genererad: den visar en textur med en färgövergång och är varken ett foto eller en skanning.

• Textfil, 3 029 byte: två sidor med text, ett ifyllt formulärfält, en länk, en sidrotation och en markering i strukturträdet.
• Bildfil, 1 359 079 byte: samma beståndsdelar samt en genererad bild med 640 × 800 pixlar. Textfilen utan bild är bara 3 029 byte, så den största delen av denna filstorlek kommer från bilden.
• Redan optimerad textfil, 2 721 byte: den används för att testa ett fall där det inte går att minska storleken ytterligare.
• Fil med signaturplatshållare, 3 139 byte: den innehåller bara strukturen för en signatur, men ingen riktig digital signatur. Den används för att kontrollera om komprimeraren avvisar signerade filer.

Samma utgångsläge för varje körning

• Varje körning börjar med originalets oförändrade byte. Om en körning kräver flera försök börjar även varje nytt försök från originalet och inte från det föregående resultatet.
• Alla resultat innehåller båda sidorna i sin helhet. Inga sidor togs bort, inget packades som ZIP, inga bilder skalades ner till färre pixlar och inga hela sidor omvandlades till bilder. Bara då är lägenas byteantal jämförbara.
• Varje resultat sparades med ett eget filnamn. För både indata och utdata dokumenterades byteantal och SHA-256-kontrollsumma. Kontrollsumman är ett fingeravtryck för filen: om så lite som en enda byte ändras, ändras kontrollsumman.
• För varje körning loggades läget, eventuell målstorlek och den JPEG-kvalitet som faktiskt användes.

Vad de tre lägena gör tekniskt

I loggen och tabellerna heter lägena lossless, balanced och small. I verktyget hittar du dem under följande namn: lossless är Förlustfri optimering, balanced är Balanserad och small är Mindre fil. Förlustfri optimering optimerar bara filens uppbyggnad, alltså objekt och komprimerade dataströmmar. Balanserad kodar dessutom om lämpliga bilder till JPEG med kvalitetsnivån 80. Om målstorleken inte nås görs ett försök med 70. Mindre fil börjar på nivån 65 och går vidare till 50 och sedan 40 om målet inte nås. Om du har angett en målstorlek och originalet eller den strukturellt optimerade versionen redan uppfyller målet behövs inget försök med JPEG-komprimering med kvalitetsförlust. Till slut väljs den minsta kontrollerade versionen. Om ingen är mindre än originalet behålls originalet. Någon viss besparing garanteras alltså inte.

Enligt dokumentationen för QPDF 12.2 minskar QPDF inte bildernas upplösning i den här processen. Omkodningen till JPEG kan däremot skapa synliga artefakter, och QPDF använder bara omkodade bilddata om de är mindre. Vad detta innebär för bildkvaliteten förklaras i guiden Komprimera PDF utan kvalitetsförlust.

Filer och kontrollsummor för egen kontroll

Följande tabell länkar till alla test- och resultatfiler. Jämför SHA-256-kontrollsumman efter nedladdningen med ett valfritt verktyg för kontrollsummor. Om den stämmer har du exakt den fil som mättes. Den engelskspråkiga loggen reproducibility-manifest.json innehåller de exakta anropen och inställningarna för alla körningar.

Resultat: en ärlig redovisning av filstorleken

Det går inte att förutsäga hur mycket din egen PDF krymper utifrån det här testet. Det beror på vad din fil innehåller. Redan de tre testfilerna visar spännvidden: den lilla textfilen blev 10,17 procent mindre i läget lossless, medan bildfilen bara blev 0,02 procent mindre i samma läge. Först omkodningen till JPEG gav en besparing på 86,78 procent för bildfilen. Tabellen innehåller alla nio körningar, även de utan någon nämnvärd besparing.

Besparingen beräknas alltid utifrån det faktiska antalet byte: sparade byte dividerat med originalstorleken. För körningen med balanced är det 1 179 371 av 1 359 079 byte, alltså 86,78 procent. För din egen fil kan du kontrollera detta med kalkylatorn för komprimeringsgrad.

JPEG-kvalitet är inte en besparing i procent

Värdena 80, 65 eller 40 är inställningar för JPEG-kodaren och inga procentangivelser för storleksminskningen. Kvalitetsnivån 80 gav här en besparing på 86,78 procent, medan nivån 65 gav 90,75 procent. För en annan fil kan samma nivåer ge helt andra resultat.

Varför fallet utan besparing ingår i testet

Ett test som bara visar den största besparingen utelämnar ett viktigt fall: vad händer när det inte går att minska storleken ytterligare? För den redan optimerade textfilen på 2 721 byte gav läget lossless ingen mindre version. Komprimeraren behöll därför originalet: utdata 2 721 byte, 0 byte i besparing, och indata och utdata har samma SHA-256-kontrollsumma. Det visar med den faktiska komprimeringsmodulen att du i detta fall inte får en omskriven fil utan någon nytta. Vad du kan göra då beskrivs i guiden PDF-filen blir inte mindre.

Målstorleken uppnådd, missad eller redan uppfylld

• Mål 250 000 byte: redan det första försöket med nivån 65 gav 125 710 byte. Målet var därmed uppnått, och resultatet är till och med identiskt byte för byte med körningen utan mål.
• Mål 128 byte: för två sidor med en bild är det orealistiskt litet. Inte heller den sista nivån 40 kom längre än till 74 707 byte. Komprimeraren meddelar att målet inte har uppnåtts och levererar ändå en fil. För denna testfil innehåller den sparade resultatfilen på 74 707 byte båda sidorna, och funktionskontrollerna som beskrivs längre ner godkändes. Bilddata kodades då om med förlust. Den här körningen bevisar inte att allt innehåll bevaras i alla andra filer.
• Mål 1 359 079 byte, alltså exakt originalstorleken: målet betraktades som redan uppfyllt. Bara den strukturella, förlustfria optimeringen kördes. Den gav 1 358 764 byte, samma storlek som körningen med lossless. Bilden kodades inte om till JPEG, eftersom de loggade anropen inte innehåller någon JPEG-inställning.

Samma storlek, annan kontrollsumma

Den upprepade körningen med balanced gav återigen exakt 179 708 byte, men en annan SHA-256-kontrollsumma. Även körningen med redan uppfyllt mål har samma storlek som körningen med lossless, men ändå en egen kontrollsumma. En möjlig orsak är att exempelvis en ny dokumentidentifierare kan skapas när en PDF skrivs. Körningarna med small utan mål och med målet 250 000 byte överensstämde däremot byte för byte. Kontrollsumman identifierar alltså en viss sparad fil. Om du upprepar en körning, även i webbläsaren, får du inte nödvändigtvis en fil som är identisk byte för byte, även om storleken är densamma.

Visning och funktioner kontrollerades separat

Att en fil är mindre säger i sig inget om huruvida text, formulär och länk har bevarats. Inte heller en bra förhandsvisning bevisar det. Därför kontrollerades de sparade filerna med två oberoende bibliotek: pdf-lib läser den sparade interna strukturen, och PDF.js 6.4.299 renderar sidorna och läser ut text och annoteringar. PDF.js kördes för detta i en isolerad Chromium-instans med versionen 151.0.7922.34. Denna kontroll av de färdiga filerna är separat från komprimeringen, som mättes i Node.js i Windows 11. Komprimering i webbläsaren eller på mobila enheter mättes inte, och kontrollen säger inget om beteendet i andra PDF-program. Varje kontroll har en egen metod och gäller bara dessa testfiler.

En detalj om formulärfältet: dess värde visas inte tillförlitligt i den vanliga textextraktionen i PDF.js, utan lästes ut via annoteringarna. Om du söker efter ett ifyllt formulärvärde i en komprimerad PDF och inte hittar det betyder det därför inte automatiskt att det saknas.

I balanced och small kodades bilden om till JPEG med förlust, utom i small-körningen där målet redan var uppfyllt. De avkodade innehållsinstruktionerna för text och linjer förblev desamma, men texturens bilddata gjorde det inte. På de renderade sidorna i resultaten från bildfilen var bildens position och utbredning samt sidrotationen desamma som i originalet. Viktigt när du själv granskar filerna: redan i originalet ligger den genererade bilden över flera textrader. Denna överlappning hör till testfilen och är ingen skada som komprimeringen har orsakat. Den finns kvar i resultaten. Det ger inget besked om läsbarheten för varje rad och inget kvalitetsbetyg. En genererad bild med textur och färgövergång säger dessutom lite om hur foton, skanningar eller liten text i skanningar påverkas av samma nivå. Läs även guiden Minska storleken på en skannad PDF.

Signaturplatshållaren visar bara att komprimeraren identifierar en fil med signaturstruktur och inte bearbetar den. Enligt komprimeringskoden avvisas även krypterade och certifierade filer. Testet kontrollerar inte om en riktig signatur är giltig och kringgår inte heller något skydd. Läs mer i guiden Komprimera PDF med signaturer och formulär.

Begränsningar och egen kontroll

Är verktyget bättre än PDF24 eller Adobe?

Den här sidan ger inget svar på det. Vi har inte kört andra program eller onlinetjänster med samma filer. Ett omdöme om kvalitet, hastighet eller pris i jämförelse skulle därför sakna belägg. Topplistor med procentangivelser eller skjutreglage ersätter inte heller en sådan jämförelse. En rättvis jämförelse kräver samma fullständiga indatafil, samma sidor, dokumenterade inställningar, exakta byteantal och samma funktionskontroller för alla resultat.

Så kontrollerar du din egen PDF

1. Behåll en oförändrad kopia av originalet.
2. Öppna PDF-komprimeraren och välj filen. Om bilddetaljer är viktiga börjar du med det förlustfria läget.
3. Anteckna den exakta storleken i byte för originalet och resultatet, till exempel från filegenskaperna, och beräkna besparingen med kalkylatorn för komprimeringsgrad.
4. Börja varje nytt försök med originalet igen och inte med ett resultat som redan har komprimerats. Spara varje resultat med ett nytt filnamn så att du inte skriver över något.
5. Öppna den sparade filen i det program som mottagaren också använder. Kontrollera alla sidor, sök efter ett känt ord, kontrollera formulärvärden och länkar och granska bilder och liten text i originalstorlek.
6. Om din PDF är digitalt signerad, krypterad eller certifierad ska du inte komprimera den med det här verktyget, utan reda ut tillvägagångssättet med utfärdaren.