Aller au contenu principal
PulsarKit

Formater et valider du JSON

Indentez, compactez ou vérifiez un fichier JSON, avec l’erreur localisée par ligne et colonne et les problèmes silencieux signalés clairement.

Déposez vos fichiers ici

.json, .jsonc, .txt · jusqu’à 100 Mo

Comment formater le JSON

  1. 1

    Déposez un fichier JSON

    Ajoutez un fichier ou jusqu’à vingt fichiers, jusqu’à 100 Mo chacun. Les fichiers contenant des commentaires et des virgules finales sont également acceptés.

  2. 2

    Choisissez formater, minifier ou valider

    Formater indente le document, minifier supprime chaque octet facultatif et valider se contente de signaler ce qui est trouvé sans produire de fichier.

  3. 3

    Lisez le rapport et téléchargez

    Les erreurs indiquent une ligne et une colonne ; les avertissements répertorient les clés dupliquées et les pertes de précision. Enregistrez le résultat lorsque tout est correct.

Des erreurs avec une position, pas un haussement d’épaules

Les navigateurs ne sont pas d’accord sur les erreurs d’analyse : certains indiquent un décalage en caractères, d’autres seulement une phrase, et le texte du message change d’une version à l’autre. C’est pourquoi le JSON est lu ici par un analyseur écrit pour cet outil, qui transforme toujours un échec en une ligne et une colonne. Dans une exportation de 40 000 objets, savoir que la virgule en trop se trouve à la ligne 8 421 fait la différence entre une correction en deux minutes et un après-midi perdu.

Clés dupliquées et nombres qui changent discrètement

Deux problèmes ne ressortent jamais d’une analyse ordinaire. Une clé répétée dans le même objet est admise par la plupart des analyseurs, qui conservent la dernière valeur sans rien dire ; ici, les deux numéros de ligne sont affichés. Et un entier plus long que 2^53, comme 9007199254740993, ne peut pas être représenté exactement comme nombre JSON : il revient diminué de un. Des identifiants fournis par des API externes y sont confrontés en permanence, donc chaque littéral de ce type est signalé avec son chemin.

Entrée tolérante, sortie stricte

Les fichiers réels arrivent avec des commentaires //, des commentaires de bloc /* */ et une virgule finale après la dernière entrée. Tout cela est lisible, et tout cela est rejeté par tout analyseur conforme à la norme. Le mode tolérant accepte tout cela, vous indique ce qui a été retiré et poursuit le traitement. La sortie est toujours du JSON simple et valide. Passez en entrée stricte pour prouver qu’un fichier est déjà conforme.

Vos données restent dans l’onglet

Les exports d’API et les fichiers de configuration contiennent souvent des jetons, des adresses et des données clients, donc rien n’est envoyé nulle part. Le fichier est lu, analysé, vérifié et réécrit dans votre navigateur, les fichiers volumineux étant traités dans un thread de travail. Aucun envoi, aucune inscription, aucune copie conservée après la fermeture de l’onglet.

Questions fréquentes

Pourquoi mon JSON avec commentaires passe-t-il quand même ?

Parce que le mode d’entrée par défaut est tolérant : les commentaires // et /* */ ainsi que les virgules finales sont acceptés, signalés comme avertissements et exclus de la sortie. C’est le choix pratique pour des fichiers de configuration modifiés à la main. Si vous devez précisément prouver qu’un fichier est un JSON standard, passez le mode d’entrée en strict et ces mêmes éléments deviennent des erreurs.

Que signifie réellement une erreur « jeton inattendu » ?

Que l’analyseur a rencontré un caractère inutilisable à cet endroit. Les causes habituelles sont une virgule manquante ou en trop, un guillemet simple au lieu d’un double, une clé non entourée de guillemets ou une valeur terminée trop tôt. Le message indique la ligne et la colonne, commencez donc à lire un ou deux jetons avant la position signalée.

Comment retirer toute l’indentation ?

Choisissez minifier. Chaque espace, tabulation et saut de ligne facultatif est supprimé et le résultat tient sur une seule ligne, généralement 15 à 30 % plus petite que la version indentée. Les données analysées sont identiques, donc un fichier minifié remplace directement la version mise en forme partout où elle fonctionnait.

Qu’est-ce qu’une perte de précision sur les nombres ?

Les nombres JSON sont en virgule flottante, donc les entiers supérieurs à 2^53 ne peuvent pas tous être représentés. Donnez 9007199254740993 et vous récupérez 9007199254740992. Les longs identifiants provenant de systèmes externes en sont les premières victimes. Chaque littéral concerné est signalé avec son chemin, et la solution durable consiste à ce que l’API productrice envoie ces identifiants sous forme de chaînes.

Puis-je trier les clés par ordre alphabétique ?

Oui, le tri est un simple réglage et il s’applique à tous les niveaux d’imbrication. Il est surtout utile avant de comparer deux exports, car il supprime les différences d’ordre sans importance et ne laisse dans le diff que les vrais changements. L’ordre des clés n’ayant aucune signification en JSON, rien n’est perdu en les triant.

Que fait le mode validation de différent ?

Il s’arrête après la vérification. Vous obtenez un verdict ainsi que la liste complète des erreurs et avertissements, et aucun fichier n’est produit pour le téléchargement. Utilisez-le quand vous devez seulement savoir si un fichier est sain, par exemple un artefact de build ou une réponse d’API que vous êtes sur le point de diffuser, sans intention de le réécrire.

Mon JSON est-il envoyé quelque part ?

Non. L’analyse, la vérification et la réécriture se font dans l’onglet de votre navigateur à partir du code livré avec la page. Aucun serveur ne reçoit le texte, rien n’est journalisé et rien ne reste après la fermeture de l’onglet.

Guides

Outils associés