Compression d'images en ligne, gratuite

Comment ça marche

1. Sélectionnez ou déposez une ou plusieurs images ci-dessus.
2. Ajustez le curseur de qualité (plus bas = fichier plus petit, compression plus forte).
3. Les images sont compressées dans votre navigateur · rien n'est envoyé à un serveur.
4. Téléchargez les images compressées une par une, ou toutes en même temps.

Pourquoi compresser des images ?

Les images volumineuses ralentissent les sites web, augmentent le taux de rebond et pénalisent votre classement Google. Compresser vos images réduit leur taille de 50 à 80 % avec une perte de qualité visuelle minime. C'est essentiel pour les développeurs web, les blogueurs, les boutiques en ligne et toute personne qui publie du contenu en ligne. Des images plus légères économisent également la bande passante sur mobile et améliorent les scores Core Web Vitals.

Ce que signifie réellement « compresser une image »

La compression d’image recouvre deux opérations fondamentalement différentes qui portent le même nom. La compression avec perte, utilisée par JPEG et WebP en mode avec perte, écarte les données d’image que l’œil humain a peu de chances de remarquer (gradations subtiles dans les ombres, bruit haute fréquence, sous-échantillonnage de la chrominance par rapport à la luminance pour exploiter la perception humaine). La sortie est plus petite que l’entrée mais ne peut pas être reconstruite bit à bit. La compression sans perte, utilisée par PNG, GIF, TIFF-LZW et WebP en mode sans perte, encode les données de pixel exactes de manière plus compacte à l’aide d’algorithmes comme DEFLATE (LZ77 + Huffman). La sortie est plus petite, et la décompression reproduit l’original octet par octet. Laquelle est appropriée dépend de l’image : les photographies tolèrent magnifiquement le mode avec perte parce que leur contenu regorge de textures que l’œil ne suit pas au niveau du pixel ; les logos, captures d’écran et graphiques avec des transitions de couleur nettes exigent le sans perte parce que chaque pixel est intentionnel.

Les réglages de qualité dans un compresseur JPEG (le curseur de cet outil, de 10 à 100 %) contrôlent les tables de quantification appliquées après l’étape DCT. À une qualité de 100, les tables n’arrondissent presque aucun coefficient de fréquence ; à une qualité de 50, elles arrondissent agressivement. Une qualité plus élevée signifie des fichiers plus gros avec des détails plus fins ; une qualité plus basse signifie des fichiers plus petits avec des artefacts en blocs visibles dans les zones plates. La valeur par défaut de 60 % se situe dans le point idéal pour le web : généralement une réduction de la taille du fichier de 50 à 80 % sans changement perceptible sur un écran typique. Pour le travail d’impression ou les grands écrans, montez à 80-90 %. Pour les vignettes ou les versions adaptées au courrier, 30-50 % convient.

Pour PNG, le curseur de « qualité » ne s’applique pas au sens habituel parce que PNG est toujours sans perte. Ce que cet outil fait réellement sur une entrée PNG, c’est exécuter une passe DEFLATE plus poussée que celle que la plupart des logiciels d’édition (Photoshop, Affinity, Sketch) ne prennent la peine de faire par défaut ; cela permet généralement de gagner 5 à 25 % sur la taille du fichier sans aucun changement de pixel. Le menu Format permet aussi de convertir PNG vers JPEG ou WebP, ce qui échange le sans perte contre un fichier bien plus petit mais perd la transparence pour la sortie JPEG et (pour du contenu photographique) la garantie de sans perte pour WebP. L’option Largeur maximale redimensionne les images pendant la compression : une photo de 4000 pixels de large réduite à 1920 pixels économise 75 % du nombre brut de pixels avant même qu’une compression ne s’exécute, et cela s’ajoute à la réduction de qualité.

Comment cet outil fonctionne en coulisses

