Convertisseur d'images par lot, gratuit

Convertissez plusieurs images d'un coup entre PNG, JPG et WebP. Ajustez la qualité, comparez les tailles de fichiers et téléchargez tout instantanément.

Vos données ne quittent jamais votre appareil
Déposez les images ici ou cliquez pour parcourir (JPEG, PNG, WebP, GIF, BMP, TIFF)

Traitement en cours…

À propos de la conversion de format d'image

Chaque format d'image a son usage. Le PNG est sans perte, idéal pour les graphismes ; le JPG est parfait pour les photos et offre des fichiers plus petits ; et le WebP propose une compression moderne avec une qualité élevée. La conversion par lot fait gagner du temps pour traiter plusieurs fichiers.

JPEG (1992), le format de la photographie

Le Joint Photographic Experts Group a été formé en novembre 1986 à Parsippany, New Jersey, avec des membres tirés de l’ISO TC97 SC2/WG8 et du groupe CCITT SGVIII. Six ans de travail de comité plus tard, le texte de la Recommandation T.81 du CCITT a été approuvé le 18 septembre 1992, le texte identique étant publié comme Norme internationale ISO/IEC 10918-1 en 1994. Cette double publication est le moment où JPEG est devenu le format photographique du monde. Le cœur mathématique est la transformée en cosinus discrète appliquée à des blocs de 8×8 pixels : chaque bloc est décomposé en une somme d’ondes cosinus, les composantes haute fréquence auxquelles la vision humaine est la moins sensible sont quantifiées plus agressivement que les composantes basse fréquence que l’œil remarque en premier. Le curseur « qualité » côté utilisateur est exactement cela, un multiplicateur sur la table de quantification. Une qualité plus élevée signifie des diviseurs plus petits, plus de précision, des fichiers plus gros. Une qualité plus basse signifie plus de zéros après quantification, un meilleur codage entropique et un fichier plus petit au prix de blocs et d’artefacts de « ringing » visibles. JPEG est lossy par conception : il n’existe aucun réglage de qualité auquel un aller-retour JPEG soit mathématiquement identique à son entrée. Pour les photographies de scènes naturelles (visages, paysages, nourriture, tout ce qui a des dégradés lisses et un ton continu) c’est sans importance ; la perte vit sous le seuil de sensibilité de la vision humaine et le fichier représente une fraction de la taille qu’un format sans perte produirait. Pour des graphiques avec des bords nets, du texte, du line art ou de grandes zones de couleur plate, JPEG est le mauvais choix : le même DCT bave les bords nets avec des artefacts de ringing (« bruit de moustique ») et des frontières en blocs entre les cellules 8×8.

PNG (octobre 1996 / janvier 1997), le format graphique sans perte

PNG (Portable Network Graphics) was developed in 1994 by an informal group outside W3C as a deliberate response to two problems with the existing options: GIF's patent encumbrance (covered below) and TIFF's complexity. The specification was approved as a W3C Recommendation on 1 October 1996, and on 15 January 1997 it was released by the IETF as RFC 2083. A second edition incorporating errata became a W3C Recommendation on 10 November 2003; a third edition adding APNG, HDR support and Exif handling was published on 24 June 2025. PNG is lossless, every encoded byte is recoverable. Internally, a PNG file is a sequence of typed chunks (IHDR header, IDAT compressed data, IEND end-of-file marker, plus optional ancillary chunks for colour profile, transparency, gamma and metadata). Pixel data is preprocessed by one of five row filters (None, Sub, Up, Average, Paeth) chosen per scanline to maximise compressibility, then run through DEFLATE, the same algorithm used in zip files and gzip. PNG supports four colour modes: greyscale, greyscale with alpha, indexed colour (palette of up to 256 entries, what people call PNG-8), and truecolor RGB (PNG-24) with optional 8-bit alpha (PNG-32). The alpha channel supports 256 levels of partial transparency per pixel, which is what makes it possible to anti-alias the edges of icons against any background without the dreaded "white halo" PNG-8 indexed transparency used to produce. PNG was designed as a web format and an archival format simultaneously, and that dual role is why it remains the default for screenshots, logos, line art, charts, and any image where pixel-perfect reproduction matters more than file size.

GIF (15 juin 1987), le survivant de l’animation et la saga des brevets

