Ce que la compression PDF sans perte fait vraiment gagner, mesuré sur onze fichiers

Tous les compresseurs PDF proposent une option sans perte, et presque aucun ne dit ce qu’elle vaut. Nous avons mesuré la nôtre.

Deux termes, définis

La compression structurelle consiste à réécrire la façon dont un PDF stocke ses objets (la table de références croisées, le regroupement des petits objets dans des flux, le filtre de compression de chaque flux) sans modifier un seul glyphe ni un seul pixel. C’est le seul type de compression qu’on puisse honnêtement qualifier de sans perte.

Un flux d’objets est une fonctionnalité de PDF 1.5 qui regroupe de nombreux petits objets (dictionnaires de page, descripteurs de police, annotations) dans un seul flux compressé au lieu d’écrire chacun sans compression. C’est de là que vient la quasi-totalité du gain structurel, et c’est pourquoi le logiciel qui a produit le fichier décide du résultat avant même que le compresseur ne s’exécute.

La mesure

Nous avons généré onze PDF le 1er octobre 2026 : les mêmes vingt pages de texte imprimées par Chromium 153 (producteur Skia/PDF m153), par macOS Quartz via cupsfilter, par jsPDF 4.2.1 et par pdf-lib avec et sans flux d’objets ; dix photos de 1600 pixels intégrées par Chromium et par pdf-lib ; cinq pages façon scan, chacune un JPEG pleine page en niveaux de gris à la qualité 55 ; un document d’une ligne et d’une page ; un document dont cinq des dix pages avaient été supprimées ; et un fichier chiffré en AES-256. Chacun est passé par compressStructural dans src/lib/pdf/ops.ts, le code exact derrière le réglage sans perte de notre compresseur, sous Node 24 avec @cantoo/pdf-lib 2.11.1.

Fichier	Producteur	Avant	Après	Gain
20 pages de texte	Impression Chromium	82 109 o	81 426 o	0.8 %
20 pages de texte	macOS Quartz	48 441 o	45 278 o	6.5 %
20 pages de texte	jsPDF 4.2.1	72 814 o	69 977 o	3.9 %
20 pages de texte	pdf-lib, sans flux d’objets	34 041 o	33 168 o	2.6 %
20 pages de texte	pdf-lib, avec flux d’objets	33 166 o	33 173 o	−0.02 %
10 photos	Impression Chromium	1 528 699 o	1 528 112 o	0.04 %
10 photos	pdf-lib	1 509 614 o	1 508 973 o	0.04 %
5 pages scannées	pdf-lib	1 816 323 o	1 815 924 o	0.02 %
1 ligne, 1 page	pdf-lib	1 307 o	1 059 o	19.0 %
10 pages, 5 supprimées	pdf-lib	13 900 o	13 441 o	3.3 %
Chiffré	pdf-lib	2 940 o	refusé	—

Lire le tableau

Aucun des quatre producteurs n’a écrit de flux d’objets, et tous les quatre ont écrit une table de références croisées classique. Le passage fait la même chose à chacun : il remplace la table par un flux de références croisées et regroupe les petits objets (dictionnaires de page, descripteurs de police, listes de ressources) dans des flux d’objets. Le gain est donc plafonné par les octets qui se trouvaient hors des flux au départ. Dans le fichier Chromium, c’étaient 8 374 octets sur 82,109, ramenés à 6 896 ; dans le fichier Quartz, 8 234 sur 48,441, ramenés à 4 224. Quartz gagne le plus parce qu’il a écrit 71 objets pour vingt pages là où Chromium en a écrit 52, avec la table la plus verbeuse des quatre. Le fichier pdf-lib qui avait déjà des flux d’objets est ressorti plus lourd de 7 octets : c’est tout le cas « votre fichier peut grossir » de cet échantillon, et cela correspond à la différence entre deux regroupements aussi bons l’un que l’autre des mêmes objets.

Le fichier jsPDF montre le plus clairement la limite de la méthode. jsPDF 4.2.1 écrit par défaut ses flux de contenu sans compression : 65 255 des 72 814 octets du fichier sont des instructions de dessin brutes, et zlib les ramène à 19 053. Cela représente 63.5 % de gain sans perte qui dorment dans le fichier. Le passage structurel ne réencodait pas un flux existant : il a donc trouvé 3.9 % et laissé en place les 65 255 octets bruts. Un passage qui compresserait les flux bruts en Deflate serait tout aussi sans perte (Flate restitue exactement les octets au décodage), et, sur ce producteur, il compterait seize fois plus que le regroupement.