Le moteur de compression est browser-image-compression de Donald Wong (GitHub : Donaldcwl/browser-image-compression, licence MIT). C’est une bibliothèque en JavaScript pur, environ 95 Ko minifiée, qui enveloppe trois primitives du navigateur : l’API File pour lire les octets, l’API Canvas (ou OffscreenCanvas quand disponible) pour décoder, redimensionner et ré-encoder les images JPEG/WebP, et UZIP (une petite bibliothèque DEFLATE) pour traiter le PNG sans passer par Canvas. Quand vous déposez une image, le navigateur transmet les octets à la bibliothèque ; la bibliothèque choisit le chemin en fonction du format d’entrée et de la sortie demandée.

Pour les entrées JPEG et WebP, le chemin est : décoder vers un canvas, redimensionner éventuellement à la Largeur maximale configurée, puis appeler canvas.toBlob(mimeType, qualité/100). L’encodeur JPEG ou WebP intégré au navigateur fait la véritable quantification et le codage de Huffman. La qualité est la valeur de votre curseur divisée par 100, passée en deuxième argument. Pour une entrée PNG conservée en PNG, la bibliothèque évite Canvas entièrement (un aller-retour par Canvas re-rasteriserait inutilement les données sans perte) et exécute à la place UZIP sur les blocs IDAT du fichier PNG directement, avec un effort de compression maximal. C’est pourquoi la compression PNG-vers-PNG est ici réellement sans perte : les données de pixel ne sont jamais décodées et ré-encodées, seul l’emballage DEFLATE est resserré.

Quand OffscreenCanvas est pris en charge (Chrome, Edge, Safari, Firefox modernes), le gros travail de décodage-redimensionnement-encodage s’exécute dans un Web Worker, gardant le fil d’interface utilisateur principal réactif. Vous pouvez déposer un lot de 20 photos et continuer à faire défiler la page pendant que chacune est traitée. Sur les navigateurs plus anciens, la bibliothèque revient au fil principal, ce qui fonctionne toujours mais bloque la page pendant les gros traitements. L’ensemble du pipeline s’exécute à l’intérieur de votre onglet. La bibliothèque est chargée une fois depuis un CDN (environ 95 Ko minifiée) à la première visite, puis mise en cache. Aucun contenu de fichier ne quitte jamais le navigateur. Ouvrez l’onglet Réseau dans les outils de développement pendant que vous compressez un lot et vous verrez le chargement unique de la bibliothèque mais rien d’autre.

Bref historique des formats de compression d’images

• DCT, 1972-1974. Nasir Ahmed a proposé la transformée en cosinus discrète comme méthode de compression d’image en 1972 ; l’algorithme formel a été publié avec T. Natarajan et K. R. Rao en 1974. Cette unique transformation mathématique se trouve sous chaque fichier JPEG, MPEG et H.26x dans le monde aujourd’hui.
• JPEG, 1992. Le Joint Photographic Experts Group (formé en 1986) a standardisé JPEG sous les références ITU-T T.81 / ISO/IEC 10918-1 en 1992. Blocs DCT 8x8, espace de couleur YCbCr avec sous-échantillonnage chromatique optionnel, tables de quantification calibrées pour la vision humaine. Le format qui a rendu possible le web riche en photos.
• PNG, 1996. Créé à l’IETF sous la référence RFC 2083 pour remplacer GIF après que les revendications de brevet LZW d’Unisys ont menacé le web ouvert. Compression DEFLATE (LZ77 + Huffman), toujours sans perte, transparence alpha complète, sans encombre de brevet. La spécification de 3e édition (W3C, 2023) a ajouté officiellement le HDR, l’animation APNG et les métadonnées EXIF.
• WebP, 2010. Google a publié WebP comme format d’image fixe basé sur le codage intra-image du codec vidéo VP8. WebP avec perte est 25 à 34 % plus petit que JPEG à qualité visuelle comparable ; WebP sans perte est environ 26 % plus petit que PNG. L’adoption a pris une décennie ; en 2026 plus de 96 % des navigateurs dans le monde le prennent en charge.
• AVIF, 2019. L’Alliance for Open Media a publié AVIF comme variante image fixe du codec vidéo AV1. Environ 50 % plus petit que JPEG à qualité comparable. La prise en charge par les navigateurs est désormais à plus de 95 %, mais celle des encodeurs dans les outils d’édition courants (Photoshop, Word, Slack) traîne. Squoosh et ImageMagick peuvent produire de l’AVIF aujourd’hui ; la plupart des appareils photo et téléphones ne le peuvent pas.
• HEIC, 2017. Apple a adopté HEIC, basé sur HEIF/H.265, comme format photo par défaut de l’iPhone. Environ moitié moins lourd que le JPEG équivalent. Encombré de redevances, donc rarement servi sur le web ouvert. La plupart des outils de téléversement en ligne (y compris celui-ci) n’acceptent HEIC qu’après une conversion vers JPEG sur ordinateur ; cette conversion est le flux quotidien pour envoyer des photos de téléphone à un destinataire non-Apple.

