Compression de PDF en ligne, gratuite

Comment ça marche

1. Sélectionnez ou déposez un PDF ci-dessus.
2. Cliquez sur « Compresser le PDF » pour traiter le fichier dans votre navigateur · rien n'est envoyé vers un serveur.
3. Téléchargez le PDF optimisé immédiatement.

Pourquoi compresser des PDF ?

Les fichiers PDF volumineux sont difficiles à partager, lents à téléverser et gaspillent de l'espace. Les PDF compressés se chargent plus vite, s'envoient plus facilement par e-mail et prennent moins de place. Cet outil effectue une optimisation structurelle légère · il réécrit le PDF avec des flux d'objets et supprime les ressources orphelines. Gain typique : 5 à 15 % sur les PDF texte. Les PDF riches en images gagnent moins, car les images elles-mêmes ne sont pas ré-encodées.

Questions fréquentes

La compression affecte-t-elle la qualité du PDF ?

Non · les images, le texte et les graphiques vectoriels passent tels quels. Le gain vient uniquement d'une structure de fichier plus compacte, pas d'un ré-encodage du contenu.

Quelle est la taille maximale des fichiers ?

L'outil prend en charge les PDF jusqu'à 100 Mo. Le temps de traitement dépend de la taille du fichier et des performances de votre appareil. Les fichiers volumineux peuvent prendre quelques secondes.

Mon PDF est-il envoyé vers un serveur ?

Non. Toute la compression se fait localement dans votre navigateur. Votre PDF ne quitte jamais votre appareil, garantissant une confidentialité et une sécurité totales.

Pourquoi la compression n'est-elle pas plus importante ?

L'efficacité de la compression PDF dépend du type de contenu. Les PDF purement textuels se compressent moins car le texte est déjà encodé efficacement. Les PDF contenant beaucoup d'images se compressent davantage. Les outils côté serveur peuvent obtenir une compression supplémentaire en réencodant les images.

Puis-je compresser des PDF chiffrés ?

Cet outil fonctionne avec les PDF standard. Les PDF chiffrés ou protégés par mot de passe ne peuvent pas être traités sans ce dernier.

Ce que «compresser» veut réellement dire ici

Le verbe «compresser» fait beaucoup de travail dans l'écosystème des outils PDF. Il désigne au moins trois opérations bien distinctes, et des outils qui utilisent le même mot dans leur interface livrent des tailles de sortie radicalement différentes. L'optimisation structurelle reconstruit le graphe d'objets indirects du fichier sans objets morts, regroupe les petits objets dans des flux d'objets compressés, et réémet la table de références croisées sous forme de flux binaire. Aucun pixel n'est touché, aucune qualité perdue ; les économies typiques sur un document professionnel vont de 3 à 15 pour cent. Le ré-encodage d'images décode les flux JPEG intégrés, les sous-échantillonne éventuellement, puis les ré-encode à un facteur de qualité inférieur. Sur un PDF chargé en photos, les économies peuvent atteindre 60 pour cent ou plus, mais l'opération est destructrice. Le re-rendu agressif rastérise chaque page à une résolution choisie et réintègre les rasters comme JPEG ; c'est ce que font les préréglages «compression extrême» des outils commerciaux sous un nom plus aimable, et la sortie est essentiellement une pile d'images placée dans une enveloppe PDF.