Steve Wilhite, le responsable d’ingénierie chez CompuServe, a introduit GIF le 15 juin 1987 pour résoudre un problème spécifique : comment partager des images couleur à travers les modems lents du service en ligne CompuServe sans que les fichiers ne dévorent l’allocation mensuelle de l’utilisateur. Son équipe a choisi l’algorithme de compression Lempel-Ziv-Welch (LZW) et a plafonné la palette de couleurs à 256 entrées. Ce que CompuServe ne savait pas en 1987, c’est que LZW avait été breveté par la Sperry Corporation (plus tard Unisys) en 1985. La question des brevets a éclaté publiquement fin 1994. Unisys a annoncé en 1995 qu’elle facturerait des redevances sur les logiciels utilisant l’algorithme (y compris GIF, TIFF et PDF) à des taux d’environ 0,45 % à 0,65 % du chiffre d’affaires. La communauté open-source du web a répondu par deux actions parallèles : la campagne « Burn All GIFs » et la conception de PNG, explicitement conçu pour être un remplacement de GIF libre de brevets. Le brevet US d’Unisys a expiré en juin 2003 ; les brevets correspondants dans d’autres juridictions ont expiré jusqu’en 2004. En 2004, GIF était libre de brevets pour la première fois de son histoire. GIF a survécu grâce à une fonctionnalité que PNG (à l’origine) n’avait pas : l’animation. Il supporte une séquence de frames avec des temporisations par frame et un index de palette transparent, ce qui en fait la lingua franca des images de réaction en boucle et des bannières web. La palette de 256 couleurs est une vraie limitation pour les photos, et la transparence 1-bit produit des bords laids lors de la superposition sur un arrière-plan coloré, mais pour de courtes animations en boucle de contenu type cartoon, GIF gagne encore sur le support universel.

BMP (mai 1990) et TIFF (automne 1986), les survivants hérités

BMP (Bitmap, aussi appelé Windows Device Independent Bitmap) a été incorporé dans Windows 3.0, sorti le 22 mai 1990, où il est devenu le standard pour le stockage de bitmap dans l’environnement graphique Windows. Il est essentiellement non compressé, le tableau de pixels brut, optionnellement aligné sur 4 octets par ligne, avec un petit en-tête en tête. Un BMP 1920×1080 24 bits fait environ 6,2 Mo ; la même image en JPEG qualité 85 ferait peut-être 200 Ko. Le rôle de BMP en 2026 est essentiellement celui d’un format d’interchange hérité et le format que les captures d’écran Windows utilisaient historiquement. TIFF (Tagged Image File Format) a été publié pour la première fois par Aldus Corporation à l’automne 1986 (Révision 3.0) ; la Révision 6.0 en juin 1992 a ajouté la couleur CMYK et YCbCr et JPEG-dans-TIFF. Adobe a acquis Aldus en 1994 et détient désormais le copyright. TIFF est unique en ce qu’il est un format conteneur plutôt qu’un seul schéma d’encodage, un seul fichier TIFF peut contenir plusieurs images (TIFF multi-page, courant pour les fax et les chapitres de livre scannés), utiliser n’importe laquelle de plusieurs méthodes de compression (aucune, LZW, ZIP, JPEG, CCITT Groupe 3/4 pour le fax) et stocker des métadonnées essentiellement arbitraires via sa structure de champs étiquetés. Cette flexibilité fait de TIFF le défaut pour les workflows de prépresse, le scan et l’archivage de documents ; il n’est essentiellement jamais utilisé pour les images web. Sa présence dans la liste d’entrée est pour les utilisateurs convertissant des sources destinées à l’impression ou scannées en formats web-friendly.

WebP (30 septembre 2010), le format web moderne

