# Markdown ↔ HTML round-trip: live preview e GFM tabelle pipe

> Convertitore Markdown ↔ HTML online bidirezionale. Subset GFM: heading, bold, link, immagini, code blocks fenced, liste, blockquote, tabelle.

Strumento gratuito nel browser (nessun upload): https://www.mauriziofonte.it/strumenti/convertitore-markdown-html

Conversione bidirezionale fra **Markdown** e **HTML**. Parser GFM (GitHub Flavored Markdown) lato browser: heading, bold/italic/strikethrough, code inline e fenced, liste ordinate e non, blockquote, link, immagini, tabelle pipe-syntax. Live preview HTML renderizzato + output text-area copiabile.

## Come usare il convertitore

1. **Scegli la direzione** - Markdown -> HTML per renderizzare il tuo.md in HTML pronto da incollare in un CMS o blog. HTML -> Markdown per estrarre il content da una pagina HTML e ripulirlo da inline styles, classi e tag inutili.
2. **Incolla il sorgente** - Live preview attivo: ogni input viene convertito automaticamente con debounce 300ms. Niente click su 'Converti' richiesto, ma il bottone resta disponibile per forzare il rendering.
3. **Verifica l'output** - Tre pannelli: input (sinistra), output text (destra), live preview HTML (sotto). Il preview mostra come l'HTML viene renderizzato dal browser. L'output text è la stringa pronta da copiare.
4. **Inverti la direzione** - Bottone 'Inverti direzione': sposta l'output dell'ultima conversione nell'input e flippa la direzione. Utile per round-trip MD -> HTML -> MD per verificare che il content sia normalizzato.

## Scope del parser e limiti

**GFM subset, non CommonMark completo.** Il parser implementa la sintassi più usata in pratica: heading 1-6, bold, italic, strikethrough, code inline e fenced con language hint per syntax highlighting esterno (Prism, highlight.js), liste ordinate e non, blockquote, link, immagini, tabelle pipe-syntax con allineamento, HR. Non supporta footnote, task list, definition list, math LaTeX, embed iframe, autolink GitHub-style (#123, @user). Per CommonMark spec-compliant rigoroso serve un parser server-side dedicato.

**HTML -> Markdown reverse.** La conversione inversa attraversa l'albero DOM via DOMParser nativo del browser e produce il Markdown equivalente per heading, paragrafi, bold, italic, code, link, immagini, blockquote, liste e tabelle. Tutti gli inline styles, le classi CSS, i div container e gli span senza semantica vengono ignorati: il content semantico viene estratto e il chrome di presentazione scartato. Il comportamento è voluto per portabilità del contenuto. Non gestisce HTML annidato complesso, iframe, script, form.

**Privacy operativa.** Il parsing è interamente locale al browser: il contenuto di un post in bozza, di documentazione interna o di note personali non transita per backend di terze parti. Utile in contesti dove il content stesso ha valore (NDA, documentazione enterprise, materiale pre-pubblicazione).

## Glossario

- **Markdown**: Sintassi plain-text per testo formattato, creata da John Gruber nel 2004. Convertita in HTML da un parser. Standard de facto per README GitHub, documentazione tecnica, blog post.
- **GFM**: GitHub Flavored Markdown, estensione di Markdown con tabelle, task list, fenced code blocks, autolink. Supportata nativamente da GitHub, GitLab, molti CMS moderni.
- **CommonMark**: Specifica formale di Markdown (commonmark.org), 2014, mira a risolvere ambiguità della sintassi originale. Implementazioni: cmark, markdown-it, commonmark.js.
- **Fenced code block**: Blocco di codice delimitato da triple backtick (`````) o triple tilde (`~~~`), opzionalmente con language hint per syntax highlighting. Alternativa al code block via indent 4 spazi (qui non supportato).
- **Inline parser**: Component del parser Markdown che processa la sintassi inline (bold, italic, code, link, image) all'interno di un blocco già identificato. Distinto dal block parser che identifica heading, list, blockquote.
- **DOM walker**: Tecnica di traversal di un albero HTML via DOM API native browser (DOMParser, childNodes, tagName). Usata qui per HTML -> Markdown reverse: walk recursivo, dispatch per tagName, output Markdown string.

## Domande frequenti

### Markdown -> HTML produce esattamente lo stesso HTML di GitHub?

No. GitHub usa cmark-gfm + sanitizer custom. Questo parser è un subset GFM, non implementa: footnote, task list `- [ ]`, autolink di issue/PR (`#123`), mention `@user`, emoji shortcode `:tada:`. Per render compatibile GitHub esatto serve cmark-gfm server-side.

### HTML -> Markdown perde informazioni?

Sì, volutamente. Tutti gli inline styles, le classi CSS, i div container, span senza semantica vengono ignorati. Il converter estrae il content semantico (heading, paragrafi, bold, italic, code, link, immagini, liste, tabelle) e scarta il chrome di presentazione. È il comportamento desiderato per content portability.

### Posso usare HTML inline dentro Markdown?

Parzialmente. Markdown standard permette HTML inline, ma questo parser fa escape di tutti i caratteri HTML in input prima di applicare le regole. Quindi `<span>hello</span>` in input diventa testo letterale, non span renderizzato. Per HTML inline mantenuto serve un parser commonmark-spec compliant.

### Le tabelle GFM con celle multilinea funzionano?

No. Il parser assume una riga = una row. Se una cella contiene `<br>` o newline, viene rotta. Workaround: tieni le righe della tabella su una sola linea oppure converti la tabella in HTML manuale prima di incollarla.

### Perché niente live preview con dual-pane sync scroll?

Scope deliberatamente limitato. La live preview qui è sempre full-output, no scroll-sync. Per editor dual-pane con sync esistono StackEdit, Typora, Obsidian; questo è un convertitore one-shot, non un editor.

### Round-trip MD -> HTML -> MD produce lo stesso file?

Tipicamente no, ma il content semantico è preservato. Differenze comuni: spazi/newline normalizzati, ordine attributi tag, tabelle con colonne di width identica per allineamento (perse nel reverse). Per file Markdown 'puliti' (no HTML inline, no edge case), il round-trip dovrebbe essere idempotente alla seconda passata.

### Posso processare file.md grandi (1MB+)?

Tecnicamente sì, ma il parser è sincrono e single-pass linea-per-linea. Per file molto grandi (10MB+) il browser potrebbe freezare per qualche secondo. Per batch processing serie usa un parser server-side (Pandoc, marked CLI).

---
Uno strumento di Maurizio Fonte, senior backend engineer. Tutti gli strumenti: https://www.mauriziofonte.it/strumenti/