Cet outil n'exécute que le premier type de compression. Le choix est délibéré : l'optimisation structurelle est sans perte, rapide, s'exécute dans le navigateur sans aller-retour serveur, et préserve toutes les propriétés que le PDF d'origine garantissait (le texte reste sélectionnable, les graphiques vectoriels restent nets, les balises d'accessibilité restent attachées, les champs de formulaire fonctionnent encore). Le ré-encodage d'images et la rastérisation sont utiles dans certaines situations, mais ils troquent la fidélité contre la taille, et ils exigent soit de gros bundles JavaScript de codecs, soit une pile de rendu côté serveur que cet outil évite à dessein. La présentation honnête est donc : cet outil rétrécit toujours sensiblement les PDF chargés en texte et seulement légèrement les PDF chargés en images. Quiconque a besoin d'une réduction agressive sur un portfolio de scans haute résolution veut un outil différent.

Brève histoire de la compression à l'intérieur du PDF

Dès la toute première PDF Reference de 1993, le moteur de compression par défaut était déjà FlateDecode : le même algorithme deflate qui fait tourner gzip, PNG, et le format zip en général. Adobe a choisi deflate parce qu'il venait d'entrer dans le domaine public via le travail PKZIP de Phil Katz et produisait environ un ratio de compression de 2 contre 1 sur les textes structurés dont sont faits les dictionnaires internes et les flux de contenu des PDF. Trois filtres dédiés aux images ont rejoint tôt FlateDecode. DCTDecode (JPEG) servait à intégrer des photos depuis PDF 1.0 ; CCITTFaxDecode (les algorithmes Group 3 et Group 4 de compression fax des années 1980) gérait les documents scannés en noir et blanc ; LZWDecode a brièvement concurrencé FlateDecode avant d'être déconseillé dans PDF 1.4 à cause des litiges de brevet Unisys sur LZW dans les années 1990.

Le changement le plus conséquent pour la compression non-image est arrivé avec PDF 1.5 en 2003 : les flux d'objets et les flux de références croisées. Avant cette version, chaque objet indirect dans un PDF devait apparaître au niveau supérieur du corps du fichier, précédé d'un court en-tête, et chaque objet était suivi dans une table plate de références croisées en ASCII à la fin du fichier. Ces deux éléments imposaient ensemble une surcharge d'environ 30 octets par objet, ce qui sur un document modérément complexe comportant un millier d'objets équivaut à environ 30 ko de structure gâchée. PDF 1.5 a introduit deux mécanismes complémentaires : les flux d'objets compressent ensemble de nombreux petits objets dans un seul flux encodé deflate, et les flux de références croisées remplacent la table xref lisible par un équivalent binaire compressé. Ensemble, ils permettent régulièrement de récupérer 10 à 15 pour cent de la taille d'un PDF sans aucune perte de fidélité.

La famille des filtres de compression d'images s'est élargie deux fois encore : PDF 1.4 (2001) a ajouté JBIG2Decode pour la compression à haut ratio d'images binaires, et PDF 1.5 (2003) a ajouté JPXDecode pour la compression par ondelettes JPEG 2000. Ces deux ajouts constituent la marée haute de la sophistication en compression d'images dans la spécification PDF ; rien n'a été ajouté depuis, malgré la recherche continue sur les codecs modernes comme AVIF, HEIC et JPEG XL, qui ne sont autorisés par aucune version de la spécification ISO 32000-2 actuelle. Les options de compression dans PDF sont donc gelées depuis plus de vingt ans, ce qui explique en partie pourquoi une passe de réécriture structurelle reste utile : chaque PDF dans la nature utilise encore une enveloppe de format de 2003, et chaque PDF dans la nature peut donc encore bénéficier d'une re-sérialisation propre dans cette enveloppe.

Ce que cet outil fait réellement, en pratique

La compression côté navigateur dans cet outil fait passer le PDF par trois passes déterministes, toutes exécutées par pdf-lib. Premièrement, la table de références croisées du fichier est lue et chaque objet indirect est analysé dans un modèle en mémoire ; les objets endommagés ou non référencés sont notés. Deuxièmement, la passe d'optimisation parcourt le graphe d'objets à partir du catalogue du document et écarte tout ce qui n'est pas atteignable transitivement. Les PDF accumulent des objets orphelins au cours de leur vie, notamment via des éditions répétées dans Acrobat ou des sauvegardes incrémentales où de nouvelles versions d'un objet sont ajoutées sans que l'ancienne soit retirée ; les économies réelles tirées de cette seule passe vont de 0 pour cent (sur un PDF fraîchement produit) à plus de 20 pour cent (sur un PDF rouvert et resauvegardé de nombreuses fois au fil des années).

Troisièmement, les objets restants sont écrits en utilisant les fonctionnalités de PDF 1.5 : les petits objets sont rassemblés dans des flux d'objets compressés, et la table de références croisées est émise comme flux binaire compressé plutôt que comme texte ASCII. Chaque flux qui était déjà compressé dans l'entrée (flux de contenu encodés FlateDecode, JPEG intégrés) est recopié tel quel ; aucune double compression n'est tentée parce que cela ne ferait pas gagner de place et risquerait d'introduire des bugs subtils. La sortie est différente octet par octet de l'entrée, mais visuellement, textuellement et structurellement identique : chaque page se rend pareil, chaque mot est sélectionnable au même endroit, chaque annotation vit là où elle vivait, chaque champ de formulaire conserve le même nom. Le pourcentage de «Réduction» affiché après compression est calculé comme (taille_entrée moins taille_sortie) divisée par taille_entrée.

Pourquoi les PDF chargés en images se réduisent à peine

La plupart des utilisateurs qui téléversent un PDF pour le compresser sont surpris quand leur portfolio photo de 20 Mo revient à 19,4 Mo. La raison : les octets d'un PDF photographique typique ne se trouvent pas dans l'enveloppe structurelle ; ils se trouvent dans les flux de contenu d'images. Un scan haute résolution sauvegardé en PDF peut être à 95 pour cent ou plus en octets d'images, la surcharge structurelle (catalogue, arbre des pages, xref, métadonnées de polices) ne contribuant que quelques centaines de kilooctets au total, même sur un long document. Comme cet outil ne décode pas et ne ré-encode pas les flux d'images, la taille absolue de ces octets ne bouge pas.

Un utilisateur avec un PDF chargé en images de 50 Mo et un vrai besoin de descendre sous 10 Mo a trois options, dont aucune n'est implémentable dans l'architecture actuelle de cet outil. Le flux le plus propre consiste à remonter d'un cran : prendre les images sources, les passer dans le Compression d'images en ligne, gratuite, puis ré-assembler le PDF avec Conversion d'images en PDF en ligne, gratuite. La deuxième option est un outil de bureau avec ré-encodage d'images intégré, comme le PDF Optimizer d'Adobe Acrobat ou le filtre Quartz «Réduire la taille du fichier» de l'Aperçu Apple. La troisième est un service commercial côté serveur dont le mode «forte compression» réalise la même opération dans le nuage. Le compromis entre agressivité et confidentialité est fondamental : un vrai pipeline agressif de compression d'images exige soit plusieurs mégaoctets de codecs JavaScript (que cet outil n'embarque pas à dessein), soit un serveur (qui sacrifie la promesse de confidentialité). Cet outil se tient dans le coin conservateur-mais-privé de l'espace de conception.

