Convertir JSON en Texte en ligne gratuitement

Convertir du JSON en texte brut : retirer la syntaxe, garder le contenu

Ouvrez un export JSON dans un éditeur de texte et comptez ce qu'il y a vraiment dedans. Des accolades, des crochets, des guillemets sur chaque clé et chaque valeur de chaîne, une virgule après chaque paire, des deux-points entre les deux, et dans un fichier indenté, des milliers d'espaces en tête de ligne. Sur un export typique bourré d'enregistrements, une grande part des octets sont des caractères structurels qui ne portent aucune information qui vous intéresse.

Cette page fait une seule chose : elle prend un fichier .json et vous rend le contenu lisible, débarrassé de tout ça. Pas de titres, pas de tableaux, pas de barres verticales — juste les valeurs, dans l'ordre, avec assez d'étiquetage pour rester intelligibles. C'est la bonne sortie quand la destination est un modèle d'embedding, un index de recherche, un script d'analyse de texte, ou n'importe quelle chaîne où la ponctuation est du bruit. Gratuit, sans inscription, jusqu'à 50 Mo, rien n'est stocké.

Ce qui est retiré, ce qui survit

Les règles sont assez simples pour tenir en tête, ce qui compte au moment de décider si la sortie conviendra à votre chaîne de traitement :

• Disparu : chaque {, }, [, ], guillemet, virgule et deux-points. Ainsi que l'indentation, qui dans un fichier mis en forme peut représenter une fraction surprenante de la taille totale.
• Conservé : les valeurs de chaînes, les nombres, les booléens — la charge utile.
• Conservé, mais aplati : les noms de clés. Ils restent en courtes étiquettes plutôt que d'être supprimés purement et simplement, parce qu'un refund_reason devant une phrase est réellement informatif, pour un lecteur comme pour un modèle d'embedding. Ce qui disparaît, c'est le chemin d'imbrication, pas le nom.
• Replié : null, les chaînes vides et les tableaux vides. En JSON brut, ils se répètent sur chaque enregistrement qui les contient ; dans la sortie texte, ils cessent d'occuper de la place.
• Linéarisé : la profondeur d'imbrication. Une valeur six niveaux plus bas et une valeur au sommet finissent en lignes sœurs. C'est le marché — vous perdez l'arbre en échange d'une prose propre.

Pourquoi la syntaxe abîme les embeddings

C'est le cas où convertir n'est pas seulement plus propre : ça change les résultats. Quand vous vectorisez un morceau de texte, le modèle encode tout ce qu'il contient. Donnez-lui un enregistrement JSON brut et une part significative du vecteur décrit le fait qu'il a vu du JSON — accolades, clés entre guillemets, la silhouette générale d'une structure de données. Deux enregistrements sur des sujets complètement différents peuvent se retrouver voisins dans l'espace vectoriel parce qu'ils partagent un schéma.

Retirez la syntaxe et l'embedding parle du contenu. Un ticket de support devient les mots réels du client plus quelques étiquettes, et la recherche sémantique dessus se comporte comme vous l'attendiez. L'effet est le plus fort sur les enregistrements courts, où le ratio syntaxe/contenu est le pire — un objet de cinq champs aux valeurs de deux mots est surtout de la ponctuation.

Même logique pour le découpage. Le JSON brut est hostile aux découpeurs à taille fixe : la coupe tombe au milieu d'un objet et produit un fragment orphelin de crochets. Le texte plat se coupe sur les frontières de phrases et de lignes, exactement comme les découpeurs le supposent.

Indexation et analyse de texte

Les moteurs de recherche plein texte tokenisent sur les frontières de mots puis jettent de toute façon la ponctuation — mais pas toujours proprement, et pas toujours avant qu'elle ait faussé vos statistiques de termes. Indexer du texte déjà nettoyé donne des fréquences de termes prévisibles et évite à l'analyseur de travailler pour rien.

Pour tout ce qui est statistique, l'argument est encore plus fort. Comptages de fréquences, analyse de sentiment sur un export d'avis produits, topic modelling sur un dump de tickets de support, extraction d'entités nommées d'un jeu de données scrapé — tout cela se fait contaminer par les tokens structurels et par des champs que vous ne vouliez pas compter. Une passe de conversion du JSON en texte lisible vous donne un corpus plutôt qu'une structure de données.

À supprimer avant analyse, si vous pouvez : les horodatages ISO, les UUID et les identifiants numériques. Ils se tokenisent en fragments sans signification et figurent sur absolument chaque enregistrement — le profil exact de ce qui va déformer une table de fréquences.

L'argument du budget de tokens

Si vous poussez un gros export vers un modèle, le texte plat est la représentation la moins chère du même contenu. Deux choses font l'économie. D'abord, les caractères structurels s'en vont. Ensuite — et c'est le plus gros poste sur les fichiers riches en enregistrements — vous cessez de payer la répétition des clés sur chaque objet. Mille enregistrements qui redisent chacun huit noms de champs transportent huit mille étiquettes redondantes dans le fichier brut.

Le compteur de tokens est sous la sortie : convertissez et vérifiez avant de coller où que ce soit. Sur les dumps d'API minifiés et les fichiers de logs NDJSON, la différence est en général substantielle. Cela dit, si vous frôlez la limite parce que le fichier est réellement énorme, aucune conversion ne vous sauvera — filtrez d'abord les enregistrements utiles, puis convertissez.