Le réglage sans perte le fait donc désormais. Tout flux écrit sans filtre est compressé en Deflate et n’est conservé que si le résultat est plus léger ; les flux qui portent déjà un filtre, comme les images JPEG, ne sont pas touchés, pas plus que les métadonnées XMP, que la spécification demande de garder lisibles par les outils qui n’analysent pas le PDF. Nouvelle mesure sur un document jsPDF comparable de vingt pages : 132 980 octets sont devenus 18,855, soit un gain de 85.8 %, et le texte de chaque page restait extractible du résultat.

Sur tout fichier chargé en images, le gain relève de l’erreur d’arrondi, car les octets sont dans les flux d’images et un passage structurel ne les ouvre pas. Dix photos pesant 1.5 Mo ont rendu 587 octets. Cinq scans pesant 1.8 Mo ont rendu 399 octets. Les 19 % du document d’une ligne correspondent aux mêmes quelques centaines d’octets de surcoût de table, sur un fichier si petit que ce surcoût en représente l’essentiel.

Les pages supprimées étaient toujours là

Le document modifié est la découverte qui a changé notre façon de décrire ce réglage. Nous avons construit dix pages, chacune portant un marqueur unique dans son texte, en avons supprimé cinq, puis avons enregistré. Le fichier enregistré pesait 13 900 octets et contenait encore les flux de contenu des dix pages : les pages supprimées ne sont plus référencées, mais pdf-lib écrit chaque objet qu’il a analysé. Le passage structurel a regroupé ce fichier à 13 441 octets avec les dix marqueurs toujours à l’intérieur, et le nombre d’objets est passé de 19 à 21.

Copier plutôt les cinq pages restantes dans un nouveau document a produit 7 518 octets, soit 46 % de moins que le résultat « compressé », avec uniquement les marqueurs 0 à 4. Regrouper préserve les orphelins ; reconstruire les élimine.

Cela compte pour le poids, et plus encore pour la confidentialité : une page supprimée avant l’envoi restait extractible d’un fichier passé par notre compresseur sans perte. Pire, la description du réglage elle-même affirmait qu’il « drops unreferenced ones » (supprime les objets non référencés). Ce n’était pas le cas.

Ce que nous avons changé

Le réglage sans perte copie désormais les pages restantes dans un nouveau fichier chaque fois que c’est sans danger, et ne conserve le résultat que s’il est plus léger. Ce n’est pas toujours sans danger : les champs de formulaire interactifs et l’arborescence des signets appartiennent au document et non à une page, si bien qu’une reconstruction les supprimerait sans prévenir. Un fichier qui contient l’un ou l’autre est seulement regroupé, et le résultat le signale au lieu de laisser croire que les orphelins ont disparu.

Nouvelle mesure après le changement, sur un fichier comparable de dix pages dont cinq retirées : un simple regroupement a donné 12 578 octets avec les dix marqueurs à l’intérieur ; le nouveau passage a donné 9 211 octets avec uniquement les marqueurs 0 à 4, soit 27 % de moins, et les pages supprimées ont réellement disparu. Un test du dépôt construit désormais exactement ce fichier et échoue si le contenu d’une page supprimée survit au passage.

Face à la méthode destructive

Les deux autres réglages de notre outil convertissent chaque page en JPEG à 150 ou 110 dpi et la réintègrent. Cela réduit fortement les scans et transforme un document texte en images de texte, sans sélection, sans recherche et sans rien pour un lecteur d’écran. Les services généralistes obtiennent un gain important sans ce coût en exécutant Ghostscript sur un serveur pour sous-échantillonner les images tout en laissant la couche de texte intacte ; Ghostscript est sous licence AGPL-3.0, et le livrer dans un navigateur placerait l’ensemble de ce site sous cette licence.

L’offre honnête est donc celle que montre le tableau : un passage structurel qui trouvera quelques pourcents sur un fichier issu d’un producteur ancien et rien sur un producteur moderne, ou un passage par rastérisation qui coûte la couche de texte. Si le document contient des champs de formulaire ou des signets et que vous voulez que le contenu supprimé disparaisse, le passage sans perte ne le fera pas pour vous, et il le dit désormais : extrayez les pages que vous gardez dans un nouveau fichier, ce que fait Split PDF.