Generador de tablas Markdown

Acerca de las tablas Markdown

Las tablas Markdown usan barras verticales (|) y guiones (-) para crear datos tabulares estructurados en texto plano. Las admiten GitHub, GitLab, Reddit y la mayoría de los renderizadores Markdown. La línea de alineación usa dos puntos para indicar alineación a la izquierda, al centro o a la derecha para cada columna.

Escribir tablas Markdown a mano puede ser tedioso y propenso a errores. Este editor visual te permite introducir datos en una cuadrícula tipo hoja de cálculo y genera Markdown correctamente formateado en tiempo real. Todo el procesamiento se hace en tu navegador.

La sintaxis pipe-table, mecánicamente

Una tabla GFM consta de tres partes: una fila de encabezado con celdas separadas por pipes (|), una fila delimitadora justo debajo con guiones (---) para cada columna, y cero o más filas de datos con la misma estructura separada por pipes. Los pipes iniciales y finales en cada fila son opcionales pero convencionalmente se incluyen para legibilidad. La alineación de columna se especifica con dos puntos en la fila delimitadora: :--- para alinear a la izquierda (el defecto), :---: para centrar, ---: para alinear a la derecha. La tabla mínima viable se ve así en fuente: | Header | Header | en línea 1, | --- | --- | en línea 2, | Cell | Cell | en línea 3 en adelante. El contenido de las celdas puede incluir cualquier formato Markdown inline (negrita, cursiva, enlaces, code spans, imágenes) pero no puede incluir elementos a nivel de bloque (listas, bloques de código, citas). Los saltos de línea dentro de una celda deben codificarse como etiquetas <br> en lugar de saltos de línea literales, ya que los saltos literales romperían la estructura de la tabla. Los caracteres pipe dentro del contenido de la celda deben escaparse como \|, de lo contrario el parser los trata como separadores de columna y el conteo de columnas de la fila sale mal. La mayoría de los parsers toleran anchos de columna desalineados; las fuentes | a | b | y | aaa | b | se renderizan idénticas, aunque la segunda parezca más «correcta» en fuente. Esta herramienta siempre emite fuente con ancho alineado por legibilidad, pero se renderiza igual que la fuente compacta.

Dónde se renderizan las tablas y dónde no

Se renderiza correctamente: GitHub (issues, pull requests, READMEs, páginas de wiki, discusiones, code reviews, comentarios en todas partes), GitLab (mismas superficies), Bitbucket, Stack Overflow, Reddit (cuando GFM está habilitado en el subreddit, lo cual es lo habitual), Discord (solo en contexto de bloque de código, las tablas GFM completas no se renderizan en mensajes de chat pero markdown-it las procesa en la superficie de documentos), Notion (con su propia importación de tablas), Obsidian, Logseq, Bear, la mayoría de los generadores de sitios estáticos (Hugo, Jekyll, Eleventy, Astro con el plugin remark-gfm, Next.js MDX), la vista previa de VS Code, GitHub Pages, Read the Docs (según la configuración). No se renderiza correctamente: CommonMark estricto (Pandoc con el reader commonmark y sin extensiones, parser C Discount sin el flag pipe-tables), Slack (renderiza un subconjunto de Markdown pero no tablas), la mayoría de los clientes de correo (el HTML renderizado en correo es estructuralmente correcto pero con estilos inline, no Markdown), instalaciones de WordPress más antiguas sin plugin de Markdown. La regla general: si tu destino es una plataforma orientada a desarrolladores (familia GitHub, documentación técnica), las tablas GFM funcionan. Si tu destino es una plataforma de audiencia general (Slack, correo, Twitter), asume que las tablas no se renderizarán y o bien pre-renderizas como imagen o reescribes como lista.

Sintaxis alternativas de tablas Markdown

El formato pipe-table domina por el alcance de GitHub, pero no es la única sintaxis de tablas Markdown. Las tablas simples de Pandoc usan separadores de línea-en-blanco-y-guiones y alinean columnas por posición visual en lugar de pipes, mucho más legibles para tablas estrechas pero más difíciles de escribir a mano. Las tablas multi-línea de Pandoc soportan celdas que abarcan múltiples líneas, importante para contenido descriptivo largo que no cabe en una fila. Las tablas grid de Pandoc usan bordes ASCII (+---+---+) que parecen dolorosos de mantener a mano pero son fáciles de emitir por herramientas. reStructuredText (Sphinx) usa tablas grid exclusivamente, la documentación de cualquier proyecto Python se escribe así. AsciiDoc usa una sintaxis pipe-prefijo distinta (|===) optimizada para autoría de libros técnicos. HTML en Markdown siempre está disponible como vía de escape: cualquier procesador Markdown deja pasar HTML crudo, así que cuando las pipe tables no bastan puedes meter una <table> real con spanning completo de filas/columnas, marcado semántico y estilo CSS. La sintaxis pipe-table que esta herramienta genera es estilo GFM, la opción más compatible para el ecosistema de desarrollo moderno.

