Desarrollo

Convertir CSV a JSON

Pega un CSV, o carga un archivo, y obtienes un arreglo JSON. Esto es un parser de verdad y no un split por comas, así que los campos entre comillas que contienen comas, saltos de línea y comillas dobladas sobreviven intactos. El delimitador se detecta a partir de las primeras líneas, salvo que elijas uno.

La detección lee las primeras cinco líneas y elige el carácter que las divide a todas en la misma cantidad de campos.

Minifica cuando la salida va al cuerpo de una petición y no a tus ojos.

Tu navegador lee el archivo y nunca lo sube a ningún lado. Todo lo que supere los 5 MB se rechaza, porque la página se bloquearía.

Análisis

La conversión es deliberadamente estricta: un valor solo se vuelve número si al imprimirlo de nuevo salen exactamente los mismos caracteres, así que 007 y 1.50 siguen siendo cadenas.

0Filas
0Columnas
0Tamaño del JSON

Por qué dividir por comas está mal

La primera versión de todo lector de CSV es line.split(','), y funciona hasta que los datos traen una coma. A partir de ahí sigue casi funcionando, que es peor. Hay tres características del formato que la rompen:

El parser de aquí es una máquina de estados que avanza carácter por carácter, la única forma de resolver bien las tres cosas. También tolera las desviaciones habituales: un CR solo, un LF solo y CRLF terminan una fila por igual, y una comilla que aparece en medio de un campo sin comillas se trata como un carácter común y no como un error.

La conversión de tipos y la regla estricta que la hace segura

CSV no tiene tipos. Cada campo es texto, así que convertir 42 en número es una suposición: una útil, y también la causa de muchísima pérdida silenciosa de datos. La implementación habitual llama al parser numérico del lenguaje y se queda con lo que salga, y así el código postal 01234 se vuelve 1234 y el número de pieza 1.50 se vuelve 1.5.

La regla que se usa aquí es más estrecha: un campo se vuelve número solo si al convertir ese número otra vez a texto salen exactamente los caracteres originales. 42 pasa la prueba. 007, 1.50, +44, 1e3 y cualquier entero lo bastante grande como para perder precisión no la pasan y siguen siendo cadenas. true y false se vuelven booleanos, un campo vacío se vuelve null, y todo lo demás queda intacto.

Las fechas nunca se convierten, porque JSON no tiene un tipo de fecha y lo único peor que una fecha en texto es una fecha equivocada. 03/04/2024 es marzo en Estados Unidos y abril en casi todo el resto del mundo, y ningún parser puede saber cuál de las dos a partir del archivo. Consérvalas como cadenas ISO-8601 y deja que decida quien las consuma.

La falla que conviene conocer

Una sola comilla doble sin pareja destruye el resto del archivo. Desde ese carácter en adelante el parser cree que está dentro de un campo entre comillas, así que los delimitadores y los saltos de línea pasan a ser texto común y todo se derrumba en un único valor enorme. Esta es la forma más frecuente en que una importación de CSV sale mal, y casi siempre viene de un campo con un símbolo de pulgadas o una comilla tipográfica que nunca se escapó. La herramienta detecta ese estado y lo avisa, pero no puede adivinar dónde tendría que haberse cerrado la comilla. Busca en la entrada una " suelta y arréglala ahí.

Las filas desparejas se manejan en lugar de rechazarse. Una fila con menos campos que el encabezado recibe null en lo que falta; una fila con más guarda los sobrantes bajo nombres column_N. Las dos se informan, porque las dos suelen significar que el archivo está dañado, no que sea poco común.

Lo que esto no puede hacer

No puede arreglar la codificación. Para cuando el texto está en el cuadro ya fue decodificado, así que si ves José el daño ocurrió al guardar o al abrir el archivo: vuelve a abrir el original como UTF-8 en lugar de intentar repararlo aquí. La marca de orden de bytes del comienzo se elimina, lo que evita que un carácter invisible se pegue al nombre de tu primera columna.

No trabaja en streaming. Todo se mantiene en memoria, así que la carga de archivos está limitada a 5 MB y el texto pegado no tiene un límite formal, pero sí el mismo límite práctico. Tampoco tiene noción de esquema: una estructura anidada no se puede reconstruir a partir de columnas planas, así que address.city llega como una clave con un punto adentro, no como un objeto anidado.

Preguntas frecuentes

¿Se sube a algún lado el archivo que elijo?

No. Se lee con el FileReader del navegador, que entrega el texto directamente a la página. No hay ningún servidor involucrado ni ninguna petición de red, que es también la razón del límite de tamaño: todo ocurre en la memoria de esta pestaña.

¿Por qué mis códigos postales conservaron los ceros a la izquierda?

Porque el conversor solo crea un número cuando ese número se imprime de vuelta con los mismos caracteres, y 1234 no es 01234. Es deliberado. Si de verdad quieres números ahí, desactiva "Convertir números y booleanos" y convierte esa columna más adelante.

Mi archivo usa punto y coma. ¿Funciona?

Sí. La detección suele reconocerlo, y puedes forzarlo con el menú de delimitador. El punto y coma es lo normal en las exportaciones de Excel de los países donde la coma es el separador decimal, así que un CSV europeo con punto y coma no está roto.

¿Qué pasa con las filas que tienen otra cantidad de campos?

Se conservan. Las filas cortas reciben null en las columnas que faltan, las filas largas guardan los valores de más bajo claves column_N, y un aviso te dice cuántas de cada tipo aparecieron. No se descarta nada en silencio.

¿Puedo obtener un arreglo de arreglos en lugar de objetos?

Desactiva "La primera fila es el encabezado" y cada fila se vuelve un objeto con las claves column_1, column_2 y así sucesivamente, incluida la primera. No hay un modo de arreglo de arreglos puro, porque en la práctica las claves hacen que la salida sea mucho más fácil de usar.

Última actualización 19 de septiembre de 2026