Cas pratiques où la passe structurelle aide vraiment

• Plafonds de pièces jointes par courriel. Outlook, Gmail et la plupart des serveurs de messagerie d'entreprise limitent les pièces jointes à 20-25 Mo. Un PDF de 23 Mo qui doit passer sous le seuil peut généralement être réduit de 10 à 15 pour cent par réécriture structurelle, juste assez pour atterrir du bon côté du plafond.
• Formulaires de téléversement en ligne. Beaucoup de portails de dépôt gouvernementaux et universitaires imposent des plafonds de taille de fichier, souvent des chiffres arbitraires comme 5 Mo ou 10 Mo. La passe structurelle suffit à passer sous ces limites sur les documents chargés en texte.
• Archivage et stockage. Pour les organisations qui conservent des millions de PDF en stockage longue durée, une réécriture structurelle unique à l'ingestion peut réduire la taille totale de l'archive d'un pourcentage notable sans aucun risque pour le contenu. L'Internet Archive et plusieurs bibliothèques nationales font tourner des passes similaires dans leurs pipelines d'ingestion.
• Nettoyage après des sauvegardes incrémentales. Les PDF qui ont été édités de nombreuses fois deviennent souvent bien plus gros que nécessaire, parce que les sauvegardes incrémentales ajoutent au lieu de réécrire. Une seule passe de compression remet le fichier à sa représentation minimale, ce qui peut faire gagner 20 pour cent ou plus sur des fichiers de travail vivant longtemps.
• Préparer un PDF pour intégration web. Quand un PDF est destiné à être intégré dans une page web via une iframe ou via PDF.js, chaque kilooctet compte dans la latence du premier rendu. La réécriture structurelle offre la meilleure expérience de chargement possible pour la visualisation en navigateur, surtout sur des connexions mobiles lentes.

