La compression PDF à l’essai : méthode, taille des fichiers et fonctionnalités

Qu’est-ce qui a été testé, et qu’est-ce qui ne l’a pas été ?

Le test a porté sur le même code de compression, sans modification, que celui utilisé par le compresseur PDF de ce site. Pour les mesures, il a toutefois été appelé directement dans Node.js au lieu de s’exécuter dans le navigateur. Cela permet de consigner précisément le fichier d’entrée, les paramètres et le résultat enregistré pour chaque essai.

• Module de compression : QPDF 12.2.0 sous forme de WebAssembly, version du wrapper 0.3.0. Le script de compilation du wrapper fixe la version de QPDF à 12.2.0, et le module installé indique lui aussi 12.2.0 lorsqu’on l’interroge.
• Environnement : Node.js 24.18.1 sous Windows 11, build 26200, x64.
• Périmètre : trois fichiers d’entrée synthétiques, neuf essais de compression et un fichier de test avec un emplacement réservé à une signature, qui doit être rejeté.
• Vérification après compression : douze PDF enregistrés totalisant 24 pages, chacun ayant fait l’objet d’une vérification de sa structure et d’un examen du rendu de ses pages.

Ces mesures ne couvrent pas :

• le temps de traitement ; aucune durée n’a été mesurée,
• le comportement dans les différents navigateurs ou sur de véritables smartphones et tablettes,
• les photos réelles, les documents numérisés, les fichiers volumineux ou les documents des utilisateurs et utilisatrices,
• les autres logiciels de compression ou services en ligne,
• une réduction moyenne à laquelle tu pourrais t’attendre pour ton fichier.

Fichiers de test, paramètres et téléchargements

Le test utilise exclusivement des PDF créés par nos soins. Il ne contient aucun document client, aucune photo du monde réel et aucune signature d’une personne réelle. L’image du fichier image est elle aussi générée : elle représente une texture avec un dégradé de couleurs et n’est ni une photo ni une numérisation.

• Fichier texte, 3 029 octets : deux pages contenant du texte, un champ de formulaire rempli, un lien, une rotation de page et une balise dans l’arbre de structure.
• Fichier image, 1 359 079 octets : les mêmes éléments, auxquels s’ajoute une image générée de 640 × 800 pixels. Le fichier texte sans image ne pèse que 3 029 octets ; l’image représente donc l’essentiel de la taille de ce fichier.
• Fichier texte déjà optimisé, 2 721 octets : il sert à tester un cas où aucun gain supplémentaire n’est possible.
• Fichier avec un emplacement réservé à une signature, 3 139 octets : il contient uniquement la structure d’une signature, sans véritable signature numérique. Il permet de vérifier si le compresseur rejette les fichiers signés.

Les mêmes conditions de départ pour chaque essai

• Chaque essai commence avec les octets d’origine inchangés. Si un essai nécessite plusieurs tentatives, chaque nouvelle tentative repart elle aussi de l’original, et non du résultat précédent.
• Tous les résultats contiennent les deux pages complètes. Aucune page n’a été supprimée, aucun contenu n’a été placé dans une archive ZIP, aucune image n’a été réduite à un nombre inférieur de pixels et aucune page entière n’a été convertie en image. C’est à cette condition que les nombres d’octets des différents modes sont comparables.
• Chaque résultat a été enregistré sous un nom de fichier distinct. Le nombre d’octets et la somme de contrôle SHA-256 ont été consignés pour l’entrée comme pour la sortie. La somme de contrôle est une empreinte du fichier : si un seul octet change, la somme de contrôle change aussi.
• Pour chaque essai, le mode, la taille cible éventuelle et la qualité JPEG réellement utilisée ont été consignés.

Ce que font les trois modes sur le plan technique

Dans le journal et les tableaux, les modes s’appellent lossless, balanced et small. Dans l’outil, tu les trouveras sous les noms suivants : lossless correspond à Optimisation sans perte, balanced à Équilibré et small à Fichier plus petit. Optimisation sans perte optimise uniquement la structure du fichier, c’est-à-dire les objets et les flux de données compressés. Équilibré réencode en plus les images qui s’y prêtent en JPEG avec un niveau de qualité de 80. Si la taille cible n’est pas atteinte, une tentative au niveau 70 est ensuite effectuée. Fichier plus petit commence au niveau 65 et passe à 50, puis à 40 si la cible n’est pas atteinte. Si tu as indiqué une taille cible et que l’original ou la version dont la structure a été optimisée respecte déjà cette cible, aucune tentative de réencodage JPEG avec perte n’est nécessaire. À la fin, la plus petite version testée est retenue. Si aucune n’est plus petite que l’original, celui-ci est conservé. Cela ne garantit donc pas une réduction donnée.