Usos habituales

• Archivos README de GitHub. Tablas comparativas («nuestra biblioteca vs. alternativas»), matrices de funciones, listas de versiones soportadas, listas de contribuyentes, fichas de referencia de comandos. Probablemente el uso individual de producción más común de las tablas GFM.
• Documentación y wikis. Tablas de referencia de API (nombre de parámetro / tipo / descripción / defecto), tablas de opciones de configuración, referencias de códigos de error, matrices de traducción de idiomas. Read the Docs, MkDocs, Docusaurus, GitBook todos soportan tablas GFM.
• Posts comparativos de blog. Artículos «Framework X vs Framework Y», comparaciones de specs de hardware, desgloses de niveles tarifarios. El formato pipe-table es mucho más legible que los párrafos ad hoc y se renderiza limpiamente en Medium, dev.to, Substack y blogs personales.
• Páginas de precios. Tablas de niveles SaaS (Free / Pro / Enterprise a través de filas de funciones) funcionan bien en formato pipe-table para mockups rápidos de borrador antes de que los diseñadores comerciales hagan la versión HTML pulida.
• Plantillas de issues de GitHub. Las plantillas de reporte de bug suelen incluir pasos de reproducción en forma de tabla (Paso / Esperado / Real / Captura). Tablas de estado de tableros de proyecto para seguir el progreso del sprint.
• Notas de reunión y planes de proyecto. Tablas de elementos de acción (Propietario / Acción / Fecha límite / Estado) en documentos de notas compartidas. Registros de decisiones. Registros de riesgos.
• Importación CSV. Muchos generadores de tablas ofrecen importación CSV-a-Markdown, pega un CSV, obtén una tabla Markdown. Lo inverso (Markdown a CSV) también es común al extraer datos estructurados de documentación de vuelta a formato hoja de cálculo.

El problema del ancho y otras restricciones

Las pipe tables tienen varias limitaciones inherentes que vale la pena conocer. El ancho de columna está restringido por el contenido de celda más largo, una URL larga o un párrafo descriptivo en una celda obliga a toda la columna a ensancharse, lo que puede producir tablas inmanejables que no caben en anchos de página de documentación estándar. La solución es o truncar el contenido largo (enlazando en otro sitio para detalle) o usar HTML inline si necesitas celdas que se envuelvan. Sin spanning de fila o columna, cada celda ocupa exactamente una fila y una columna. Las tablas complejas con celdas fusionadas necesitan HTML <table> real con atributos rowspan / colspan. Sin tablas anidadas, no puedes meter una tabla dentro de la celda de otra tabla en Markdown. Sin contenido a nivel de bloque en celdas, sin listas, sin bloques de código, sin citas dentro de una celda. Contenido inline (negrita, cursiva, code spans, enlaces, imágenes) está bien pero cualquier cosa multi-línea necesita etiquetas <br>. La fila de encabezado es obligatoria en GFM, no hay sintaxis de tabla sin encabezado. Si quieres una tabla sin encabezado visible, deja las celdas de encabezado vacías pero la fila aún tiene que estar presente. La alineación aplica por columna a toda la columna, no puedes tener distinta alineación para distintas celdas en la misma columna. Para layouts de tabla sofisticados que excedan estas restricciones, la herramienta correcta es HTML en tu fuente Markdown, no Markdown mismo.

Conversión CSV ↔ Markdown