Formats pris en charge

• JPEG · Idéal pour les photos et les images complexes. Compression avec perte et qualité ajustable.
• PNG · Idéal pour les graphiques, les logos et les images avec transparence.
• WebP · Le format moderne de Google, offrant des fichiers plus petits que JPEG/PNG à qualité comparable.

Flux de compression du monde réel

• Images de blog et de site web. Un JPEG de 2 Mo sorti directement d’un téléphone face à un JPEG compressé de 250 Ko : identiques à l’œil humain sur un écran typique, mais le fichier plus petit se charge à peu près 8 fois plus vite. Les scores Core Web Vitals (LCP) s’améliorent directement. La plupart des pages avec plusieurs photos voient les plus gros gains de performance Lighthouse via la compression d’image, pas via l’optimisation JavaScript ou CSS.
• Téléversements sur les réseaux sociaux. Instagram, Twitter, Facebook, LinkedIn recompressent tous les images au téléversement avec leurs propres algorithmes. Compresser d’abord vous donne le contrôle de ce qui est sacrifié ; téléverser des photos brutes laisse la plateforme faire ces choix à votre place, souvent avec une dégradation visible.
• Pièces jointes d’e-mail. La plupart des fournisseurs plafonnent les pièces jointes à 25 Mo par message (Gmail, Outlook, Apple Mail). Compresser un dossier de photos d’environ 50 Mo à environ 10 Mo permet de tout envoyer en un seul e-mail au lieu de répartir sur plusieurs envois ou de passer à un lien de partage cloud.
• Photos de produits e-commerce. Les catalogues de produits avec des centaines ou des milliers de photos entraînent de grosses factures de bande passante CDN et des chargements de page lents. Compresser toute la bibliothèque réduit les deux. Les vendeurs Shopify, Etsy et Amazon compressent couramment avant le téléversement pour baisser les coûts d’hébergement et améliorer le classement dans les recherches.
• Portfolios riches en captures d’écran. Les portfolios de design d’interface sont riches en PNG parce que les captures d’écran ont des transitions de couleur nettes où les artefacts JPEG seraient visibles. PNG-vers-PNG via un DEFLATE plus serré économise généralement 10 à 20 % sans changement de pixel, utile pour les sites de portfolio de designer qui doivent rester rapides sans sacrifier la qualité de rendu.
• Réduction d’archives. Une photo de 12 mégapixels d’un téléphone est exagérée pour un album familial qui ne sera jamais regardé que sur écran. Redimensionner à 4 mégapixels à 80 % de qualité : le résultat est identique sur tous les appareils qui le verront, et l’archive descend à un cinquième de la taille d’origine. Les originaux restent en sécurité sur le disque source ; les versions compressées partent vers le partage ou la sauvegarde.

Pièges courants et ce qu’ils signifient