Quand le texte plat est le mauvais choix

Être honnête là-dessus est plus utile que de prétendre que la conversion gagne toujours. Les modèles lisent le JSON brut couramment ; c'est l'un des formats qu'ils ont le plus vus. Il y a trois situations où il ne faut pas le dépouiller :

• Vous générez du code contre les données. Définitions de types, parseurs, fonctions de mapping, schémas de validation — tout cela exige les noms de clés exacts, l'imbrication exacte et les types exacts. Collez la charge utile brute, ou un échantillon élagué. Aplatir jette précisément ce dont le modèle a besoin.
• L'imbrication porte le sens. Si savoir sous quel parent se trouve une valeur est justement la question — permissions par rôle, réglages par environnement, arbre de catégories — l'aplatissement détruit la réponse. Utilisez plutôt JSON vers Markdown, qui préserve la hiérarchie en titres et transforme les tableaux d'enregistrements uniformes en tableaux parcourables.
• Une personne va le lire. Le texte plat est optimisé pour les machines. Pour une relecture humaine, le Markdown gagne haut la main.

Le sélecteur de format en haut de cette page passe de l'un à l'autre en gardant votre fichier sélectionné : comparer prend un clic plutôt qu'un second envoi.

Les fichiers pénibles et leur comportement

• Les échappements Unicode. Les fichiers écrits par de vieilles bibliothèques encodent le non-ASCII en \u00e9 plutôt qu'en caractère lui-même. Ils sont décodés en vraies lettres — ce qui compte énormément pour des données en français, où les accents sont partout.
• Les blobs Base64. Images, PDF ou pièces jointes passés en contrebande dans un champ JSON sont énormes et ne contiennent aucun texte lisible. Retirez-les avant l'envoi, sinon ils domineront à la fois la taille du fichier et votre compte de tokens.
• Du JSON échappé dans du JSON. Courant dans les charges de webhooks et les lignes de log — un champ chaîne dont le contenu est lui-même un objet sérialisé. Il ressort en une longue chaîne échappée. Déballez ce champ d'abord si c'est la partie qui vous intéresse.
• Les fichiers malformés. Virgules finales, guillemets simples, None ou NaN à la Python. Le parsing échoue net. Passez le fichier au linter si son origine est floue.
• JSON Lines. Les exports NDJSON marchent bien ici — enregistrements uniformes, un par ligne, déjà proches de la forme voulue. Renommez en .json ou enveloppez les lignes dans un tableau avant l'envoi.

Questions fréquentes

Comment convertir un fichier JSON en txt ?

Déposez le .json dans le convertisseur ci-dessus et les valeurs reviennent en texte lisible, sans les accolades, crochets, guillemets, virgules et deux-points. Téléchargez le résultat en .txt. Gratuit, sans inscription, 50 Mo par fichier, rien n'est stocké ensuite.

Pourquoi convertir du JSON en texte plutôt que d'utiliser le JSON tel quel ?

Parce que les caractères de syntaxe sont du poids mort pour tout ce qui lit du sens plutôt que de la structure. Les modèles d'embedding, les classifieurs et les index plein texte tokenisent chaque guillemet et chaque virgule, ce qui dilue les vecteurs et gonfle la facture sans ajouter d'information. Si votre consommateur parse du JSON, gardez le JSON — ceci est pour les chaînes qui n'en font rien.

Les objets et tableaux imbriqués sont-ils aplatis ?

Oui. L'imbrication est un fait structurel et la structure est précisément ce qui est retiré : un enregistrement profondément imbriqué arrive comme une suite plate de valeurs étiquetées dans l'ordre du document. Les clés sont gardées comme étiquettes pour que les valeurs restent interprétables, mais la relation parent-enfant entre elles n'est pas représentée. C'est sur les configurations profondément imbriquées que ça fait le plus mal.

Les formats JSON Lines et NDJSON sont-ils gérés ?

Seulement si le fichier est du JSON valide dans son ensemble. Le NDJSON, c'est un objet par ligne sans tableau englobant — délibérément pas un document JSON unique, donc il ne se parsera pas comme tel. Enveloppez d'abord les lignes dans [ ] avec des virgules entre elles — un travail d'une ligne en jq ou sed — et la conversion passe normalement.

Et les très gros exports ?

Le plafond est de 50 Mo par fichier, ce qui fait beaucoup de JSON — les exports indentés sont surtout faits d'espaces et de structure, donc le contenu lisible n'est qu'une fraction de la taille. Si vous dépassez, filtrez les enregistrements utiles avec jq avant de convertir, plutôt que de découper arbitrairement et de perdre le tableau englobant.

Convertisseurs voisins

Si votre JSON est en réalité un tableau déguisé, l'exporter en CSV et passer par CSV vers texte donne un résultat plus net. Pour l'autre format structuré qui a le même problème sous une autre forme, il y a XML vers texte, et pour les pages enregistrées, HTML vers texte. File2Txt prend n'importe quel format pris en charge si vous préférez ne pas choisir de page.

Et si le fichier est l'un des nombreux fichiers d'un projet, le convertir seul est probablement la mauvaise unité de travail. Le convertisseur de dossier local et le convertisseur GitHub vers texte vous laissent sélectionner le JSON plus le code qui le lit en une seule passe. Pour les pages en ligne, Web2Txt aspire directement une URL, et le guide de préparation des fichiers pour les LLM couvre le cas général.

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.