Por qué previsualizar antes de subir el README
Un README, una entrada de blog o unas notas de reunión escritas en Markdown parecen simples mientras las escribes, pero el resultado renderizado puede sorprender: un asterisco mal cerrado convierte medio párrafo en cursiva, una tabla sin la fila de separación no se muestra como tabla, o una lista numerada se reinicia porque falta una línea en blanco. Detectar esto en tu propio navegador — antes de hacer git push — ahorra idas y venidas.
La vista previa de Markdown de ToolPico muestra el resultado exacto mientras escribes, con soporte para la sintaxis GitHub Flavored Markdown (GFM) que usan los README, issues y pull requests: tablas, listas de tareas, texto tachado y bloques de código con resaltado de sintaxis.
Cómo evitar tablas Markdown rotas
| --- | --- |) y las filas de datos, todas con el mismo número de columnas. Olvidar la fila de separación es el error más frecuente.Por ejemplo, para documentar los campos aceptados por un formulario ficticio, una tabla bien formada se ve así (todos los valores son de ejemplo, no datos reales):
| Campo | Tipo | Obligatorio |
|---|---|---|
nombre | Texto | Sí |
email | Texto | Sí |
edad | Número | No |
El código markdown correspondiente sería | Campo | Tipo | Obligatorio | en la primera línea, | --- | --- | --- | en la segunda, y después una línea por fila de datos. Si escribes esto en el editor de la herramienta, la tabla renderizada aparece al instante en el panel derecho — así confirmas la alineación de columnas antes de pegarla en tu README real.
:--- alinea a la izquierda, :---: centra, y ---: alinea a la derecha.Listas de tareas y notas al pie en Markdown
- [ ] Tarea para una tarea pendiente o - [x] Tarea para una completada; para una nota al pie, usa [^1] en el texto y define [^1]: explicación en cualquier parte del documento.Las listas de tareas (checklists) son habituales en README de proyectos para mostrar el estado de un roadmap: por ejemplo, una entrada de ejemplo podría listar «- [x] Configurar el repositorio», «- [x] Escribir los tests iniciales» y «- [ ] Publicar la versión 1.0». En la vista previa de esta herramienta puedes incluso hacer clic sobre la casilla renderizada para alternar su estado y ver cómo cambia el código markdown en el editor — útil para comprobar visualmente antes de fijar el estado real de cada tarea.
Las notas al pie son útiles en artículos que citan fuentes: en lugar de saturar el párrafo con paréntesis, colocas la referencia numerada y defines su contenido al final del documento. La herramienta numera las notas automáticamente por orden de aparición y las agrupa en una sección al final de la vista previa, con enlaces de ida y vuelta entre la llamada y la nota.
~~texto~~) y detección automática de enlaces sobre la sintaxis estándar de Markdown. Los archivos README, issues y pull requests de GitHub están escritos en GFM.Exportar el resultado a HTML o PDF
Además del README, esta misma vista previa sirve para preparar una entrada de blog, unas notas de reunión o un documento que después quieras convertir a PDF para compartir con alguien que no usa Markdown. El botón «Imprimir / PDF» oculta el editor y la interfaz, dejando solo el contenido renderizado en el resultado — ideal para un documento limpio y legible.
Pega tu README, entrada de blog o notas y mira la vista previa en directo — gratis, sin registro, en tu navegador.
Probar la herramienta →Preguntas frecuentes
¿Cómo se previsualiza un README antes de subirlo a GitHub?
¿Por qué mi tabla Markdown no se ve bien?
| --- | --- |) justo debajo del encabezado, o no dejar el mismo número de columnas en cada fila. Si una fila tiene menos barras verticales | que las demás, la tabla se rompe o se desalinea. Usa la vista previa en directo para ver el resultado real antes de guardar el archivo.