La mayoría de los datos tabulares del mundo real viven en archivos CSV (exports de hoja de cálculo, respuestas de API, salida de análisis de logs), convertir hacia y desde Markdown es un workflow común. CSV → Markdown: parsea el CSV (manejando campos quoteados con comas embebidas, comillas escapadas, saltos de línea dentro de campos), luego formatea cada fila como | valor | valor | con las filas de encabezado y delimitador apropiadas. La mayoría de los generadores de tablas incluyendo este ofrecen importación CSV; para conversiones puntuales también puedes usar la herramienta de línea de comandos csvlook de csvkit que produce una salida en formato pipe similar. Markdown → CSV: re-parsea la tabla GFM en filas y columnas, luego emite CSV con quoting correcto. Útil al extraer datos estructurados de documentación de vuelta a forma de hoja de cálculo para análisis. La dirección Markdown-a-CSV la ofrecen herramientas como pandoc (con la combinación correcta de reader/writer), tableconvert.com y varias utilidades de línea de comandos. La ida y vuelta es con pérdida en una dirección, el formato (negrita, enlaces, imágenes) sobrevive intacto al paso por CSV solo si escribes el contenido de la celda CSV como texto Markdown crudo y tratas el resultado como Markdown otra vez.

Privacidad: por qué importa el solo-navegador incluso aquí

Las tablas no parecen datos sensibles, pero el contenido de las tablas a menudo lo es. Los planes de proyecto contienen decisiones de personal y funciones no anunciadas. Las tablas de precios contienen información comercial. Las tablas comparativas en posts de blog no publicados revelan posicionamiento editorial. Los elementos de acción de notas de reunión contienen información de asignación y rendición de cuentas. Los generadores de tablas del lado servidor suben tus datos a un tercero donde quedan en logs. Esta herramienta corre enteramente en tu navegador vía JavaScript, verifícalo en la pestaña Network de DevTools mientras editas celdas, o pon la página offline (modo avión) tras cargar y el editor sigue funcionando. Segura para borradores de documentación no publicados, planificación de proyecto interna, tablas comparativas para posts de blog no publicados aún, o cualquier contenido de tabla que no quieras ver copiado en el disco duro de un desconocido.

Preguntas frecuentes

¿Qué sintaxis de tabla Markdown se genera?

Genera la sintaxis estándar GFM (GitHub Flavored Markdown) con barras verticales, una línea de separación de guiones y dos puntos opcionales para la alineación. Esta sintaxis funciona en GitHub, GitLab, Reddit, Jekyll, Hugo y la mayoría de los procesadores Markdown.

¿Cómo definir la alineación de las columnas?

Haz clic en los botones L (izquierda), C (centro) o R (derecha) bajo cada encabezado de columna. La alineación izquierda usa :---, la centro :---: y la derecha ---: en la línea de separación.

¿Puedo importar desde CSV o pegar desde una hoja de cálculo?

La importación CSV está en el roadmap. Por ahora, pegar-desde-Excel/Google Sheets a menudo funciona porque la mayoría de las apps de hoja de cálculo ponen datos separados por tabuladores en el portapapeles, que puedes pegar en celdas individuales. Para importación CSV en bulk sin pegado manual, herramientas de línea de comandos como csvlook de csvkit producen salida tabla-GFM similar, o pandoc puede convertir CSV a Markdown directamente con pandoc --from csv --to gfm input.csv.

¿Y celdas fusionadas, tablas anidadas o contenido bloque en celdas?

Las pipe tables GFM no soportan estas. Cada celda ocupa exactamente una fila y una columna; sin rowspan ni colspan. Sin tablas anidadas. Sin contenido a nivel de bloque (listas, bloques de código, citas) dentro de una celda, solo contenido inline (negrita, cursiva, code spans, enlaces, imágenes, saltos de línea vía <br>). Para layouts de tabla sofisticados que excedan estas restricciones, incrusta HTML <table> crudo directamente en tu fuente Markdown, todo procesador Markdown deja pasar el HTML sin cambios. El compromiso es que la fuente se vuelve mucho más difícil de leer y editar a mano.

¿Hay un límite de filas o columnas?

Puedes tener hasta 20 columnas y 100 filas. Para la mayoría de la documentación y los archivos README, es más que suficiente. La tabla se actualiza en tiempo real mientras escribes.

¿El contenido de mis tablas se envía a algún sitio?

No. La generación corre enteramente en tu navegador vía JavaScript. Las celdas que editas y la salida Markdown nunca cruzan la red, verifícalo en la pestaña Network de DevTools mientras escribes, o pon la página offline (modo avión) tras cargar y el editor sigue funcionando. Segura para borradores de documentación no publicados, planes de proyecto internos, tablas comparativas de precios no publicadas aún, o cualquier contenido tabular que no quieras ver copiado en el disco duro de un desconocido.

Herramientas relacionadas