Selon la documentation de QPDF 12.2, QPDF ne réduit pas la résolution des images lors de cette opération. Le réencodage JPEG peut toutefois produire des artefacts visibles, et QPDF ne conserve les données d’image réencodées que si elles sont plus petites. Le guide Compresser un PDF sans perte de qualité explique ce que cela implique pour la qualité des images.

Fichiers et sommes de contrôle pour vérifier les résultats

Le tableau suivant fournit les liens vers tous les fichiers de test et de résultat. Après le téléchargement, compare la somme de contrôle SHA-256 à l’aide de l’outil de calcul de sommes de contrôle de ton choix. Si elle correspond, tu disposes exactement du fichier mesuré. Le journal en anglais reproducibility-manifest.json contient les appels et les paramètres précis de tous les essais.

Résultats : la taille des fichiers présentée en toute transparence

Ce test ne permet pas de prédire de combien ton propre PDF sera réduit. Cela dépend du contenu de ton fichier. Les trois fichiers de test montrent déjà l’étendue des résultats possibles : la taille du petit fichier texte a diminué de 10,17 pour cent en mode lossless, contre seulement 0,02 pour cent pour le fichier image dans le même mode. Seul le réencodage JPEG a permis une réduction de 86,78 pour cent pour le fichier image. Le tableau contient les neuf essais, y compris ceux sans réduction notable.

La réduction est toujours calculée à partir du nombre réel d’octets : les octets économisés divisés par la taille d’origine. Pour l’essai avec balanced, cela représente 1 179 371 sur 1 359 079 octets, soit 86,78 pour cent. Pour ton propre fichier, tu peux vérifier ce calcul avec le calculateur de taux de compression.

La qualité JPEG n’est pas un pourcentage de réduction

Les valeurs 80, 65 ou 40 sont des paramètres de l’encodeur JPEG, et non des pourcentages de réduction de taille. Ici, le niveau de qualité 80 a permis une réduction de 86,78 pour cent, contre 90,75 pour cent pour le niveau 65. Avec un autre fichier, ces mêmes niveaux peuvent donner des résultats très différents.

Pourquoi inclure le cas sans réduction

Un test qui ne montre que la meilleure réduction passe sous silence un cas important : que se passe-t-il lorsqu’aucun gain supplémentaire n’est possible ? Pour le fichier texte déjà optimisé de 2 721 octets, le mode lossless n’a produit aucune version plus petite. Le compresseur a donc conservé l’original : une sortie de 2 721 octets, une réduction de 0 octet et une somme de contrôle SHA-256 identique pour l’entrée et la sortie. Cela démontre, avec le véritable module de compression, que dans ce cas tu ne reçois pas un fichier réécrit sans bénéfice. Le guide La taille du PDF ne diminue pas explique ce que tu peux faire dans cette situation.

Taille cible atteinte, non atteinte ou déjà respectée

• Cible de 250 000 octets : dès la première tentative au niveau 65, le résultat était de 125 710 octets. La cible était donc atteinte, et le résultat est même identique octet par octet à celui de l’essai sans cible.
• Cible de 128 octets : pour deux pages avec une image, cette taille est irréaliste. Même le dernier niveau 40 n’a permis de descendre qu’à 74 707 octets. Le compresseur signale que la cible n’est pas atteinte et fournit tout de même un fichier. Pour ce fichier de test, le fichier de résultat enregistré de 74 707 octets contient les deux pages, et les vérifications fonctionnelles décrites plus bas ont été réussies. Les données de l’image ont été réencodées avec perte. Cet essai ne prouve pas que tous les contenus seront préservés pour n’importe quel autre fichier.
• Cible de 1 359 079 octets, soit exactement la taille d’origine : la cible était considérée comme déjà respectée. Seule l’optimisation structurelle sans perte a été exécutée. Elle a produit un fichier de 1 358 764 octets, de la même taille que celui de l’essai avec lossless. L’image n’a pas été réencodée en JPEG, car les appels consignés ne contiennent aucun paramètre JPEG.

Même taille, somme de contrôle différente

La répétition de l’essai avec balanced a de nouveau produit exactement 179 708 octets, mais avec une somme de contrôle SHA-256 différente. L’essai dont la cible était déjà respectée donne lui aussi la même taille que l’essai avec lossless, tout en ayant sa propre somme de contrôle. Une explication possible est que l’écriture d’un PDF peut, par exemple, générer un nouvel identifiant de document. En revanche, les essais avec small sans cible et avec une cible de 250 000 octets ont donné des fichiers identiques octet par octet. La somme de contrôle identifie donc un fichier enregistré précis. Si tu répètes un essai, y compris dans le navigateur, tu n’obtiendras pas nécessairement un fichier identique octet par octet, même si sa taille reste la même.

