Vérifiez vous-même : ce que vous déposez ici n'est pas téléversé
Vous ne devriez pas avoir à nous croire sur parole. Chaque affirmation de ce site sur le traitement local se vérifie en moins d'une minute avec des outils déjà présents dans votre navigateur.
Ci-dessous : comment vérifier le moteur vous-même, la liste complète des requêtes réseau de ce site (y compris celles qui quittent ce domaine), les moteurs open source derrière chaque fonction, et les limites que nous reconnaissons.
1. Trois façons de le vérifier vous-même
Test hors ligne : chargez une fois une page de conversion, passez l'appareil en mode avion — ou cochez « Offline » dans DevTools → Réseau — puis convertissez quand même un .docx. Cela fonctionne toujours, car le moteur tourne déjà sur votre machine. Un outil qui dépendrait de nos serveurs échouerait immédiatement.
Onglet Réseau : ouvrez DevTools → Réseau, videz la liste, puis convertissez un fichier. Vous verrez les téléchargements du moteur depuis ce même domaine (/pandoc.wasm, /pdf-inspector.wasm, /pdf.worker.min.mjs) et rien d'autre. Filtrez sur Fetch/XHR : un envoi apparaîtrait comme un POST vers un domaine tiers. Il n'y en a aucun.
Aucun backend n'existe pour recevoir quoi que ce soit : ce site est un paquet statique de fichiers HTML, JavaScript et WebAssembly. Cherchez dans le code source un point d'envoi ou une clé API — il n'y a ni l'un ni l'autre. Si vous trouvez un jour une requête transportant votre document, le débat est tranché contre nous.
2. Toutes les requêtes émises par ce site
Nous préférons lister les exceptions plutôt que de vous laisser les découvrir. Les binaires du moteur sont servis depuis ce domaine puis mis en cache par votre navigateur : /pandoc.wasm (environ 56 Mo, le vrai compilateur Pandoc, téléchargé une fois), /pdf-inspector.wasm (environ 6 Mo, le moteur PDF) et /pdf.worker.min.mjs (environ 1 Mo, le worker pdf.js utilisé pour l'OCR).
Trois types de ressources viennent en revanche du CDN jsDelivr : le worker, le core et le modèle de langue de tesseract.js — uniquement lorsque vous utilisez l'OCR et seulement pour la langue choisie ; KaTeX (~340 Ko) pour le rendu des formules dans l'aperçu HTML et en Markdown → PDF ; et Mermaid (~1 Mo) seulement si un document contient un bloc de diagramme Mermaid.
Aucune de ces requêtes ne transporte votre document ni son contenu. Ce sont de simples requêtes GET de code de bibliothèque et de données de langue OCR. Vérifiez-le dans les DevTools : sélectionnez la requête et assurez-vous que Payload / Request body est vide.
3. Ce qui tourne réellement dans votre navigateur
Word, ODT, EPUB, HTML, reStructuredText, LaTeX, CSV et d'autres formats sont convertis par Pandoc compilé en WebAssembly — le même moteur que l'outil en ligne de commande, exécuté dans un thread d'arrière-plan. L'entrée PDF passe par pdf-inspector (Rust → WebAssembly) et pdf.js ; le texte scanné ou photographié est reconnu par tesseract.js. Markdown → PDF utilise la boîte d'impression de votre navigateur.
Tous les moteurs sont open source et figurent avec leur licence sur la page Conditions d'utilisation : Pandoc et le core pandoc-wasm embarqué sont sous GPL, pdf-inspector sous MIT, pdf.js et tesseract.js sous Apache-2.0. Comme ces moteurs sont livrés à votre navigateur, le code source correspondant est le projet qui y est lié.
Il n'y a aucun service de conversion propriétaire au milieu, aucune clé API facturée à l'usage et aucun compte. C'est pourquoi la conversion par lots et les options Pro (citations, filtres Lua, modèles personnalisés) fonctionnent encore avec le câble réseau débranché.
4. Limites assumées
La première visite télécharge le moteur : environ 56 Mo de WebAssembly, mis en cache ensuite. Sur une connexion lente, la première conversion peut prendre du temps — un convertisseur côté serveur vous le cacherait ; nous ne le pouvons pas.
Le mode hors ligne ne fonctionne qu'après cette première visite. Un appareil neuf sans aucun réseau ne peut rien convertir, car le moteur n'a jamais été mis en cache.
L'OCR télécharge son modèle de langue depuis le CDN jsDelivr lors de la première utilisation d'une langue (environ 2–15 Mo chacune) et reste bien plus lent que l'extraction native de texte. Les pages scannées, l'écriture manuscrite et les photos à faible contraste sont les cas les plus difficiles.
La conversion entre formats de documents est naturellement destructive : mises en page complexes, colonnes, zones de texte, suivi des modifications, commentaires et certaines équations ne survivent pas à tous les chemins. Relisez toujours le résultat avant de vous y fier.
Word → PDF n'est pas proposé. La sortie PDF via LaTeX est une fonctionnalité de la ligne de commande Pandoc, et Markdown → PDF se limite à ce que la boîte d'impression du navigateur peut produire — pas d'options d'incorporation de polices, pas d'édition des métadonnées PDF.
Il n'y a ni API REST, ni CLI, ni point d'accroche d'automatisation. Si vous avez besoin de conversion côté serveur à grande échelle, exécutez Pandoc en local : c'est le même moteur que celui utilisé par ce site.
5. Toujours pas convaincu ? Reproduisez les vérifications
Dans un terminal, curl -s https://wordtomarkdown.com/en/ | grep -oE 'https://[a-zA-Z0-9.-]+' | sort -u liste tous les hôtes référencés par cette page. Vous verrez ce domaine et https://schema.org — ce dernier est un identifiant JSON-LD lu par les moteurs de recherche, pas une requête — et aucun point d'envoi.
Dans les DevTools, ouvrez l'onglet Réseau, convertissez un fichier, puis cliquez sur une requête pour inspecter son onglet Payload. Un payload vide sur toutes les requêtes signifie que rien n'a été envoyé : le seul trafic consiste à télécharger du code et des modèles.
Si vous trouvez une requête qui contredit cette page, dites-le-nous via la page Contact. Nous corrigerons la page plutôt que de discuter.