• Recompresser plusieurs fois un JPEG le dégrade. Chaque enregistrement JPEG réexécute l’étape de quantification DCT, perdant des détails que vous ne pourrez jamais récupérer. Les pertes sont subtiles au premier passage et évidentes au troisième ou quatrième. Compressez toujours depuis la source de plus haute qualité dont vous disposez (le fichier brut de l’appareil photo, l’exportation depuis votre outil de design), pas depuis un JPEG déjà compressé enregistré la semaine dernière. Si vous devez faire des ajustements, gardez une copie maîtresse en PNG ou TIFF.
• PNG vers JPEG perd la transparence. JPEG n’a tout simplement pas de canal alpha dans la spécification du format. Tout pixel transparent devient blanc plein (ou ce que votre encodeur substitue) lors de la conversion de PNG vers JPEG. Pour les logos, icônes, captures d’écran avec arrière-plans transparents ou tout graphique avec un canal alpha, restez en PNG ou passez à WebP, qui préservent tous deux la transparence.
• JPEG vers PNG agrandit le fichier. La compression DEFLATE de PNG excelle sur les gradients lisses et les grandes zones unies, et est terrible sur les motifs de bruit haute fréquence que la compression JPEG laisse derrière elle. Convertir un JPEG en PNG double ou triple souvent la taille du fichier sans aucun gain de qualité. Si vous avez besoin du sans perte à partir d’un JPEG, il est déjà trop tard : l’information d’origine a disparu. La conversion n’a de sens que si vous avez spécifiquement besoin de la transparence PNG ou d’un outil qui n’accepte pas JPEG.
• Les métadonnées EXIF sont retirées par défaut. La bibliothèque browser-image-compression abandonne par défaut les métadonnées EXIF (infos appareil, coordonnées GPS, date de prise, profil colorimétrique ICC) pendant la recompression. Pour le web c’est généralement une fonctionnalité (la fuite de coordonnées GPS est un vrai problème de confidentialité). Pour les photographes archivant avec métadonnées intactes, cet outil n’est pas le bon ; utilisez un compresseur de bureau comme ImageOptim ou jpegtran avec l’option explicite « préserver les métadonnées ».
• Les profils colorimétriques peuvent ne pas survivre. Un profil colorimétrique ICC intégré (sRGB, Adobe RGB, ProPhoto) indique aux écrans comment interpréter les valeurs de pixels. Le ré-encodage basé sur Canvas peut écarter le profil intégré et marquer la sortie comme sRGB. Pour un usage écran ordinaire c’est très bien parce que presque tout est en sRGB de toute façon. Pour le travail de préparation d’impression, la préparation de photos avec gestion des couleurs ou les livrables à large gamme, utilisez un outil sensible à la couleur (Export Sous de Photoshop, Affinity, RawTherapee) qui préserve explicitement les données de profil.
• Les très grandes images peuvent faire planter un onglet de navigateur mobile. Décoder une image vers Canvas demande de la RAM proportionnelle à ses dimensions : une photo de 24 mégapixels (6000x4000 pixels) demande environ 96 Mo rien que pour le tampon de pixels RGBA, plus la mémoire de travail de l’encodeur. Les appareils mobiles avec 4 Go de RAM peuvent voir l’onglet terminé par l’OS avant la fin de l’encodage. Redimensionnez l’entrée ou utilisez un navigateur de bureau pour les très grandes photos.

Confidentialité : les images restent sur votre appareil

Chaque compresseur d’image cloud (TinyPNG, Compressor.io, Optimizilla, les outils image de Smallpdf, le point de terminaison de compression de Pixlr, les dizaines de services « compresser image en ligne ») téléverse votre fichier sur les serveurs de l’opérateur, exécute son algorithme de compression et renvoie l’image plus petite en téléchargement. Les implications pour la confidentialité ne sont pas triviales parce que les photos contiennent régulièrement du contenu identifiable : visages, adresses visibles à l’arrière-plan, captures d’écran d’interfaces internes ou de documents confidentiels, photos d’enfants, photos prises dans des espaces privés. La plupart des opérateurs publient des politiques de confidentialité s’engageant à supprimer les téléversements dans une heure ou deux et à chiffrer en transit, et les plus gros (TinyPNG, Smallpdf) détiennent la certification ISO/IEC 27001. Ils ont de fortes raisons commerciales d’honorer ces politiques. Mais « supprimé dans l’heure » n’est pas « jamais vu ». Pendant cette heure le contenu de l’image se trouve dans l’infrastructure de l’opérateur, accessible à tout processus ou personne disposant des accès appropriés, et visible dans les journaux et sauvegardes selon la politique de rétention applicable.

