Cómo convertir CSV a JSON sin perder la mitad de tus datos

Un CSV se convierte en JSON transformando cada fila en un objeto y cada encabezado de columna en una clave, así que un archivo que empieza con id,name,city sale como un array de objetos con esas tres propiedades. Cualquier conversor hace eso, incluido el de este sitio, que analiza el texto en tu navegador y te devuelve el array. El trabajo está en las discrepancias entre los dos formatos: el CSV no tiene tipos, ni anidamiento, ni una declaración de codificación, y JSON necesita las tres cosas resueltas antes de poder escribir un solo carácter.

Cómo se ve la salida en realidad

Con este CSV:

id,name,city,joined
1,Ada,London,1843-01-01
2,Grace,New York,1944-07-02

el JSON es un array de dos objetos:

[
  { "id": 1, "name": "Ada", "city": "London", "joined": "1843-01-01" },
  { "id": 2, "name": "Grace", "city": "New York", "joined": "1944-07-02" }
]

Esa forma — un array de objetos planos con claves tomadas de la fila de encabezados — es la que esperan la mayoría de las APIs, los importadores de bases de datos y las bibliotecas de JavaScript. Ningún conversor puede saber si tu primera línea es datos o un encabezado, así que si el archivo no tiene fila de encabezados tienes que indicarlo; las claves pasan entonces a ser nombres posicionales como column_1. Nada puede inventar nombres con sentido para columnas que nadie etiquetó.

Por qué no puedes limitarte a separar por comas

El primer lector de CSV que escribe cualquiera es un split por comas dentro de un bucle sobre las líneas. Funciona con el archivo de ejemplo y luego corrompe en silencio el de verdad, porque hay tres características del formato que lo rompen.

Campos entre comillas. "Lovelace, Ada" es un solo valor. Sepáralo por la coma y obtienes dos, y todas las columnas a su derecha se desplazan una posición solo en esa fila — que es el peor tipo de bug, porque el archivo se sigue cargando.

Comillas duplicadas. Dentro de un campo entre comillas, una comilla doble literal se escribe dos veces. "She said ""no""" es un solo valor: She said "no". En CSV no existe el escape con barra invertida; si diste por hecho que sí, estás corrompiendo cualquier cosa que contenga un símbolo de pulgadas.

Saltos de línea dentro de los campos. Un campo entre comillas puede contener saltos de línea, lo que significa que una fila de CSV y una línea de texto no son lo mismo. Leer el archivo línea por línea ya es el bug, antes de haber parseado nada.

Estas reglas vienen del RFC 4180, el memorando de 2005 que puso por escrito lo que ya hacía todo el mundo. Es informativo y no obligatorio, y por eso los archivos reales se desvían de él: retornos de carro sueltos, punto y coma como delimitador, líneas en blanco al final. Un parser que valga la pena tolera todo eso y aun así cumple las tres reglas, lo que exige una máquina de estados carácter por carácter en vez de una expresión regular.

Por qué todo tu CSV sale como una sola fila

Una única comilla doble sin pareja arruina todo lo que viene después. Desde ese carácter en adelante, el parser cree que está dentro de un campo entre comillas, así que las comas y los saltos de línea dejan de ser separadores y pasan a ser texto corriente. Las filas anteriores a la comilla suelta sobreviven; el resto del archivo se colapsa en una sola fila con un único valor enorme.

El culpable habitual es un símbolo de pulgadas suelto, una altura escrita como 5"11 o una medida como 24" wide que nunca se escapó. Ninguna herramienta puede adivinar dónde debería haberse cerrado la comilla: busca en la entrada una " solitaria y arréglala ahí. Si un conversor reporta muchas menos filas de las que pegaste, esto es lo primero que hay que revisar.

Por qué desaparecen los ceros a la izquierda y los IDs largos

Todos los campos de un CSV son texto. JSON distingue 42 de "42", así que el conversor tiene que decidir, campo por campo, y cada decisión que toma mal es pérdida silenciosa de datos. Las víctimas clásicas:

• Ceros a la izquierda. El código postal 01234 se convierte en 1234. El código de producto 007 se convierte en 7.
• Ceros a la derecha. El precio 1.50 se convierte en 1.5, lo que importa en el momento en que se vuelve a imprimir en una factura.
• Números de teléfono. +44 se interpreta como el número 44 y el signo más desaparece.
• Identificadores largos. En la práctica los números de JSON son doubles IEEE 754, así que por encima de 9007199254740991 ya no se puede confiar en que un entero sobreviva exacto: vuelve con sus últimos dígitos cambiados. Los números de tarjeta, los snowflake IDs y las referencias de pedido de 19 dígitos caen todos aquí.

Existe una regla segura y es estrecha: convierte un campo a número solo si al imprimir ese número se obtienen exactamente los caracteres originales. 42 pasa la prueba. 007, 1.50, +44, 1e3 y cualquier entero demasiado grande no la pasan y se quedan como strings. Esa es la regla que usa el conversor de aquí. Trae consigo dos efectos secundarios que conviene conocer antes de comparar la salida: true y false pasan a ser booleanos, y una celda vacía pasa a ser null en vez de una cadena vacía. Si alguna de las dos cosas te importa, desactiva la conversión de tipos y castea las columnas tú mismo más adelante: con ella desactivada, cada celda que existe en el archivo sale como el texto exacto que contenía.

