Esta es la referencia de sintaxis Markdown que puedes marcar y volver a consultar. Cada elemento cubierto con un ejemplo real — encabezados, énfasis, enlaces, imágenes, listas, bloques de código, tablas, citas en bloque y más. Donde una característica es parte del estándar CommonMark está marcada como tal; las extensiones de GitHub Flavored Markdown (GFM) se señalan explícitamente para que sepas qué es universalmente compatible y qué depende del renderizador.
Encabezados
Markdown tiene dos estilos de encabezados. El estilo ATX usa caracteres de almohadilla — un # para h1 hasta seis ###### para h6. El estilo setext usa subrayados de caracteres = o - y solo llega a h1 y h2. ATX es el estilo que deberías usar en todas partes — es explícito, escala a los seis niveles y es lo que soporta cada herramienta. Un error común: olvidar el espacio después del #. Estrictamente hablando, #Encabezado no es un encabezado en CommonMark — el espacio es obligatorio.
# Page Title (h1)
## Section Heading (h2)
### Subsection (h3)
#### Detail Level (h4)
##### Minor Heading (h5)
###### Smallest Heading (h6)
---
<!-- Setext style — only h1 and h2, rarely used -->
Page Title
==========
Section Heading
---------------En un documento real, típicamente usas un h1 al inicio (el título del documento), h2 para secciones principales y h3 para subsecciones dentro de esas. Ir más profundo que h3 es una señal de que tu documento podría necesitar reestructuración en lugar de otro nivel de anidamiento.
#. #Encabezado es tratado silenciosamente como un párrafo por muchos analizadores estrictos. La especificación CommonMark requiere al menos un espacio entre los caracteres # y el texto del encabezado.Formato de texto
La negrita usa dobles asteriscos o dobles guiones bajos. La itálica usa asteriscos simples o guiones bajos simples. Negrita-itálica combina tres de cualquiera. El tachado es una extensión GFM y usa dobles tildes. El código en línea usa backticks.
**Bold text** or __Bold text__
*Italic text* or _Italic text_
***Bold and italic*** or ___Bold and italic___
~~Strikethrough~~ (GFM only)
`inline code`Las variantes * y _ son en su mayoría intercambiables, pero difieren en un caso límite: énfasis en medio de palabra. Los asteriscos funcionan en medio de palabra (in*cre*íble se renderiza como increíble), pero los guiones bajos no — in_cre_íble se renderiza literalmente en CommonMark porque los guiones bajos dentro de palabras se tratan como caracteres de palabra, no como marcadores de énfasis. Esto importa en la escritura técnica donde los guiones bajos aparecen en identificadores. Como regla: usa * para énfasis y reserva _ solo si tienes una fuerte preferencia de estilo. No mezcles * y _ dentro del mismo span de énfasis — *texto_ no cerrará correctamente.
Enlaces e imágenes
Hay tres estilos de enlace: enlaces en línea, enlaces de referencia y autoenlaces. Las imágenes siguen la misma sintaxis que los enlaces en línea pero con un prefijo !.
<!-- Inline link: [text](url) or [text](url "title") -->
Read the [CommonMark spec](https://spec.commonmark.org/current/ "CommonMark Specification")
Format Markdown with the [Markdown Formatter](/markdown-formatter)
<!-- Reference link: define the URL separately — cleaner in long documents -->
Check the [GFM spec][gfm] for GitHub-specific extensions.
[gfm]: https://github.github.com/gfm/
<!-- Autolink: angle brackets make a URL or email clickable -->
<https://commonmark.org>
<[email protected]>
<!-- Image: same as inline link but with ! prefix -->
width o height. La sintaxis  se mapea a una etiqueta <img> simple sin dimensionado. Si necesitas controlar las dimensiones de la imagen, tienes que usar HTML crudo: <img src="url" alt="texto" width="400">. Esta es una limitación conocida — la Markdown Guide cubre la solución alternativa.Listas
Las listas desordenadas usan -, * o + como marcadores de viñeta. Las listas ordenadas usan números seguidos de un punto. Anida listas indentando dos o cuatro espacios. Las listas de tareas (GFM) usan [ ] para sin marcar y [x] para marcado.
<!-- Unordered list -->
- Install dependencies
- Configure environment variables
- Run the dev server
<!-- Ordered list -->
1. Clone the repository
2. Run `npm install`
3. Copy `.env.example` to `.env` and fill in values
4. Run `npm run dev`
<!-- Nested list (indent 2 or 4 spaces) -->
- Backend
- Set up PostgreSQL
- Configure connection string
- Frontend
- Install Tailwind
- Configure PostCSS
<!-- Task list (GFM) — great for README checklists -->
## Release Checklist
- [x] Unit tests passing
- [x] End-to-end tests passing
- [ ] Changelog updated
- [ ] Docker image tagged
- [ ] Deployment approvedCódigo — En línea y delimitado
El código en línea usa un solo backtick en cada lado. Para bloques, usa triples backticks (bloques de código delimitados) y opcionalmente especifica el identificador de lenguaje justo después de la valla de apertura — esto activa el resaltado de sintaxis en GitHub, vistas previas de VS Code y la mayoría de los generadores de sitios estáticos. También puedes usar bloques de código indentados (4 espacios de indentación), pero prefiere los bloques delimitados: soportan sugerencias de lenguaje, son explícitos y funcionan incluso cuando el contenido circundante también tiene indentación.
<!-- Inline code -->
Use the `fetch()` API to make HTTP requests.
Set the `Content-Type` header to `application/json`.
<!-- Fenced code block with language hint -->
```python
import json
with open("config.json") as f:
config = json.load(f)
print(config["database"]["host"])
```
```typescript
interface ApiResponse<T> {
data: T;
status: number;
message: string;
}
async function fetchUser(id: string): Promise<ApiResponse<User>> {
const res = await fetch(`/api/users/${id}`);
return res.json();
}
```
```bash
# Install dependencies and start the dev server
npm install
npm run dev
```
```json
{
"name": "my-project",
"version": "1.0.0",
"scripts": {
"dev": "vite",
"build": "tsc && vite build"
}
}
```
```yaml
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test
```Identificadores de lenguaje comunes: python, js o javascript, ts o typescript, bash o sh, json, yaml, html, css, sql, go, rust, java. Previsualiza cómo se renderiza tu Markdown usando la herramienta Vista Previa de Markdown.
Tablas (GFM)
Las tablas son una extensión de GitHub Flavored Markdown — no forman parte del estándar CommonMark. Funcionan en GitHub, GitLab, la mayoría de los generadores de sitios estáticos y VS Code, pero no en todos los procesadores Markdown. La sintaxis usa caracteres de pipe para separar columnas y una fila separadora de guiones para marcar el encabezado. Los dos puntos en la fila separadora controlan la alineación de columnas.
| Feature | CommonMark | GFM |
| -------------------- | :--------: | :-------: |
| Headings | ✅ | ✅ |
| Bold / Italic | ✅ | ✅ |
| Fenced code blocks | ✅ | ✅ |
| Tables | ❌ | ✅ |
| Task lists | ❌ | ✅ |
| Strikethrough | ❌ | ✅ |
| Autolinks | ✅ | ✅ (ext.) |La alineación de columnas se establece en la fila separadora. :--- alinea a la izquierda (el predeterminado). ---: alinea a la derecha. :---: centra. No necesitas rellenar columnas con espacios para alinearlas visualmente en la fuente — eso es cosmético y no tiene efecto en la salida renderizada. Los pipes al inicio y al final de cada fila son técnicamente opcionales en GFM pero incluirlos es el estilo más claro.
Citas en bloque
Las citas en bloque prefijan cada línea con >. Las citas anidadas usan >>. Puedes incluir otros elementos Markdown — encabezados, listas, bloques de código — dentro de una cita en bloque, lo que las hace útiles para cuadros de notas en la documentación.
> **Note:** As of Node.js 18, the `fetch` API is available globally
> without importing anything. No more `node-fetch` dependency.
> This is a quote that spans
> multiple lines.
>
> And has a second paragraph.
> Outer quote.
>
> > Nested quote — useful for "quoting a quote" in changelogs
> > or spec discussions.
<!-- Blockquote containing a code block — useful for quoting error messages -->
> The migration failed with:
>
> ```
> ERROR: relation "users" already exists
> ```Reglas horizontales, saltos de línea y escapes
Estas tres características confunden a la gente porque su comportamiento parece un error hasta que conoces las reglas. Las reglas horizontales, los saltos de línea forzados y el escape con barra invertida tienen todos una sintaxis específica que no es obvia.
<!-- Horizontal rules: three or more of ---, ***, or ___ on their own line -->
---
***
___
<!-- All three render as <hr>. Most common style is --- -->
<!-- Hard line breaks: end a line with two trailing spaces, or use backslash -->
First line with two trailing spaces
Second line (rendered as a new line, not a new paragraph)
First line with backslash\
Second line (same result)
<!-- A single newline in Markdown source is NOT a line break — it's a space.
Two newlines = a paragraph break. -->
<!-- Backslash escaping: put before any Markdown character to render it literally -->
*This is not italic*
# This is not a heading
[Not a link](not-a-url)
`Not inline code`
<!-- Characters that can be escaped -->
\ ` * _ { } [ ] ( ) # + - . !\) es más robusto si tu editor o pipeline de CI elimina los espacios al final. Alternativamente, reestructura tu contenido para necesitar menos saltos de línea forzados — son más frecuentemente necesarios en poesía o direcciones, no en documentación.HTML en Markdown
La mayoría de los procesadores Markdown pasan el HTML crudo sin cambios, lo que desbloquea algunos patrones útiles que la sintaxis Markdown pura no puede expresar. El caso de uso más común en los READMEs de GitHub es la sección colapsable <details>/<summary>. Otros útiles: <kbd> para atajos de teclado y atributos id personalizados en encabezados para enlaces de ancla precisos.
<!-- Collapsible section — very common in GitHub READMEs -->
<details>
<summary>Click to expand: Advanced configuration options</summary>
You can override the defaults by creating a `config.local.json` file
in the project root. Supported keys:
| Key | Default | Description |
| ---------- | ------- | ----------------------- |
| `port` | 3000 | Dev server port |
| `logLevel` | `info` | One of debug/info/warn |
</details>
<!-- Keyboard shortcuts -->
Press <kbd>Ctrl</kbd>+<kbd>Shift</kbd>+<kbd>P</kbd> to open the command palette.
<!-- Custom heading ID for anchor links -->
<h2 id="configuration-reference">Configuration Reference</h2>
<!-- Link to that heading from anywhere -->
See the [Configuration Reference](#configuration-reference).Una advertencia importante: el bloque <details> requiere una línea en blanco entre la etiqueta de cierre </summary> y el contenido del cuerpo si ese contenido contiene Markdown. Sin la línea en blanco, el Markdown dentro no se analizará — se renderizará como texto plano. Puedes limpiar y formatear tus archivos Markdown con la herramienta Formateador Markdown.
Conclusión
Eso cubre la sintaxis completa — CommonMark estándar y las extensiones GFM que los desarrolladores usan diariamente. Para la última palabra sobre casos límite, la especificación CommonMark y la especificación GFM son ambas documentos legibles, no solo dumps de referencia. La referencia rápida CommonMark es un resumen práctico en una sola página. Las páginas de sintaxis básica de Markdown Guide y sintaxis extendida también están bien organizadas si quieres más explicación en prosa junto a ejemplos. Cuando necesitas ver exactamente cómo lucirá tu Markdown antes de hacer commit, la herramienta Vista Previa de Markdown lo renderiza en vivo en tu navegador. Para limpiar el formato inconsistente en un documento, el Formateador Markdown normaliza los estilos de encabezados, los marcadores de lista y el espaciado. Y para producir HTML limpio de la salida Markdown, el Formateador HTML embellece lo que emite el procesador Markdown.