Ce compresseur ne téléverse jamais rien. La bibliothèque browser-image-compression s’exécute entièrement dans votre onglet ; les octets d’image sont lus par l’API File, traités en JavaScript (ou dans un Web Worker si OffscreenCanvas est disponible), et la sortie compressée est renvoyée au même onglet sous forme de Blob téléchargeable. Vous pouvez vérifier l’absence de téléversement en ouvrant les outils de développement du navigateur sur l’onglet Réseau avant de compresser un lot : aucune requête ne part avec votre contenu d’image. Le seul trafic réseau est la récupération unique de la bibliothèque (~95 Ko) depuis le CDN à la première visite, après quoi la bibliothèque est mise en cache. Passez le navigateur en mode avion après le chargement de la page et le compresseur continue à fonctionner sur les fichiers locaux. Pour les photos contenant quoi que ce soit de sensible (visages, lieux, captures d’écran internes), le compromis côté navigateur vaut clairement la peine d’être fait.

Quand un autre outil est le bon choix

• Traitement par lot de plus de 500 images dans un pipeline scripté. Utilisez sharp dans Node.js (la bibliothèque côté serveur de référence pour les images), ImageMagick ou GraphicsMagick en ligne de commande, ou Pillow en Python. Ces outils gèrent des milliers de fichiers sans limites mémoire du navigateur et tournent depuis des tâches CI, des hooks de déploiement ou des tâches cron.
• Garanties strictes de sans-perte avec égalité de bits vérifiable. Pour PNG vers PNG, cet outil est réellement sans perte parce que UZIP ne touche pas aux données de pixel. Pour les flux exigeant une vérification cryptographique (imagerie médicale, preuves légales), utilisez un outil de bureau comme ImageMagick avec `-define png:compression-level=9` explicite et une vérification SHA-256 des données de pixel décodées.
• Préservation des profils colorimétriques de qualité impression. Adobe Photoshop, Affinity Photo ou RawTherapee pour le travail de préparation à l’impression avec préservation des profils ICC, simulation d’épreuves et sortie CMJN. La compression basée sur le navigateur ne peut pas garantir des flux à gestion des couleurs parce que Canvas opère en sRGB et peut écarter les données de profil intégrées.
• Sortie AVIF pour une compression nouvelle génération. browser-image-compression ne produit pas d’AVIF en 2026. Pour l’encodage AVIF dans le navigateur, utilisez Squoosh (aussi Google, aussi côté client) ; pour AVIF en ligne de commande, utilisez avifenc de libavif. AVIF produit des fichiers à peu près 50 % plus petits que JPEG à qualité comparable, mais l’encodeur est coûteux en calcul (10 fois plus lent que l’encodage JPEG).

Questions fréquentes

La compression réduit-elle la qualité de l'image ?

À la qualité par défaut de 60 %, la plupart des images paraissent quasi identiques à l'original, tout en étant 50 à 80 % plus légères. Ajustez le curseur pour trouver le bon équilibre selon vos besoins.

Y a-t-il une limite de taille de fichier ?

Chaque image peut peser jusqu'à 50 Mo. Comme le traitement se fait dans votre navigateur, les fichiers très volumineux peuvent prendre un instant selon votre appareil.

Mes images sont-elles envoyées à un serveur ?

Non. L'intégralité de la compression se fait localement dans votre navigateur. Vos images ne quittent jamais votre appareil, ce qui rend l'outil totalement privé et sécurisé.

Quel réglage de qualité dois-je utiliser ?

Pour le web, 60 à 70 % est idéal. Pour l'impression ou un portfolio, essayez 80 à 90 %. Pour une compression maximale (miniatures, e-mails), 30 à 50 % convient très bien.

Autres questions fréquentes