Las fechas se quedan como strings, y esa es la respuesta correcta

JSON no tiene tipo fecha. 03/04/2024 es el 3 de abril en la mayor parte del mundo y el 4 de marzo en Estados Unidos, y nada en el archivo te dice cuál de los dos. Un conversor que elige uno está adivinando por ti, y se equivocará en una parte de tus filas sin decírtelo. Deja las fechas como strings ISO-8601 — 2024-04-03 — y que lo que consuma el JSON decida qué significan.

Qué pasa con las filas que no coinciden con el encabezado

Las exportaciones reales tienen filas irregulares. Lo sensato es conservarlas en vez de rechazar el archivo: una fila corta recibe null en las columnas que faltan, y una larga conserva los sobrantes bajo claves posicionales. Lo que importa es que el conversor avise de que ocurrió. Las filas irregulares casi siempre significan que el archivo está dañado — un delimitador suelto, una descarga truncada —, así que contar cuántas quedaron cortas o largas es un diagnóstico, no una nota al pie.

¿Se puede sacar JSON anidado de un CSV plano?

No a partir del archivo solo, y este es el límite que manda a la gente a buscar una opción que no existe. Un CSV es un rectángulo. Si tu columna se llama address.city, una conversión directa te da una clave con un punto en el nombre, no un objeto address que contiene un city. El punto significa algo para ti y nada para el archivo.

Algunos conversores ofrecen leer los nombres con punto como rutas. Eso es una convención, no un formato, y se rompe la primera vez que un nombre de columna legítimo contiene un punto. Si necesitas salida anidada, convierte a JSON plano y reestructúralo en unas pocas líneas de código, en vez de confiar en que una casilla adivinó tu esquema.

Por qué los caracteres acentuados llegan hechos basura

Si José aparece como José, el daño ocurrió antes de la conversión. Eso son bytes UTF-8 leídos como Latin-1, y quedó grabado cuando el archivo se guardó o se abrió. La solución es volver a exportarlo como UTF-8 desde la fuente original. Ir en el otro sentido — decodificar de vuelta el texto estropeado — a veces funciona, pero cualquier carácter que la code page equivocada no pudo representar ya fue sustituido por un signo de interrogación o un marcador de posición, y ninguna cantidad de redecodificación los devuelve. Empieza por el archivo original si todavía lo tienes.

Un detalle relacionado: la exportación "CSV UTF-8" de Excel escribe un byte order mark al principio del archivo. Si nada lo quita, ese carácter invisible se pega al nombre de tu primera columna, y te pasas veinte minutos preguntándote por qué data[0].id es undefined cuando la clave en realidad es \uFEFFid. El conversor de aquí quita el BOM inicial antes de parsear, así que este no llega a tu salida — pero un script que escribas tú no lo hará salvo que se lo pidas. Cualquier cosa que estropee el texto de formas que no puedes ver vale la pena conocerla en general, y el mismo tipo de problema aparece cuando un ampersand en tus datos se topa con HTML y sale por el otro lado como &.

Qué pierde una ida y vuelta en cada dirección

Convertir JSON de vuelta a CSV aplana todo: los objetos anidados se colapsan en columnas con punto, un array se comprime en una sola celda como texto JSON, y todos los tipos vuelven a ser texto. Así que una ida y vuelta CSV → JSON → CSV no te devolverá un archivo idéntico byte a byte, y una ida y vuelta JSON → CSV → JSON pierde los tipos por completo. Si necesitas la dirección inversa, el conversor de JSON a CSV se encarga del aplanado, y lo que te cuesta una estructura anidada al bajar vale la pena leerlo antes de comprometerte con eso como paso de un pipeline.

Cuándo dejar de usar un conversor y escribir código

Una herramienta de navegador es lo correcto para un archivo puntual, una muestra que necesitas mirar, o un texto pegado desde una hoja de cálculo. Deja de serlo en tres puntos: archivos de más de unos pocos megabytes, porque todo se mantiene en memoria — el selector de archivos de aquí rechaza cualquier cosa por encima de 5 MB en vez de congelarte la pestaña, aunque nada te impide pegar esa cantidad de texto a mano —; cualquier cosa que vayas a hacer más de dos veces, porque un script que puedes volver a ejecutar le gana a una pestaña que tienes que recordar; y cualquier cosa que necesite streaming, donde las filas se procesan según van llegando.

Por lo demás, la comprobación es siempre la misma. Convierte y luego lee el primer objeto y el último. Ceros a la izquierda intactos, fechas todavía como strings, ninguna clave con un carácter raro dentro, número de filas coincidiendo con la hoja de cálculo. Treinta segundos, y atrapa casi todas las fallas que aparecen aquí.

Última actualización 19 de septiembre de 2026