Google a annoncé WebP le 30 septembre 2010 comme un nouveau format ouvert pour les graphiques true-color compressés avec perte sur le web, produisant des fichiers plus petits que JPEG à qualité comparable. Le format est basé sur l’encodage de keyframe du codec vidéo VP8, que Google avait acquis avec l’achat de On2 Technologies. Initialement WebP était lossy uniquement. Le 18 novembre 2011, Google a annoncé un mode de compression sans perte et le support de la transparence à la fois en mode lossless et lossy ; libwebp 0.2.0 a atteint une implémentation lossless stable le 16 août 2012. Selon la documentation développeur de Google : les images WebP sans perte sont environ 26 % plus petites que les mêmes images en PNG, et les images WebP avec perte sont 25-34 % plus petites que les JPEG comparables à qualité SSIM équivalente. Ces réductions ne sont pas magiques, elles viennent d’une conception de codec fondamentalement plus récente (codage intra-frame prédictif, codage entropique arithmétique moderne, transformations de couleur plus intelligentes) que les bases du début des années 1990 contre lesquelles JPEG et PNG ont été conçus. Le support navigateur s’est construit lentement : Chrome 17 en février 2012 (lossy), Chrome 23 en novembre 2012 (lossless). Apple a tenu bon pendant la majeure partie d’une décennie et a finalement ajouté le support WebP dans Safari 14, qui a été livré avec iOS 14 et macOS 11 Big Sur en septembre 2020. Cette date de septembre 2020 est le moment où WebP est devenu pratiquement utilisable comme format web principal sans fallback JPEG pour les utilisateurs iPhone. La couverture aujourd’hui est d’environ 97 % du trafic mondial, WebP n’est plus un format « moderne » avec réserves, c’est un défaut.

Au-delà de WebP : AVIF (févr. 2019), HEIC (2017), JPEG XL (2018-)

AVIF v1.0.0 a été publié le 19 février 2019 par l’Alliance for Open Media (AOMedia, un consortium de Google, Netflix, Microsoft, Mozilla, Cisco, Intel, Amazon, Apple). C’est le profil image fixe du codec vidéo AV1, construit sur le conteneur HEIF, et c’est actuellement le format d’image largement déployé qui compresse le mieux, à qualité visuelle équivalente, les fichiers AVIF sont typiquement 50 % plus petits que JPEG et 20-30 % plus petits que WebP. Le support navigateur est arrivé en trois vagues : Chrome 85 (août 2020), Firefox 93 (octobre 2021), Safari avec iOS 16 (septembre 2022) et macOS Ventura (octobre 2022). HEIC est le format par défaut de l’iPhone depuis iOS 11 en 2017, le conteneur HEIF avec des images compressées HEVC, formellement ISO/IEC 23008-12. La compression est excellente (typiquement 50 % plus petite que JPEG) mais HEVC est encombré de brevets, ce qui explique pourquoi Chrome, Firefox et Edge non-Apple refusent de décoder HEIC nativement. JPEG XL (ISO/IEC 18181, 2022) est le format techniquement excellent mais de niche, il peut recompresser sans perte les JPEG existants à environ 20 % plus petit, supporte HDR, large gamme, animation et décodage progressif, et est libre de brevets. Chrome a abandonné son flag expérimental le 31 octobre 2022 (la « décision Halloween ») ; Apple a livré Safari 17 en septembre 2023 avec JPEG XL natif sur macOS Sonoma, iOS 17 et visionOS. Le format est supporté nativement dans Safari 17+, derrière un flag dans Firefox et Chrome 145 (février 2026), mais une livraison par défaut pour le trafic général reste en attente. Ce convertisseur n’émet actuellement pas AVIF, HEIC ni JPEG XL, ils sont listés ici pour que vous puissiez décider de les manipuler en amont.

Choisir le bon format de sortie

L’histoire format-par-format ci-dessus est une visite. La question pratique est plus courte : étant donné une image particulière et un usage particulier, quel format de sortie est correct ?

Ce que fait réellement le curseur de qualité

Le curseur de qualité va de 10 à 100 par pas de 5. Derrière ce simple chiffre se cache une relation étonnamment non linéaire entre la qualité perçue et la taille du fichier. Pour JPEG, le consensus de l’ingénierie de traitement d’image est que la qualité 75-85 est le sweet spot. À qualité 80, la taille du fichier chute de 70-90 % par rapport à une source non compressée avec une différence visuelle imperceptible aux distances de visionnage normales d’écran. La chute entre qualité 80 et 85 est raide : une image de test représentative pourrait passer de 3,7 Mo à qualité 80 à 6 Mo à qualité 85, un quasi-doublement pour aucune amélioration visible sur un écran de téléphone ou d’ordinateur portable. Qualité 75 est l’endroit où les artefacts commencent à devenir détectables à l’inspection rapprochée des détails à haute fréquence (bords de texte, textures fines). Qualité 90 et au-dessus, c’est pour les JPEG d’archivage où la taille du fichier est sans importance. Le défaut de 80 se trouve à l’extrémité basse du sweet spot, approprié pour l’optimisation web par lots, où le but est d’expédier le moins de données possible tout en gardant des images qui semblent acceptables. Pour WebP, le défaut de l’API canvas toBlob('image/webp') est qualité 0,80 ; WebP à qualité 70 est généralement aussi visuellement propre que JPEG à qualité 80. Pour PNG, « qualité » est un abus de langage, PNG est toujours sans perte sur les données pixel. Le curseur de cet outil n’a aucun effet lorsque PNG est sélectionné comme format de sortie. La leçon cruciale pour le traitement par lots : un seul réglage de qualité est rarement correct pour chaque image dans un lot mixte. Un dossier de 50 photos prises sur le même appareil dans le même éclairage peut probablement toutes sauvegarder à qualité JPEG 80 sans perte. Un dossier mélangeant captures d’écran, photos, line art et logos ne peut pas, un « convertir tout en JPG-80 » d’un seul clic transformera les captures d’écran en bruit de moustique illisible. Divisez l’entrée en lots séparés quand le contenu varie.