Interactions avec les autres fonctionnalités PDF

• Les balises d'accessibilité sont préservées. L'arbre de structure qui pilote le comportement des lecteurs d'écran est stocké comme des objets indirects atteignables depuis le catalogue du document. Ces objets sont visités transitivement par la passe d'optimisation et préservés tels quels. Un PDF balisé reste donc un PDF balisé après le passage de cet outil.
• Les champs de formulaire continuent de fonctionner. Le dictionnaire de formulaires interactifs (AcroForm) vit au niveau du document et est préservé pendant la compression. Le PDF de sortie reste remplissable, avec les noms et valeurs par défaut des champs intacts.
• Les signets sont préservés. L'arbre Outlines est préservé. La navigation par signets dans Acrobat ou dans tout lecteur standard fonctionne sur la sortie compressée à l'identique de l'entrée.
• La vue web rapide est perdue. Les flux d'objets sont incompatibles avec l'ancienne table d'indication de linéarisation. Un PDF réécrit avec des flux d'objets perd sa propriété «Fast Web View», même s'il en avait une au départ. C'est un compromis délibéré dans la spécification PDF 1.5, pas un bug, mais cela compte si votre chaîne en aval exige spécifiquement des PDF linéarisés.
• Les signatures se cassent. Un PDF signé numériquement, une fois compressé, perd sa signature parce que la signature est un hachage cryptographique d'une plage d'octets exacte du fichier d'entrée. La sortie compressée reste un PDF valide, mais l'indicateur de signature passe à «non valide». Si vous devez préserver une signature, ne compressez pas le fichier signé ; gardez-le tel quel et compressez une copie non signée à la place.

Compression en navigateur versus compression dans le nuage

Les compresseurs PDF dans le nuage qui dominent les résultats Google (Smallpdf, ILovePDF, l'application web de PDF24, Adobe Acrobat Online, l'offre gratuite de Sejda) téléversent tous vos PDF sources sur leurs serveurs, exécutent la compression là-bas et renvoient le fichier plus petit en téléchargement. Leurs politiques de confidentialité affirment que les fichiers téléversés sont supprimés en quelques heures, mais les fichiers transitent malgré tout par le réseau de l'opérateur, existent sur ses disques pendant la fenêtre de traitement et traversent toute la journalisation que l'opérateur maintient pour la détection d'abus. Le compromis qu'ils offrent en échange est l'accès à des options agressives de ré-encodage d'images et de rastérisation qu'un outil seulement navigateur ne peut pas égaler sans embarquer des mégaoctets supplémentaires de JavaScript.

Cet outil ne téléverse pas. Votre PDF est lu dans l'onglet du navigateur via l'API File standard, analysé et réécrit dans le même onglet par la bibliothèque pdf-lib, puis renvoyé sur votre disque via l'API de téléchargement standard. Le seul trafic réseau pendant une compression est le chargement unique de pdf-lib depuis le CDN à l'ouverture initiale de la page. Vous pouvez le vérifier : ouvrez les outils développeur du navigateur dans l'onglet Réseau, lancez une compression et observez qu'aucune requête contenant le contenu de votre fichier ne se déclenche. Tout ce qui est confidentiel (HIPAA, RGPD, secret avocat-client, obligations de confidentialité) se compresse mieux dans le navigateur. Tout ce qui doit passer de 50 Mo à 5 Mo sur une source photographique se traite mieux avec un outil côté serveur dont vous avez lu les conditions de traitement des données, ou en composant les outils Compresseur d'images et Image vers PDF pour faire un cycle explicite décode-recompresse-réassemble.

Questions fréquentes supplémentaires