Pourquoi ma sortie PNG n’est-elle qu’un peu plus petite que l’original ?

PNG est sans perte. Les économies viennent entièrement de la recherche d’une compression DEFLATE plus serrée des mêmes données de pixel, ce qui économise généralement 5 à 25 % par rapport à ce qu’un outil d’édition (Photoshop, Sketch, Figma) a écrit par défaut. Si votre PNG était déjà bien optimisé, il ne reste pas beaucoup de marge. Pour obtenir une réduction supplémentaire significative, soit convertissez en WebP (qui conserve la transparence et est généralement 25 % plus petit que PNG), soit acceptez une certaine perte en convertissant en JPEG (qui peut être beaucoup plus petit mais perd la transparence).

Cet outil fonctionne-t-il hors ligne ?

Après la première visite, oui. La bibliothèque browser-image-compression (environ 95 Ko minifiée) est mise en cache par le navigateur au premier chargement. Les visites suivantes au compresseur fonctionnent entièrement hors ligne, tant que le cache du navigateur n’a pas été vidé entre-temps. Vous pouvez vérifier en activant le mode avion après avoir ouvert la page une fois et en compressant une image locale.

Mes données EXIF (appareil, GPS, date de prise) seront-elles préservées ?

Non, les métadonnées EXIF sont retirées pendant la compression par défaut. Pour le partage web c’est généralement souhaitable (les coordonnées GPS et les numéros de série d’appareil photo ne devraient pas fuiter), mais pour les photographes archivant avec métadonnées intactes, cet outil n’est pas le bon. Utilisez un compresseur de bureau conscient des EXIF comme ImageOptim (macOS) ou jpegtran avec l’option `-copy all` pour préserver les métadonnées.

Quelle est la différence entre le redimensionnement Largeur maximale et la réduction de qualité ?

Le redimensionnement change les dimensions en pixels de l’image : une photo 4000x3000 redimensionnée à 1920x1440 a 75 % de pixels en moins à encoder, ce qui réduit la taille du fichier avant même qu’une compression ne s’exécute. La réduction de qualité (le curseur) contrôle à quel point l’encodeur JPEG ou WebP arrondit ses coefficients DCT, ce qui rend les données encodées plus petites par pixel. Les deux s’ajoutent : redimensionnez d’abord pour réduire le nombre global de pixels, puis réduisez la qualité de ce qui reste. Pour un flux « rendre cette image adaptée au web » typique, réglez Largeur maximale à 1920, qualité à 70, et la sortie représente environ 10 à 15 % de la taille d’origine.

Puis-je compresser des images HEIC de mon iPhone ?

La prise en charge du décodage HEIC par les navigateurs est limitée (Safari sur appareils Apple le fait ; Chrome et Firefox non). Sur les navigateurs non-Apple cet outil refusera les fichiers HEIC. Le flux pour les photos d’iPhone consiste soit à changer le réglage de l’iPhone (Appareil photo → Formats → Le plus compatible) pour enregistrer directement en JPEG, soit à convertir HEIC en JPEG une fois sur un Mac ou avec un outil dédié, puis à passer ces JPEG dans ce compresseur. La feuille « Partager via » d’iCloud convertit généralement automatiquement en JPEG quand on partage vers des destinataires non-Apple.

Existe-t-il un équivalent de bureau ou en ligne de commande ?

Plusieurs. Pour l’automatisation par lot, sharp dans Node.js est la bibliothèque côté serveur de référence et produit une sortie quasi identique. ImageMagick (magick input.jpg -quality 70 output.jpg) et GraphicsMagick gèrent d’énormes fichiers et tournent depuis n’importe quel shell. jpegoptim et optipng sont des ré-encodeurs spécialisés JPEG et PNG qui grignotent souvent quelques pour cent supplémentaires par rapport aux outils génériques. Pour un travail interactif ponctuel comme cet outil mais avec plus de contrôles, Squoosh (Google Chrome Labs, également entièrement côté client) prend en charge une gamme plus large de formats, y compris AVIF.

Outils associés