Lossy vs lossless, la distinction la plus importante

Un encodeur sans perte garantit que la sortie décodée est bit-à-bit identique à l’entrée encodée. PNG est lossless. WebP-lossless est lossless. TIFF (dans ses modes lossless) est lossless. Le compromis est la taille du fichier : les encodeurs sans perte ne peuvent pas exploiter les différences perceptuelles imperceptibles et doivent tout préserver. Une photographie 1920×1080 en PNG sans perte pourrait faire 5 Mo ; la même photo en JPEG-qualité-85 fait 200 Ko. Le PNG est bit-parfait ; le JPEG est visuellement équivalent. Un encodeur lossy écarte l’information que le système visuel humain est le moins susceptible de remarquer, détails à haute fréquence, fine variation de chroma dans les couleurs saturées, le quatrième chiffre significatif de chaque dégradé. JPEG, WebP lossy et AVIF lossy font tous cela. Les implications pour un convertisseur par lots sont concrètes : lossless vers lossless (PNG vers PNG, ou PNG vers WebP-lossless) est véritablement sans perte à travers n’importe quel nombre de conversions ; lossy vers lossy à la même qualité (JPEG-85 vers JPEG-85) n’est pas lossless, chaque ré-encodage applique une autre étape de quantification, répétez 10 fois et le résultat est visiblement dégradé ; lossy vers lossless (JPEG vers PNG) fige les artefacts existants en place mais ne les redégrade pas ; lossless vers lossy introduit la compression avec perte au moment de la conversion et il n’y a aucun moyen de récupérer le détail écarté plus tard. Les utilisateurs ré-exécutent souvent une conversion en s’attendant à ce que ce soit un no-op. En dehors du cas lossless-vers-lossless, ce n’est pas le cas.

EXIF, IPTC, XMP, et pourquoi cet outil les retire

Les fichiers JPEG et HEIC des appareils photo et téléphones portent un bloc EXIF, métadonnées Exchangeable Image File Format incorporées dans l’en-tête de l’image. EXIF inclut le modèle d’appareil, l’objectif, les réglages d’exposition, la date et l’heure, la version logicielle, et le plus conséquent les coordonnées GPS de l’endroit où la photo a été prise (si les services de localisation étaient activés au moment de la capture). Les métadonnées IPTC ajoutent légende, byline, copyright et mots-clés. XMP, à l’origine d’Adobe, est un superset basé sur XML qui englobe les formats plus anciens et c’est ce que Lightroom et Photoshop utilisent. Les implications de confidentialité sont significatives. Une photo prise sur un iPhone avec localisation activée incorpore des coordonnées GPS précises à quelques mètres près. La partager sur un forum, en pièce jointe d’e-mail, ou via un blog personnel peut divulguer l’adresse domicile du photographe, l’école de son enfant, son lieu de travail, son itinéraire de randonnée. Les principales plateformes sociales (Facebook, Instagram, Twitter/X) retirent EXIF au téléversement avant de servir l’image à d’autres utilisateurs, mais elles lisent et stockent les métadonnées originales elles-mêmes. Les forums plus petits, blogs WordPress, Discord, clients e-mail et transferts directs de fichiers laissent EXIF intact. Le ré-encodage à travers l’API canvas (le moteur que cet outil utilise) écarte par défaut toutes les métadonnées EXIF, IPTC et XMP. La sortie est une image propre sans provenance incorporée, une fonctionnalité de confidentialité, et un effet de bord du pipeline canvas (le canvas ne stocke que les données pixel ; il n’a aucune notion de métadonnées à préserver). Les utilisateurs qui veulent préserver les métadonnées (photographes archivant les données d’exposition, workflows de contenu où le copyright doit voyager avec le fichier) ont besoin d’un outil différent, typiquement convert d’ImageMagick ou une bibliothèque dédiée consciente d’EXIF. Ce convertisseur coupe dans l’autre sens : il est metadata-stripping par conception, ce qui est exactement ce qu’un utilisateur soucieux de confidentialité veut quand il envoie des images à un forum où il ne veut pas que ses coordonnées GPS suivent.