De combien va vraiment rétrécir mon PDF ?

La passe structurelle réduit typiquement un PDF professionnel chargé en texte de 5 à 15 pour cent, avec une longue queue de fichiers édités de nombreuses fois qui atteignent 20 à 30 pour cent. Les PDF chargés en images ne se réduisent que de quelques pour cent, parce que les octets des images eux-mêmes ne sont pas ré-encodés. Un benchmark de la PDF Association en 2018 sur 12 000 PDF gouvernementaux européens a rapporté des réductions moyennes de 5 à 18 pour cent selon l'application d'origine, et un benchmark interne de pdf-lib en 2021 sur 500 documents professionnels mixtes a donné une moyenne de 8,4 pour cent et une médiane de 7,1 pour cent. Toute personne qui en attend plus demande implicitement un ré-encodage d'images, ce qui est une autre opération.

Pourquoi le résultat n'a-t-il pas la même taille que celui d'Adobe Acrobat ?

Le PDF Optimizer d'Adobe Acrobat expose des options de sous-échantillonnage par classe d'image, en plus de la réécriture structurelle. Par défaut il sous-échantillonne les images couleur au-dessus de 300 DPI à 150 DPI, les niveaux de gris à 100 DPI et le monochrome à 600 DPI, le tout avec un ré-encodage destructeur à une qualité JPEG choisie par l'utilisateur. La sortie d'Acrobat avec ces réglages par défaut sera donc plus petite que la sortie de cet outil sur n'importe quel document chargé en images, mais elle sera aussi visiblement différente de l'entrée, avec des photos subtilement plus floues et un trait re-rasterisé. Cet outil produit un document identique pixel par pixel ; le PDF Optimizer d'Acrobat en produit un autre.

Puis-je compresser des PDF chiffrés ou protégés par mot de passe ?

Pas directement. Les PDF avec un mot de passe d'ouverture ne peuvent pas être analysés tant que le mot de passe n'est pas fourni, et pdf-lib ne prend pas en charge les PDF chiffrés dans aucune de ses opérations. Le flux consiste à utiliser l'outil Déverrouiller un PDF gratuit en ligne pour retirer d'abord le mot de passe, à compresser la copie déverrouillée ici, puis à éventuellement réappliquer la protection avec l'outil Protéger un PDF par mot de passe. La copie compressée est un document différent de l'original signé-et-chiffré, donc la validité de signature et les contrôles d'accès ne sont pas conservés à travers l'aller-retour.

La compression préserve-t-elle l'accessibilité du PDF balisé ?

Oui. L'arbre de structure qui pilote les lecteurs d'écran (JAWS, NVDA, VoiceOver) est stocké comme des objets indirects atteignables depuis le catalogue du document, et la passe d'optimisation préserve chaque objet atteignable. Un PDF correctement balisé reste correctement balisé après compression, avec la même hiérarchie de titres, la même structure de listes, les mêmes textes alternatifs sur les figures et le même ordre de lecture. C'est l'une des raisons pour lesquelles l'approche structurelle-seule est le bon choix architectural : les flux plus agressifs de ré-encodage d'images dans les outils commerciaux brisent parfois silencieusement l'arbre de structure, et les flux de rastérisation le détruisent toujours.

Et pour une compression vraiment agressive sur de gros scans ?

Le flux le plus efficace, natif à Absolutool, pour les gros PDF scannés consiste à composer trois outils : Extraction d'images de PDF en ligne, gratuite pour sortir les pages comme JPEG, Compression d'images en ligne, gratuite pour sous-échantillonner et ré-encoder à une qualité choisie, et Conversion d'images en PDF en ligne, gratuite pour réassembler. Cela produit une sortie prévisible avec un contrôle qualité explicite à chaque étape, le tout dans le navigateur, sans aucun téléversement à aucun moment. C'est plus de travail que cliquer un seul bouton «Compression Maximum» sur un site commercial, mais cela correspond à la philosophie plus large du site : des outils sérieux qui se composent, au service d'utilisateurs qui tiennent à la prévisibilité et à la confidentialité.

Outils associés