Convertir JSON en Markdown en ligne gratuitement

Convertir du JSON en Markdown : transformer un dump imbriqué en quelque chose qui se lit vraiment

Le JSON est un format pour machines que les humains tolèrent. À trois niveaux de profondeur, ça va. À huit niveaux, avec un tableau de 400 objets planté au milieu, vous faites défiler un mur d'accolades en essayant de deviner quel crochet fermant appartient à quoi. Quiconque a déjà ouvert une réponse d'API brute dans un onglet de navigateur connaît la sensation.

Convertir le JSON en Markdown prend cet arbre et le réexprime en document. Les clés d'objets deviennent des titres. Les objets imbriqués deviennent des sections imbriquées. Les tableaux d'enregistrements semblables deviennent des tableaux que vous parcourez des yeux plutôt qu'à coups de Ctrl+F. Déposez un fichier .json dans l'outil ci-dessus et c'est fait en deux secondes — gratuit, sans inscription, limite de 50 Mo, rien n'est conservé de notre côté.

Ce qui arrive à la structure

La conversion est une descente de l'arbre, et chaque construction JSON se projette sur une construction Markdown :

• Les objets deviennent des sections. Une clé de premier niveau comme customer devient un titre, et tout ce qu'elle contient se range dessous. La profondeur devient le niveau de titre, si bien que la hiérarchie que vous deviez déduire de l'indentation est désormais visible d'un coup d'œil.
• Les paires clé/valeur scalaires deviennent des lignes étiquetées. "status": "active" se lit status : active. Guillemets, deux-points et virgules finales disparaissent, et avec eux environ un tiers des caractères d'un fichier typique.
• Les tableaux de scalaires deviennent des listes à puces. Une liste de tags ou d'identifiants cesse de ressembler à une structure de données et se met à ressembler à une liste.
• Les tableaux d'objets uniformes deviennent des tableaux Markdown. C'est le gros morceau, il a sa section plus bas.
• Valeurs vides et nulles. Un champ à null, "" ou [] ne porte presque aucune information mais coûte des tokens sur chaque enregistrement où il apparaît. L'aplatissement replie ce bruit au lieu de le répéter 500 fois.

Ce que le JSON brut fait mal pour un lecteur est précisément ce qu'il fait bien pour un parseur : chaque enregistrement redit chaque clé. Le JSON profondément imbriqué cache sa forme derrière la ponctuation. Le Markdown met la forme en surface.

Les tableaux d'objets uniformes sont le cas idéal

Si votre JSON est une liste d'enregistrements qui partagent tous les mêmes clés — commandes, utilisateurs, produits, entrées de log, résultats de recherche — vous obtenez le meilleur résultat possible : un seul tableau Markdown, les clés en en-têtes de colonnes, une ligne par enregistrement. Deux cents objets qui occupaient 3 000 lignes de JSON brut se replient en 200 lignes de tableau.

L'économie n'est pas cosmétique. En JSON brut, chacun de ces 200 enregistrements répète le nom de champ "created_at", le nom de champ "customer_id", et ainsi de suite. Dans un tableau, chaque nom apparaît exactement une fois, dans la ligne d'en-tête. Pour un LLM qui travaille contre une limite de contexte, c'est la différence entre un jeu de données qui tient et un qui ne tient pas. Le compteur de tokens sous la sortie rend cela concret — convertissez le même fichier dans les deux formats et regardez le chiffre chuter.

Là où ça se dégrade : les enregistrements hétérogènes. Si la moitié de vos objets a un bloc address et l'autre non, ou si un champ est lui-même un objet imbriqué, un tableau plat ne peut pas représenter cela proprement. Vous aurez un tableau plus large avec des trous, ou du contenu imbriqué repoussé dans sa propre section. Si vos données sont authentiquement tabulaires, les exporter d'abord en CSV et passer par le convertisseur CSV vers Markdown donnera en général des tableaux plus nets, parce que le CSV ne peut pas être bancal par construction.

Quand il ne faut pas convertir du tout

Autant être franc, car beaucoup de pages qui vendent des convertisseurs ne le seront pas : un LLM lit le JSON brut parfaitement bien. C'est un format que les modèles ont vu en quantités énormes pendant leur entraînement. Rien ne vous oblige à convertir quoi que ce soit.

Gardez le JSON brut quand les clés exactes comptent. Si vous demandez à un modèle d'écrire du code contre une réponse d'API — une interface TypeScript, un parseur, une fonction de mapping — il lui faut les noms de clés littéraux, l'imbrication littérale et les types littéraux. Le Markdown estompe une partie de tout ça, à dessein. Collez la charge utile brute, ou un échantillon élagué, et laissez le modèle voir ce qu'il va réellement parser.

Convertissez quand un humain est dans la boucle, ou quand les tokens sont comptés. Vous voulez comprendre ce que renvoie une API inconnue. Vous relisez un fichier de configuration écrit par quelqu'un d'autre. Vous donnez un gros export à un modèle et le fichier brut est fait de ponctuation à 40 %. Voilà les cas où un convertisseur JSON vers Markdown mérite sa place. Tout le reste est affaire de goût.

Fichiers minifiés, fichiers indentés et JSON Lines

Trois variantes reviennent sans arrêt et se comportent différemment :

• Le JSON minifié — une ligne gigantesque, aucun espace. C'est le format que la plupart des API renvoient réellement. Illisible pour une personne, et malcommode aussi pour les modèles, faute de retours à la ligne où s'ancrer. C'est ici que la conversion aide le plus : vous passez d'une seule ligne de 200 Ko à un document structuré.
• Le JSON indenté — déjà mis en forme. Plus facile à lire, mais l'indentation elle-même fait désormais des milliers d'espaces en tête de ligne que vous payez en tokens. Le Markdown vous donne la hiérarchie sans la facture d'espaces.
• NDJSON / JSON Lines — un objet JSON complet par ligne, sans tableau englobant. Le standard des logs et des exports en flux. C'est uniforme par nature, donc presque idéal pour une sortie en tableau. Si votre fichier est en .jsonl ou .ndjson, renommez-le en .json ou enveloppez les lignes dans un tableau avant l'envoi.