Arrière-plans transparents, le choix PNG-vers-JPEG

PNG supporte un canal alpha par pixel : chaque pixel a une opacité de 0 (totalement transparent) à 255 (totalement opaque). JPEG n’a pas de canal alpha. Convertir un PNG avec transparence en JPEG force un choix : que doivent devenir les pixels transparents ? Le défaut de l’API canvas est de compositer contre du noir transparent, donc le JPEG résultant résout les pixels transparents en noir opaque. Un logo sur fond transparent converti PNG-vers-JPEG sort avec des coins noirs autour du logo, pratiquement jamais ce que l’utilisateur voulait. La mitigation est de remplir le canvas avec une couleur d’arrière-plan choisie (le blanc est le défaut typique) avant de dessiner l’image dessus. Les utilisateurs qui ont besoin de préserver la transparence devraient choisir PNG ou WebP comme format de sortie. WebP supporte la transparence à la fois en mode lossless et lossy, ce qui en fait le choix moderne quand la source a de la transparence et que la destination doit être efficace, un PNG à fond transparent de 50 Ko pourrait devenir un WebP lossy à fond transparent de 12 Ko tout en préservant le canal alpha.

Comment la conversion tourne dans votre navigateur

L’affirmation « tout tourne dans votre navigateur » repose sur trois API de la plateforme web qui ne sont devenues que récemment assez puissantes pour faire d’un convertisseur d’images par lots un produit côté client crédible. API FileReader et Blob : quand vous déposez des fichiers dans la zone de téléversement, chaque File est une sous-classe de Blob exposant soit readAsDataURL() (callback plus ancien) soit file.arrayBuffer() (basé sur Promise). Pour les images spécifiquement, le chemin plus simple est de construire une URL Blob avec URL.createObjectURL(file) et de l’assigner à un nouvel élément Image, laissant le décodeur d’image intégré du navigateur manipuler JPEG, PNG, GIF, WebP et BMP nativement. L’API Canvas : une fois qu’une Image est chargée, la conversion est une danse en deux étapes, dessiner avec ctx.drawImage(img, 0, 0), puis lire le canvas en retour avec canvas.toBlob(callback, type, quality). Le paramètre type est une chaîne MIME ('image/png', 'image/jpeg', 'image/webp') ; le paramètre quality est un nombre entre 0 et 1 pour les formats lossy. OffscreenCanvas et Web Workers : pour les gros lots, faire tout le travail canvas sur le thread principal bloque l’UI. La solution moderne est OffscreenCanvas, qui expose les opérations canvas dans un contexte worker et est lui-même transférable à un Web Worker via postMessage sans copier. Le worker exécute le pipeline décode-rasterise-encode dans un thread séparé, gardant la page réactive. Ensemble, ces API font qu’un lot de 50 fichiers tourne en quelques secondes sans bloquer le scrolling ou les clics de boutons. JSZip (une bibliothèque pure-JavaScript sous licence MIT) gère le packaging final ZIP entièrement en mémoire avant que la boîte de dialogue de sauvegarde du navigateur ne se déclenche. Pas de téléversement, pas de zip serveur, pas de fichier temporaire sur disque. Il y a une décennie, un convertisseur d’images par lots qui tournait dans le navigateur aurait été une curiosité. La performance WebAssembly, le parallélisme OffscreenCanvas, et la RAM de téléphone moderne (6-12 Go) et le nombre de cœurs (6-8 CPU) ont inversé cette image. L’argument de confidentialité clôt l’affaire : les convertisseurs côté serveur exigent de téléverser vos images sur une machine tierce, et même avec une politique de suppression scrupuleuse, le téléversement lui-même est un événement réseau qui peut être loggé, intercepté ou compromis. Un convertisseur seul-navigateur n’envoie jamais un octet.

