Vai al contenuto
Markdown toolkit

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.

Live preview

Come usare il convertitore

  1. 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. 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. 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. 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).

Sintassi Markdown supportata

Heading
# H1... ###### H6 (atx-style, hash + space). Setext-style (===== sotto il titolo) non supportato.
Bold / italic / strike
**bold** o __bold__, *italic* o _italic_, ~~strike~~. Combinazioni nested (***bold italic***) parzialmente supportate.
Code inline e fenced
Inline: `codice`. Fenced block: ```lang + newline + codice + newline + ```. La language hint diventa class="language-xxx" per highlighter esterni come Prism o highlight.js.
Liste
Non ordinata: - item, * item, + item. Ordinata: 1. item (qualunque numero, il render rinumera). Liste annidate: indent 2 spazi NON supportato in questo subset (limitazione consapevole, ridurrebbe parse robustness).
Blockquote
> testo. Multilinea consecutive vengono raggruppate. Niente blockquote annidato in questo subset.
Link e immagini
Link: [testo](url). Immagine: ![alt](url). Reference-style ([text][ref]) non supportato.
Tabelle GFM
Pipe-syntax con riga separator |---|---|---|. Allineamento via :-- (left, default), :-: (center), --: (right) sulla riga separator.
HR
---, ***, ___ su riga isolata.

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

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 ambiguita' 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?
Si', 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. E' 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 si', 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).

Chi sviluppa questi strumenti?

Maurizio Fonte, consulente IT senior con oltre 20 anni di esperienza in PHP, Laravel, infrastrutture Linux, cybersecurity e integrazione AI/LLM in azienda. Backend di produzione, modernizzazione di codice legacy, audit di sicurezza, agenti AI e MCP server custom: il lavoro che sta dietro a questi strumenti.

Conosci Maurizio Fonte