CSV to JSON Converter

Yes. The parser follows RFC 4180 quoting rules: a field wrapped in double quotes can contain commas, quotes, or embedded line breaks, and a literal quote inside it is written as two double quotes (""), which the converter un-escapes automatically. A comma outside quotes is always a column separator, so "Doe, John" parses as a single field containing a comma rather than splitting into two fields — the same rule Excel and Google Sheets use when they export quoted CSV.

The later column silently overwrites the earlier one. Each row becomes a single JSON object keyed by header name, and JavaScript object keys can't repeat, so if your source file has two columns both labeled "Notes" (common after a spreadsheet merge or export bug), only the second column's values survive in the JSON — the first column's data is dropped without a warning. Rename duplicate headers before pasting if you need to keep both columns.

This page is comma-only, matching the plain "CSV to JSON" use case most people search for. If your file is semicolon- or tab-delimited — common in European locales where the comma is used as the decimal separator, or in files exported from database tools — use the full CSV/JSON converter, which auto-detects the delimiter or lets you choose comma, semicolon, tab, or pipe explicitly.

Rows are matched to headers by position, not by count, and nothing here throws an error. A short row (fewer fields than headers) fills the missing trailing values with null; a long row (more fields than headers) has its extra values silently discarded, since only as many fields as there are headers get read. Ragged CSV — often caused by a stray or missing delimiter partway through a file — won't be flagged, so check row lengths first if exact column alignment matters.

Cela arrive parce que le convertisseur déduit les types à partir du motif textuel de chaque cellule, et une simple suite de chiffres comme 02138 ou 4025 correspond au motif d'un entier, quelle que soit sa signification réelle. Une fois traité comme un nombre, parseInt("02138") renvoie 2138 — le zéro initial disparaît, car les nombres JSON n'ont aucune notion de chiffres « paddés » comme le ferait une chaîne. Le CSV lui-même ne peut pas indiquer qu'un champ doit rester du texte : le système de guillemets de la RFC 4180 contrôle uniquement l'échappement des virgules, des guillemets et des retours à la ligne, pas le type de donnée à l'intérieur des guillemets, donc un "02138" entre guillemets et un 02138 sans guillemets sont analysés de façon identique. Si vous convertissez des codes postaux, des numéros de téléphone, des SKU ou des numéros de compte, utilisez le convertisseur CSV/JSON complet et désactivez l'inférence de type pour que chaque colonne soit conservée comme chaîne, puis rétablissez le typage sélectivement là où vous voulez réellement des nombres.

Le cas le plus courant consiste à faire passer un export de tableur vers un système qui ne comprend que le JSON. Une équipe marketing exporte un CSV de prospects depuis un CRM et doit les envoyer en POST vers un webhook ou une automatisation Zapier/Make qui attend un corps JSON. Un développeur backend reçoit un CSV de données produits d'un fournisseur et doit l'insérer en masse dans MongoDB ou Firestore, qui stockent tous deux des documents de type JSON plutôt que des lignes et des colonnes. Un ingénieur QA prend une feuille de calcul de cas de test et la transforme en fichier de test (fixture) JSON consommé par un outil d'exécution de tests. Dans chaque cas, la source de vérité est tabulaire (un tableur, un export de base de données, un téléchargement CRM), mais la destination — une API, une base documentaire, un harnais de test — n'accepte que du JSON, donc une conversion ponctuelle rapide et fiable évite d'écrire un analyseur pour une tâche effectuée une ou deux fois par mois.

Le CSV précède de plusieurs décennies toute spécification formelle : des outils de tableur et de mainframe écrivaient des fichiers texte délimités par des virgules depuis les années 1970, chacun avec ses propres particularités de guillemets et de fins de ligne. La RFC 4180, publiée par Y. Shafranovich en 2005, documente les conventions courantes (fins de ligne CRLF, encadrement optionnel par guillemets doubles, doublement des guillemets pour l'échappement) mais elle est explicitement informative, et non une norme contraignante. En pratique, le « CSV » varie encore : Excel, dans certaines locales européennes, exporte des fichiers délimités par des points-virgules parce que la virgule y sert de séparateur décimal, certains outils utilisent un simple LF au lieu de CRLF, et l'UTF-8 précédé d'un BOM est courant dans les exports Windows. Le JSON, à l'inverse, s'appuie sur de véritables normes — ECMA-404 et RFC 8259 — ce qui explique en partie pourquoi il s'analyse de façon identique partout, alors que les analyseurs CSV doivent encore deviner le dialecte.

Non — c'est une idée reçue courante. Les lignes et colonnes d'un CSV ne produisent jamais qu'un tableau JSON plat d'objets plats ; il n'existe aucun moyen d'exprimer de l'imbrication en CSV, donc ce convertisseur (ou tout autre outil CSV vers JSON) ne peut pas produire d'objets ou de tableaux imbriqués, quelle que soit l'organisation des données. Le type de chaque valeur n'est pas fixe non plus : comme le CSV stocke tout en texte, "42" peut vouloir dire le nombre 42 ou la chaîne "42" selon le contexte, et différents outils déduisent les types selon des règles différentes. Les règles de ce convertisseur (true/false pour les booléens, motifs de chiffres pour les nombres, vide/null/n-a pour null) constituent un ensemble de valeurs par défaut raisonnable, pas une garantie qu'il corresponde à tout autre analyseur CSV auquel vous pourriez comparer le résultat, y compris l'import CSV natif d'un logiciel de tableur.

La ligne d'en-tête fournit directement les noms de clés JSON, caractère pour caractère, y compris les espaces, la ponctuation ou les emoji présents dans votre fichier source — les clés JSON ne sont que des chaînes, donc presque tout est valide. La seule exception est une cellule d'en-tête totalement vide : plutôt que de produire une clé sans nom, le convertisseur se rabat sur un espace réservé du type column1, column2, correspondant à la position de la cellule dans la ligne, de sorte que chaque valeur se retrouve tout de même quelque part dans l'objet de sortie, simplement sous un nom générique au lieu de l'étiquette manquante. Si vous voulez des noms de clés plus propres et adaptés au code — sans espaces, avec une casse cohérente, sans caractères spéciaux qui nécessiteraient la notation par crochets en JavaScript — il vaut mieux renommer la ligne d'en-tête dans votre tableur source avant de coller les données, car le convertisseur reprend les en-têtes tels quels sans les normaliser ni les nettoyer pour vous.