Questions fréquentes

Quels formats d'image sont pris en charge ?

Le convertisseur traite la plupart des formats courants (JPG, PNG, GIF, WebP, BMP, TIFF) et convertit vers PNG, JPG ou WebP.

Puis-je ajuster la qualité pour JPG et WebP ?

Oui. Utilisez le curseur de qualité pour ajuster la compression (0-100). Des valeurs plus élevées donnent une meilleure qualité mais des fichiers plus gros.

Comment télécharger plusieurs fichiers ?

Choisissez « Tout télécharger en ZIP » pour regrouper toutes les images converties dans une seule archive ZIP, pratique à télécharger et à stocker.

Pourquoi la limite est-elle de 50 fichiers par lot ?

C’est un plafond mémoire. Chaque image doit être décodée en RAM comme données pixel brutes avant que le canvas puisse la ré-encoder. Une photo iPhone 12 mégapixels se décode en environ 36 Mo de données pixel (12 millions de pixels × 3 octets RGB, ou 4 octets RGBA). 50 d’entre elles d’un coup font 1,8 Go de mémoire de travail. La plupart des laptops gèrent cela confortablement ; les téléphones plus anciens non. Le plafond de 50 fichiers garde la page prévisible à travers les appareils. Pour des lots plus grands, faites tourner l’outil en rounds, disons, 50 fichiers, télécharger, effacer, en déposer 50 autres.

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

Pas de plafond dur, la limite est la mémoire disponible de votre appareil. Une seule image de 50 MP se décode en environ 150 Mo de données pixel, ce qui marche sur un desktop mais aura du mal sur un téléphone plus ancien. Comme règle empirique, les fichiers sous 10 Mo se convertissent sans heurt sur essentiellement n’importe quel appareil ; les fichiers de plus de 50 Mo ralentiront ou échoueront sur les mobiles bas de gamme. Si une conversion fige, rafraîchissez la page et essayez le fichier dans un lot plus petit.

Le convertisseur retire-t-il les métadonnées EXIF ?

Oui, par conception. Le pipeline de ré-encodage canvas ne stocke que les données pixel, donc les blocs de métadonnées EXIF, IPTC et XMP (modèle d’appareil, réglages d’exposition, coordonnées GPS, tags de copyright, historique d’édition) ne survivent pas à l’aller-retour. La sortie est une image propre sans provenance incorporée, ce qui est un gain de confidentialité quand vous partagez des photos sur des forums ou contacts e-mail où vous ne voulez pas que les coordonnées GPS suivent. Si vous avez besoin que les métadonnées soient préservées (photographes archivant les données d’exposition, workflows de contenu nécessitant des tags de copyright), ce n’est pas le bon outil, utilisez convert d’ImageMagick ou une bibliothèque dédiée consciente d’EXIF qui préserve explicitement les métadonnées.

Que se passe-t-il avec les arrière-plans transparents quand je convertis PNG en JPG ?

JPEG n’a pas de canal alpha, donc les pixels transparents dans le PNG source doivent devenir une couleur opaque dans la sortie JPEG. Le comportement par défaut du canvas est de compositer contre un arrière-plan coloré (typiquement blanc). Un logo sur fond PNG transparent converti en JPEG perdra la transparence et prendra le remplissage d’arrière-plan. Si la transparence importe, choisissez PNG ou WebP comme format de sortie, les deux préservent l’alpha. WebP-lossy préserve la transparence à des tailles de fichier dramatiquement plus petites que PNG et est le choix moderne pour les graphiques web transparents.

Mes images sont-elles téléversées quelque part ?

Non. Chaque étape (sélection de fichier, décodage, ré-encodage canvas, packaging ZIP, téléchargement) tourne entièrement dans votre navigateur via JavaScript. Il n’y a pas de traitement côté serveur. Vous pouvez le vérifier en ouvrant l’onglet Réseau des DevTools de votre navigateur pendant que vous convertissez : il n’y a pas de requêtes sortantes portant des données image. La page est sûre pour les captures d’écran sensibles, les scans de documents, les photos personnelles avec métadonnées de localisation, ou tout autre chose que vous ne voudriez pas voir copiée sur le disque dur d’un inconnu.

Outils associés

PDF → HTML

Convertissez du PDF en HTML instantanément.

Encodeur Base64

Encodez des images en Base64.

Texte → CSV

Convertissez des données au format CSV.