Cómo usar un editor Markdown con vista previa en vivo

Markdown es rápido porque mantiene el formato simple. El problema es que algunos errores no se ven hasta pegar el texto en un README, CMS, wiki o gestor de incidencias.

El Editor Markdown de NeatForge permite escribir a la izquierda, ver la vista previa a la derecha, consultar estadísticas y copiar Markdown o HTML renderizado.

Cuándo usarlo

Úsalo cuando quieras redactar sin abrir una aplicación pesada de documentación.

Casos comunes:

• Preparar notas de versión.
• Escribir secciones de README.
• Crear borradores para un CMS.
• Revisar listas, enlaces, énfasis y bloques de código.

Si algo de lo que escribes termina renderizándose en algún sitio —que es casi todo lo que se escribe sobre software— previsualizar antes de publicar te ahorra un viaje de ida y vuelta corrigiendo formato después del envío.

La sintaxis que usarás a diario

No necesitas memorizar todo Markdown. En la práctica, un puñado de construcciones cubre el 95% de los documentos reales:

Elemento	Sintaxis	Se renderiza como
Encabezado	# Título, ## Sección	Estructura del documento
Negrita / cursiva	**negrita**, *cursiva*	Énfasis
Enlace	[texto](https://ejemplo.com)	Enlace clicable
Lista	- item o 1. item	Lista con viñetas o numerada
Código inline	`código`	Monoespaciado en línea
Bloque de código	```lang	Bloque con resaltado
Cita	> texto citado	Aviso o cita
Tabla	| a | b |	Columnas alineadas

Dos extras que conviene conocer, ambos soportados por el editor porque forman parte del Markdown de GitHub (GFM):

• Tachado: ~~texto~~ muestra el texto tachado, útil en changelogs (“obsoleto eliminado en v2”).
• Listas de tareas: - [ ] pendiente y - [x] hecho se renderizan como casillas en incidencias y READMEs de GitHub.

Flujo recomendado

1. Abre el Editor Markdown.
2. Pega tu borrador en el panel Markdown.
3. Revisa la vista previa mientras editas.
4. Usa el conteo de caracteres, palabras y líneas para controlar la longitud.
5. Copia Markdown si tu destino lo acepta, o copia HTML si tu CMS lo necesita.

Un flujo real: redactar un README

Así se ve una sesión típica escribiendo el README de un proyecto pequeño.

1. Abre el editor y pega tu borrador. Parte de tus notas existentes: apuntes de reunión, un esquema o la versión anterior del archivo. No intentes redactar prosa pulida de inmediato; primero la estructura.

2. Construye el esqueleto con encabezados. Dibuja las secciones del README: # Nombre del proyecto, ## Instalación, ## Uso, ## Licencia. Los encabezados son baratos de mover y la vista previa muestra la jerarquía tomando forma mientras trabajas.

3. Rellena los bloques de código con etiqueta de lenguaje. Los fragmentos de instalación se leen mejor con resaltado:

```bash
npm install mi-paquete
```

La etiqueta (bash, js, python, json) no es decorativa: GitHub y la mayoría de renderizadores la usan para colorear, y los bloques sin etiqueta se ven como texto gris difícil de escanear.

4. Vigila la vista previa para cazar errores. El panel derecho se actualiza al escribir y deja al descubierto tres clases de fallo: un bloque de código sin cerrar (todo lo posterior queda en monoespaciado), una tabla con pipes desalineados (se renderiza como una línea de texto crudo) y un enlace sin paréntesis de cierre ([texto](url se muestra literalmente).

5. Usa las estadísticas para mantener las secciones ajustadas. Los conteos de caracteres, palabras y líneas te ayudan a imponer reglas propias como “instalación en menos de 100 palabras” o “ninguna sección de más de 300 palabras”. Los READMEs cortos se leen; los largos se hojean.

6. Copia el formato adecuado al destino. GitHub quiere el Markdown original; el campo de un CMS suele querer HTML. Ambos están a un clic, sin envoltorios ocultos ni estilos que limpiar.

Errores comunes que rompen el renderizado

Son los fallos que una vista previa en vivo detecta pero un editor de texto plano oculta:

Indentación inconsistente en listas. Mezclar - item con contenido anidado exige 4 espacios (o tabs consistentes) para los subniveles. Si la indentación varía, las listas anidadas se aplanan como hermanas.

Las líneas en blanco importan. Encabezados, listas y bloques de código necesitan una línea vacía encima en los renderizadores estrictos. Escribir texto seguido de # Encabezado sin separación puede unir ambos en un párrafo; la vista previa muestra exactamente lo que hará tu sistema destino.

Caracteres especiales en el texto del enlace. Si el texto visible contiene un ] sin escapar, el enlace se rompe: [array[0]](url) no se renderiza. Escápalo como [array\[0\]](url).

Las tablas necesitan su fila separadora. Una tabla Markdown requiere la línea |---|---| justo bajo la cabecera. Sin ella obtienes prosa, no tabla.

Las comillas tipográficas no son Markdown. Si un procesador corrigió tus comillas a comillas curvas (" "), algunos renderizadores estrictos las tratan como texto y no como delimitadores, rompiendo negritas y cursivas. Si el formato falla sin motivo aparente, revisa las comillas primero.

Editor vs. conversor a Word

El editor sirve para redactar y previsualizar. Para exportar .docx o PDF, usa el Convertidor de Markdown y Word.

• Editor: escribir, revisar y copiar HTML.
• Conversor: descargar Word o PDF.

El patrón habitual: redacta e itera en el editor hasta que la estructura quede bien y pega el Markdown final en el conversor para el documento compartible. Así separas la fase creativa (rápida, con vista previa) de la fase de entrega (formato fijo para interesados no técnicos).

Privacidad

El editor funciona localmente en tu navegador. Tus borradores no se suben a NeatForge.

Eso lo hace apto para notas internas, changelogs, borradores de documentación y respuestas de soporte, incluido contenido bajo NDA o embargo que no debería transitar por servidores de terceros. Una vez cargada la página, incluso puedes seguir editando y copiando sin conexión, porque todo el renderizado ocurre en JavaScript local.

→ Abrir el Editor Markdown gratis