Un avertissement pratique : un fichier malformé ne se convertira pas. Virgules finales, guillemets simples au lieu de doubles, retours à la ligne non échappés dans les chaînes, ou un NaN égaré sorti d'un export Python — tout cela échoue à la validation. Passez le fichier dans un linter d'abord s'il vient d'un endroit inhabituel.

Où cela sert

• Comprendre une API non documentée. Capturez une réponse réelle, convertissez-la, et vous avez un plan lisible de la forme de la réponse — mieux que la plupart des docs d'éditeurs, et vous pouvez le donner à un modèle comme référence.
• Relire des dumps d'analytics ou d'export. Quelques milliers d'événements d'un outil d'analyse produit deviennent un tableau auquel on peut réellement poser des questions.
• Auditer de la configuration. Manifestes Kubernetes, configs ESLint, réglages de déploiement — convertis en Markdown, l'héritage et les surcharges deviennent évidents comme ils ne le sont jamais dans des accolades imbriquées.
• Écrire de la documentation. La sortie Markdown se glisse directement dans un README, une page de wiki ou un site de docs sans remise en forme.
• Comparer deux charges utiles. Convertissez l'avant et l'après, faites un diff du Markdown. Les changements structurels ressortent bien plus que dans un diff JSON plein de crochets déplacés.

Si le JSON vit dans une base de code, convertissez la base de code

La plupart des fichiers JSON ne sont pas autonomes. C'est un package.json, un fichier de fixtures, un jeu de données d'amorçage, une spec OpenAPI — logé dans un dépôt à côté du code qui le lit. Convertir ce seul fichier isolément donne au modèle les données mais aucun contexte.

Dans cette situation, utilisez plutôt le convertisseur de dépôt GitHub vers texte, ou le convertisseur de dossier local si le projet est sur votre machine et n'est poussé nulle part. Cochez les fichiers JSON plus les fichiers source qui les consomment et vous obtenez un seul bloc de texte contenant les deux côtés de la relation. Il existe aussi une version GitLab. C'est presque toujours le meilleur choix pour tout ce qui touche au développement — le convertisseur de fichier unique est pour le JSON arrivé tout seul.

Questions fréquentes

Comment convertir du JSON en Markdown ?

Envoyez le .json ci-dessus et il revient en Markdown — les objets imbriqués en niveaux de titres, les tableaux d'enregistrements uniformes en tableaux à barres verticales, et les clés en champs étiquetés. Gratuit, 50 Mo par fichier, sans compte. Téléchargez en .md ou copiez dans un document, une issue ou un prompt.

Un tableau d'objets devient-il un tableau Markdown ?

Quand les objets partagent la même forme, oui — c'est le cas que le Markdown gère le mieux. Une liste d'enregistrements aux clés identiques se convertit en tableau à barres verticales avec une colonne par clé, bien plus facile à parcourir que le tableau brut. Les tableaux hétérogènes, où chaque élément a des champs différents, retombent sur des sections, faute de jeu de colonnes cohérent à construire.

Comment l'imbrication profonde est-elle gérée ?

L'imbrication se projette sur la profondeur des titres, et le Markdown s'arrête à ######. Un fichier de configuration imbriqué sur huit niveaux touchera le fond et les couches les plus profondes s'aplatiront dans le niveau au-dessus. Pour des structures aussi profondes, le texte brut ne fait pas pire — rien de lisible n'allait survivre de toute façon.

Est-ce un bon moyen de documenter une réponse d'API ?

C'est un moyen rapide de mettre une vraie charge utile dans une page de docs ou une pull request sans mise en forme à la main. Collez une réponse d'exemple, convertissez, et vous avez un tableau de champs qui s'affiche partout où le Markdown s'affiche. Ce que la conversion ne peut pas deviner : quels champs sont optionnels, ni ce que signifie un type quand une valeur se trouve être null dans votre échantillon.

JSON vers Markdown ou JSON vers texte pour un LLM ?

Le Markdown si la forme porte du sens — vous voulez que le modèle comprenne que ces champs appartiennent à cet objet. Le texte si vous découpez pour des embeddings, où les caractères de syntaxe sont du bruit qui dilue le vecteur. Pour une seule charge utile à faire expliquer, le Markdown se lit mieux et coûte à peine plus.

Markdown ou texte brut, et ce qu'il y a d'autre ici

Si vous ne voulez aucune structure du tout — vous construisez des embeddings, vous indexez pour la recherche, ou vous compressez un fichier au plus petit compte de tokens possible — prenez plutôt la voie JSON vers texte brut. Elle retire entièrement la syntaxe au lieu de la traduire. Le sélecteur de format en haut de cette page bascule entre les deux en transportant le fichier sélectionné, pour essayer les deux sans envoyer deux fois.

Pour les autres formats structurés, XML vers Markdown gère les flux, les charges SOAP et les schémas d'entreprise, et HTML vers Markdown gère les pages web enregistrées. File2Txt est l'entrée générale si vous préférez ne pas choisir de page — il prend aussi les PDF, les fichiers Office, les images et les archives. Il y a un article plus long sur la préparation des fichiers pour les LLM si l'argument général vous intéresse.

Repo2Txt est conçu et maintenu par v12hero, un développeur indépendant qui crée des applications natives et web respectueuses de la vie privée.