Affichage et fonctionnalités vérifiés séparément

Un fichier plus petit ne dit pas encore si le texte, le formulaire et le lien ont été conservés. Un aperçu correct ne le prouve pas non plus. C’est pourquoi les fichiers enregistrés ont été vérifiés à l’aide de deux bibliothèques indépendantes : pdf-lib lit la structure interne enregistrée, tandis que PDF.js 6.4.299 effectue le rendu des pages et extrait le texte et les annotations. Pour cela, PDF.js a été exécuté dans une instance isolée de Chromium, version 151.0.7922.34. Cette vérification des fichiers finaux est distincte de la compression mesurée dans Node.js sous Windows 11. La compression dans le navigateur ou sur des appareils mobiles n’a pas été mesurée, et cette vérification ne permet aucune conclusion sur le comportement d’autres logiciels PDF. Chaque vérification repose sur sa propre méthode et ne vaut que pour ces fichiers de test.

Un détail concernant le champ de formulaire : sa valeur n’apparaît pas de manière fiable lors de l’extraction normale du texte par PDF.js ; elle a donc été lue dans les annotations. Si tu recherches une valeur de formulaire renseignée dans un PDF compressé sans la trouver, cela ne signifie donc pas automatiquement qu’elle est absente.

Avec balanced et small, l’image a été réencodée en JPEG avec perte, sauf lors de l’essai small dont la cible était déjà respectée au départ. Les instructions de contenu décodées pour le texte et les lignes sont restées identiques, mais pas les données de l’image représentant la texture. Sur les pages rendues des résultats issus du fichier image, la position et les dimensions de l’image ainsi que la rotation des pages sont restées identiques à celles de l’original. Un point important si tu examines toi-même les fichiers : dans l’original déjà, l’image générée recouvre plusieurs lignes de texte. Ce chevauchement fait partie du fichier de test et n’est pas un dommage causé par la compression. Il est conservé dans les résultats. Cela ne permet ni de conclure sur la lisibilité de chaque ligne ni d’attribuer une note de qualité. De plus, une image générée avec une texture et un dégradé de couleurs renseigne peu sur la manière dont des photos, des documents numérisés ou du texte en petits caractères dans des documents numérisés réagissent au même niveau. Le guide Réduire la taille d’un PDF numérisé complète ce sujet.

L’emplacement réservé à une signature montre uniquement que le compresseur reconnaît un fichier contenant une structure de signature et ne le traite pas. D’après le code de compression, les fichiers chiffrés et certifiés sont également rejetés. Ce test ne vérifie pas la validité d’une véritable signature et ne contourne aucune protection. Pour en savoir plus, consulte le guide Compresser un PDF contenant des signatures et des formulaires.

Limites et vérification par tes soins

L’outil est-il meilleur que PDF24 ou Adobe ?

Cette page ne répond pas à cette question. Nous n’avons pas fait traiter les mêmes fichiers par d’autres logiciels ou services en ligne. Un jugement comparatif sur la qualité, la vitesse ou le prix ne serait donc pas étayé. Les classements accompagnés de pourcentages ou de curseurs ne remplacent pas non plus une telle comparaison. Une comparaison équitable nécessite le même fichier d’entrée complet, les mêmes pages, des paramètres consignés, des nombres d’octets exacts et les mêmes vérifications fonctionnelles pour tous les résultats.

Comment vérifier ton propre PDF

1. Conserve une copie inchangée de ton original.
2. Ouvre le compresseur PDF et sélectionne le fichier. Si les détails des images sont importants, commence par le mode sans perte.
3. Note la taille exacte en octets de l’original et du résultat, par exemple à partir des propriétés des fichiers, puis calcule la réduction avec le calculateur de taux de compression.
4. Repars du fichier original pour chaque nouvel essai, et non d’un résultat déjà compressé. Enregistre chaque résultat sous un nouveau nom de fichier afin de ne rien écraser.
5. Ouvre le fichier enregistré dans le programme qu’utilise également le destinataire. Vérifie toutes les pages, recherche un mot connu, contrôle les valeurs des champs de formulaire et les liens, puis examine les images et les petits caractères à leur taille d’origine.
6. Si ton PDF est signé numériquement, chiffré ou certifié, ne le compresse pas avec cet outil ; clarifie plutôt la marche à suivre avec l’émetteur.