Questo è il riferimento alla sintassi Markdown che potete aggiungere ai preferiti e a cui tornare. Ogni elemento coperto con un esempio reale — intestazioni, enfasi, link, immagini, elenchi, blocchi di codice, tabelle, citazioni e altro. Dove una funzionalità fa parte del CommonMark standard è indicata come tale; le estensioni di GitHub Flavored Markdown (GFM) sono indicate esplicitamente così sapete cosa è supportato universalmente e cosa dipende dal renderer.
Intestazioni
Markdown ha due stili di intestazione. Lo stile ATX usa caratteri cancelletto — uno # per h1 fino a sei ###### per h6. Lo stile setext usa sottolineature di caratteri = o - e raggiunge solo h1 e h2. ATX è lo stile da usare ovunque — è esplicito, si scala a tutti e sei i livelli, ed è quello supportato da tutti gli strumenti. Un errore comune: dimenticare lo spazio dopo il #. A rigor di termini, #Intestazione non è un'intestazione in CommonMark — lo spazio è obbligatorio.
# 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
---------------In un documento reale, tipicamente si usa un h1 in cima (il titolo del documento), h2 per le sezioni principali e h3 per le sottosezioni all'interno di quelle. Andare più in profondità di h3 è un segnale che il documento potrebbe aver bisogno di ristrutturazione piuttosto che di un altro livello di annidamento.
#. #Intestazione viene silenziosamente trattato come un paragrafo da molti parser rigorosi. La specifica CommonMark richiede almeno uno spazio tra i caratteri # e il testo dell'intestazione.Formattazione del Testo
Il grassetto usa doppi asterischi o doppi underscore. Il corsivo usa singoli asterischi o singoli underscore. Grassetto-corsivo combina tre di entrambi. Il testo barrato è un'estensione GFM e usa doppie tilde. Il codice inline usa i backtick.
**Bold text** or __Bold text__
*Italic text* or _Italic text_
***Bold and italic*** or ___Bold and italic___
~~Strikethrough~~ (GFM only)
`inline code`Le varianti * e _ sono per lo più intercambiabili, ma differiscono in un caso limite: l'enfasi nel mezzo di una parola. Gli asterischi funzionano nel mezzo di una parola (in*cred*ibile viene renderizzato come incredibile), ma gli underscore no — in_cred_ibile viene renderizzato letteralmente in CommonMark perché gli underscore all'interno delle parole sono trattati come caratteri di parola, non come marcatori di enfasi. Questo è importante nella scrittura tecnica dove gli underscore compaiono negli identificatori. Come regola: usare * per l'enfasi e riservare _ solo se si ha una forte preferenza di stile. Non mescolare * e _ all'interno dello stesso span di enfasi — *testo_ non si chiuderà correttamente.
Link e Immagini
Ci sono tre stili di link: link inline, link di riferimento e autolink. Le immagini seguono la stessa sintassi dei link inline ma con un prefisso !.
<!-- 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 sintassi  mappa a un semplice tag <img> senza dimensionamento. Se si ha bisogno di controllare le dimensioni dell'immagine, è necessario passare all'HTML grezzo: <img src="url" alt="testo" width="400">. Questa è una limitazione nota — la Markdown Guide copre la soluzione alternativa.Elenchi
Gli elenchi non ordinati usano -, * o + come marcatori di punto elenco. Gli elenchi ordinati usano numeri seguiti da un punto. Annidare gli elenchi indentando di due o quattro spazi. Gli elenchi di attività (GFM) usano [ ] per gli elementi non selezionati e [x] per quelli selezionati.
<!-- 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 approvedCodice — Inline e Recintato
Il codice inline usa un singolo backtick su ogni lato. Per i blocchi, usare tre backtick (blocchi di codice recintati) e opzionalmente specificare l'identificatore del linguaggio subito dopo la recinzione di apertura — questo abilita l'evidenziazione della sintassi in GitHub, le anteprime di VS Code e la maggior parte dei generatori di siti statici. Si possono anche usare blocchi di codice indentati (4 spazi di indentazione), ma preferire i blocchi recintati: supportano i suggerimenti del linguaggio, sono espliciti e funzionano anche quando il contenuto circostante ha già indentazione.
<!-- 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
```Identificatori di linguaggio comuni: python, js o javascript, ts o typescript, bash o sh, json, yaml, html, css, sql, go, rust, java. Visualizzare in anteprima come si renderizza il Markdown usando lo strumento Anteprima Markdown.
Tabelle (GFM)
Le tabelle sono un'estensione di GitHub Flavored Markdown — non fanno parte dello standard CommonMark. Funzionano in GitHub, GitLab, la maggior parte dei generatori di siti statici e VS Code, ma non in tutti i processori Markdown. La sintassi usa il carattere pipe per separare le colonne e una riga separatrice di trattini per contrassegnare l'intestazione. I due punti nella riga separatrice controllano l'allineamento delle colonne.
| Feature | CommonMark | GFM |
| -------------------- | :--------: | :-------: |
| Headings | ✅ | ✅ |
| Bold / Italic | ✅ | ✅ |
| Fenced code blocks | ✅ | ✅ |
| Tables | ❌ | ✅ |
| Task lists | ❌ | ✅ |
| Strikethrough | ❌ | ✅ |
| Autolinks | ✅ | ✅ (ext.) |L'allineamento delle colonne è impostato nella riga separatrice. :--- allinea a sinistra (il predefinito). ---: allinea a destra. :---: centra. Non è necessario aggiungere spazi alle colonne per renderle visivamente allineate nel sorgente — è cosmetico e non ha effetto sull'output renderizzato. I pipe all'inizio e alla fine di ogni riga sono tecnicamente opzionali in GFM ma includerli è lo stile più chiaro.
Citazioni
Le citazioni precedono ogni riga con >. Le citazioni annidate usano >>. È possibile includere altri elementi Markdown — intestazioni, elenchi, blocchi di codice — all'interno di una citazione, il che le rende utili per i box di callout nella documentazione.
> **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
> ```Righe Orizzontali, Interruzioni di Riga e Escape
Queste tre funzionalità mettono in difficoltà le persone perché il loro comportamento sembra un bug finché non si conoscono le regole. Le righe orizzontali, le interruzioni di riga forzate e l'escape con backslash hanno tutti una sintassi specifica non ovvia.
<!-- 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 -->
\ ` * _ { } [ ] ( ) # + - . !\) è più robusto se l'editor o la pipeline CI rimuovono gli spazi finali. In alternativa, ristrutturare il contenuto in modo da aver bisogno di meno interruzioni di riga forzate — sono più spesso necessarie in poesia o indirizzi, non nella documentazione.HTML in Markdown
La maggior parte dei processori Markdown passa l'HTML grezzo invariato, il che sblocca una manciata di pattern utili che la pura sintassi Markdown non può esprimere. Il caso d'uso più comune nei README di GitHub è la sezione collassabile <details>/<summary>. Altri utili: <kbd> per le scorciatoie da tastiera, e attributi id personalizzati sulle intestazioni per link anchor precisi.
<!-- 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).Un'avvertenza importante: il blocco <details> richiede una riga vuota tra il tag di chiusura </summary> e il contenuto del corpo se quel contenuto contiene Markdown. Senza la riga vuota, il Markdown all'interno non verrà analizzato — verrà renderizzato come testo grezzo. È possibile pulire e formattare i file Markdown con lo strumento Formattatore Markdown.
Conclusione
Questo copre l'intera sintassi — CommonMark standard e le estensioni GFM che i developer usano quotidianamente. Per la parola autorevole sui casi limite, la specifica CommonMark e la specifica GFM sono entrambi documenti leggibili, non solo dump di riferimento. Il riferimento rapido CommonMark è un pratico riassunto su una singola pagina. Le pagine della sintassi di base e della sintassi estesa della Markdown Guide sono anche ben organizzate se si desidera una spiegazione più in prosa insieme agli esempi. Quando si ha bisogno di vedere esattamente come apparirà il Markdown prima di eseguire il commit, lo strumento Anteprima Markdown lo renderizza live nel browser. Per pulire la formattazione incoerente in un documento, il Formattatore Markdown normalizza gli stili delle intestazioni, i marcatori degli elenchi e la spaziatura. E per produrre HTML pulito dall'output Markdown, il Formattatore HTML abbellisce qualsiasi cosa il processore Markdown emetta.