TOML vs JSON vs YAML: quale formato di config scegliere?

Ecco la versione breve di TOML vs JSON vs YAML: JSON è lo standard di interscambio tra macchine che ogni linguaggio sa analizzare, YAML è il formato a misura d’uomo che fa girare Kubernetes e le pipeline CI, e TOML è il formato esplicito e tipizzato pensato per la configurazione di strumenti e applicazioni come Cargo.toml e pyproject.toml. Nessun formato vince ovunque. Il formato di file di configurazione giusto dipende da tre cose: chi lo modifica, se ti servono i commenti e quanto rigidi devono essere i tipi.

Una regola pratica veloce. Se lo scrive una macchina e lo legge una macchina, usa JSON. Se una persona modifica a mano ogni giorno un’infrastruttura profondamente annidata, YAML si merita la sua complessità. Se vuoi una configurazione ovvia e tipizzata, difficile da sbagliare, TOML è la scelta più sicura. Questi formati non sono davvero concorrenti. Occupano corsie diverse: JSON per le macchine, YAML per il DevOps, TOML per la configurazione degli strumenti. Qui sotto trovi esempi affiancati, le differenze che causano davvero bug e una matrice decisionale che puoi applicare al tuo prossimo progetto.

La risposta in 30 secondi

Se hai solo mezzo minuto, questa tabella è il confronto tra formati di file di configurazione che cercavi.

	JSON	YAML	TOML
Commenti	No	Sì (#)	Sì (#)
Tipi di dato	Espliciti, minimali	Impliciti (dedotti dalla forma)	Espliciti, ricchi
Date native	No	Dipende dalla versione	Sì (quattro tipi)
Stile di annidamento	Parentesi graffe {}	Rientro	Header [section]
Sensibile al rientro	No	Sì (tab vietati)	No
Stringhe multi-riga	No (solo \n)	Sì (| e >)	Sì (""")
Virgole finali	Vietate	N/D	Consentite negli array
Superset di JSON	—	Sì (1.2)	No
Ideale per	API, scambio dati	K8s, CI, Ansible	Config di tooling Rust/Python

Da quella tabella seguono tre verdetti in una riga:

• Scegli JSON quando il file è prodotto e consumato da programmi: payload di API, package.json, tsconfig.json, qualsiasi cosa attraversi il confine tra sistemi.
• Scegli YAML quando le persone modificano a mano una configurazione profonda e annidata e l’ecosistema se la aspetta già: manifest Kubernetes, GitHub Actions, Docker Compose, playbook Ansible.
• Scegli TOML quando vuoi una configurazione chiara e tipizzata per uno strumento o un’applicazione, per lo più piatta con qualche sezione, modificata da contributori di diversa esperienza: Cargo.toml, pyproject.toml, Hugo, Netlify.

Quei verdetti reggono per ragioni precise, ed è proprio lì che si nascondono i bug veri.

La stessa config, in tre modi

Il modo più rapido per vedere la differenza è scrivere la stessa configurazione tre volte. Ecco una piccola config di servizio: un nome e una versione, un paio di flag di primo livello, un elenco di funzionalità e un blocco database annidato.

JSON:

{
  "name": "acme-api",
  "version": "2.4.0",
  "debug": false,
  "released": "2026-07-02",
  "features": ["auth", "metrics", "tracing"],
  "database": {
    "host": "db.internal",
    "port": 5432,
    "max_connections": 100
  }
}

YAML:

name: acme-api
version: "2.4.0"
debug: false
released: "2026-07-02"
features:
  - auth
  - metrics
  - tracing
database:
  host: db.internal
  port: 5432
  max_connections: 100

TOML:

name = "acme-api"
version = "2.4.0"
debug = false
released = "2026-07-02"
features = ["auth", "metrics", "tracing"]

[database]
host = "db.internal"
port = 5432
max_connections = 100

Tutti e tre descrivono dati identici. Guarda dove inciampa il tuo occhio. JSON porta con sé la punteggiatura maggiore: ogni chiave è tra doppi apici, ogni livello aggiunge graffe e una singola virgola finale di troppo è un errore di sintassi. YAML elimina quasi tutto questo, così la struttura nasce dal solo rientro, che si legge benissimo finché non ci si infila un tab. TOML sta nel mezzo: apici solo sulle stringhe, coppie key = value e un header [database] che nomina il blocco annidato come farebbe un vecchio file INI. Nota che il campo released è una stringa tra apici in tutti e tre, così qui i dati restano identici. È una scelta deliberata, perché le date sono esattamente il punto in cui questi formati smettono di essere d’accordo.

JSON — lo standard di interscambio tra macchine

JSON è il formato che usi senza pensarci, e di solito è l’istinto giusto. Ogni linguaggio diffuso include un parser, ogni API HTTP lo parla e la sua grammatica è abbastanza piccola da tenerla a mente. È rigoroso e privo di ambiguità: una stringa è una stringa, 5432 è un numero, true è un booleano e c’è esattamente un modo per scrivere ciascuno. È questo rigore che rende JSON sicuro da spedire tra sistemi che non si sono mai incontrati. Quando un servizio Node invia JSON a un servizio Go, entrambi concordano sul significato byte per byte.

Proprio quella rigidità è il motivo per cui JSON domina il suo terreno. package.json, tsconfig.json e composer.json sono JSON perché gli strumenti li generano e riscrivono di continuo, e una configurazione scritta da una macchina vuole un formato rigoroso per le macchine. Per i payload di API e le code di messaggi non c’è semplicemente motivo di scegliere altro.

Le debolezze di JSON emergono tutte nel momento in cui una persona deve modificarlo a mano. Non ci sono commenti. Non ci sono virgole finali, quindi riordinare un elenco significa sistemare le virgole. Non ci sono stringhe multi-riga, solo escape \n. Ogni chiave ha bisogno dei doppi apici. E non c’è un tipo data, quindi 2026-07-02 deve vivere come stringa tra apici ed essere analizzato per convenzione. Per un file di configurazione che una persona mantiene, queste lacune sommate diventano attrito.

Il problema del “JSON senza commenti”

La funzionalità di JSON più richiesta in assoluto è proprio quella che Douglas Crockford ha lasciato fuori di proposito: i commenti. Il suo ragionamento era che i commenti invogliavano le persone a intrufolare direttive di parsing nei file di configurazione, rompendo l’interoperabilità. Qualunque cosa tu pensi di quella scelta, non puoi annotare una config JSON semplice, il che è doloroso per qualsiasi cosa mantenuta da persone. La soluzione pratica è un superset. JSON5 aggiunge commenti, virgole finali, chiavi senza apici e apici singoli; JSONC (JSON with Comments) è la variante più leggera che VS Code usa per le sue impostazioni. Entrambi mantengono la forma di JSON rendendolo modificabile. Se ti servono i commenti ma vuoi restare nella famiglia JSON, leggi la nostra guida alla formattazione di JSON5 e JSONC per capire quando usare ciascuno e come tenere buoni gli strumenti.

YAML — lo standard DevOps a misura d’uomo

YAML è ottimizzato per la persona alla tastiera. Supporta i commenti, il suo layout basato sul rientro mantiene pulite le strutture profondamente annidate e gli anchor ti permettono di definire un blocco una volta e riutilizzarlo con un alias invece di copiare e incollare:

defaults: &defaults
  timeout: 30
  retries: 3

staging:
  <<: *defaults
  host: staging.internal

production:
  <<: *defaults
  host: prod.internal

L’anchor &defaults dà un nome a un blocco, e <<: *defaults lo unisce a entrambi gli ambienti, così una modifica al timeout condiviso avviene in un solo punto. Né JSON né TOML hanno qualcosa di simile. È questa leggibilità il motivo per cui YAML è diventato la lingua franca delle operations: manifest Kubernetes, workflow di GitHub Actions, file Docker Compose e playbook Ansible sono tutti YAML. Quando la tua config è profonda cinque livelli e una persona la ritocca ogni giorno, la scarsa punteggiatura di YAML è un vero sollievo.

Il prezzo è complessità e sorprese. La specifica di YAML 1.2 è ampia, e la piena conformità è rara, quindi parser diversi non concordano ai margini. Il rientro è significativo, i tab sono vietati del tutto e uno spazio disallineato può cambiare il significato o impedire il parsing. Il lato più affilato è la tipizzazione implicita: YAML indovina il tipo di uno scalare senza apici dalla sua forma, e indovina male abbastanza spesso da essersi guadagnato un soprannome.

Il problema Norvegia in un paragrafo

Scrivi country: NO in YAML e molti parser ti restituiscono il booleano false, non la stringa "NO", perché YAML 1.1, che gran parte del tooling Kubernetes segue ancora, tratta NO, YES, ON, OFF, Y e N come booleani. Il codice paese della Norvegia diventa false, in silenzio, senza alcun errore. La stessa tipizzazione implicita trasforma 0755 in un numero ottale e 1.20 in 1.2. La soluzione è noiosa ma affidabile: metti tra apici le stringhe che potrebbero essere scambiate per qualcos’altro. Questo autogol è abbastanza celebre da meritare un approfondimento a sé, con tanto di disservizi reali e la storia di YAML 1.1 contro 1.2, nella nostra guida al problema Norvegia di YAML. Per questo articolo, la conclusione è semplice: la comodità di YAML e la sua pericolosità nascono dalla stessa caratteristica.

YAML vince quando le persone modificano ogni giorno una config profondamente annidata e l’ecosistema circostante la richiede già. Se stai scrivendo un chart Helm, stai scrivendo YAML, e va bene così.

TOML — configurazione esplicita pensata per il tooling

TOML (Tom’s Obvious, Minimal Language, creato da Tom Preston-Werner) è stato progettato per essere il formato di configurazione che gli utenti di YAML avrebbero voluto: leggibile, ma senza indovinelli. Il suo tratto distintivo è l’esplicitezza. I tipi non sono ambigui, quindi port = 5432 è sempre un intero e name = "acme" è sempre una stringa, senza inferenze basate sulla forma su cui inciampare. La sintassi di TOML prende in prestito l’header [section] dai file INI, il che rende scorribile il primo livello di una config, e non è sensibile al rientro, quindi gli spazi non cambiano mai il significato. La specifica di TOML 1.0.0 è piccola e stabile, il che è un pregio: c’è meno da ricordare male.

La capacità di punta di TOML sono i tipi nativi di data e ora, che né JSON né lo YAML semplice gestiscono in modo pulito. Ne ha quattro: date-time con offset e fuso orario (1979-05-27T07:32:00Z), date-time locale senza fuso, data locale (1979-05-27, solo un giorno di calendario) e ora locale (07:32:00). Vuol dire che una data di deploy resta una data vera invece di una stringa da rianalizzare.

Tre elementi della sintassi di TOML fanno gran parte del lavoro. Un header [section] apre una tabella; un header con punti come [tool.ruff] annida una tabella dentro un’altra senza rientri aggiuntivi; e una tabella inline { version = "1.0", features = ["derive"] } racchiude un piccolo oggetto su una sola riga. Le sezioni ripetute usano un header raddoppiato, l’array di tabelle:

[[servers]]
name = "alpha"
ip = "10.0.0.1"

[[servers]]
name = "beta"
ip = "10.0.0.2"

Quel blocco diventa un array JSON di due oggetti sotto la chiave servers. Si legge bene per un elenco piatto, che è esattamente ciò di cui ha bisogno la maggior parte delle config di strumenti.

Le debolezze sono reali ma circoscritte. TOML non ha un tipo null, quindi un valore assente è semplicemente una chiave omessa. L’annidamento profondo diventa verboso, perché ogni livello di una struttura annidata e ripetuta ripete l’intero header [[path]], che si fa più rumoroso dell’equivalente YAML. E TOML è più giovane e meno universale di JSON o YAML, quindi non tutti gli strumenti lo parlano. TOML dà il meglio per una configurazione per lo più piatta con una manciata di sezioni etichettate, che descrive la stragrande maggioranza delle config di strumenti.

Perché TOML per Rust e Python?

L’ascesa di TOML segue due ecosistemi che l’hanno adottato come standard. Il gestore di pacchetti di Rust, Cargo, usa Cargo.toml per ogni crate, quindi ogni sviluppatore Rust legge e scrive TOML fin dal primo giorno. Python ha seguito: la PEP 518 ha introdotto pyproject.toml per dichiarare i requisiti di build, e la PEP 621 ha standardizzato i metadati di progetto (nome, versione, dipendenze e sezioni [tool.*]) nello stesso file, sostituendo un insieme sparso di setup.py, setup.cfg e config per singolo strumento. Oltre a questi due, Hugo, Netlify, Poetry e Foundry usano TOML come impostazione predefinita. Il filo comune è la configurazione di tooling che i contributori modificano a mano e che trae vantaggio dall’essere ovvia anziché ingegnosa.

Testa a testa — le differenze che mordono davvero

Le tabelle delle funzionalità sono ordinate. I bug no. Queste sono le differenze specifiche che causano problemi reali, ognuna con un piccolo esempio che puoi far passare in qualsiasi parser.

Commenti

JSON non ha alcuna sintassi per i commenti. TOML e YAML usano entrambi # fino a fine riga.

# TOML: un commento iniziale
port = 5432  # e uno finale

# YAML: stile di commento identico
port: 5432   # commento finale

Nel momento in cui incolli un // o un # in JSON rigoroso, il parsing fallisce. Non è una questione estetica. Una config mantenuta da una persona senza commenti accumula conoscenza tribale che vive solo nella testa di qualcuno.

Tipi di dato e date

I tipi di JSON sono espliciti ma scarni, senza un tipo data. I tipi di TOML sono espliciti e ricchi. Quelli di YAML sono impliciti e, come visto sopra, ogni tanto sbagliati. Le date sono la divisione più netta. TOML esprime nativamente tutti e quattro i tipi:

odt = 1979-05-27T07:32:00Z   # date-time con offset (ha il fuso orario)
ldt = 1979-05-27T07:32:00    # date-time locale (senza fuso)
ld  = 1979-05-27             # data locale (un giorno di calendario)
lt  = 07:32:00               # ora locale

Converti quel TOML in JSON e ogni valore diventa una stringa che conserva il suo significato: una data locale resta "1979-05-27" invece di essere gonfiata in un finto timestamp a mezzanotte. Il nostro convertitore da TOML a JSON preserva esattamente quel tipo di data, cosa che molti convertitori ingenui sbagliano. YAML, invece, può trattare o meno 1979-05-27 come una data a seconda del parser e della versione dello schema, che è proprio l’ambiguità che non vuoi in una config di produzione.

Profondità di annidamento

Più la tua config si annida in profondità, più i formati divergono. Prendi un piccolo albero in stile Docker Compose:

services:
  web:
    build:
      context: .
      args:
        NODE_ENV: production
    ports:
      - "8080:8080"

YAML esprime la profondità con il solo rientro e resta compatto. La stessa struttura in TOML ti costringe a scrivere per esteso l’intero percorso in ogni header e a spostare i valori scalari prima delle tabelle figlie:

[services.web]
ports = ["8080:8080"]

[services.web.build]
context = "."

[services.web.build.args]
NODE_ENV = "production"

JSON porta l’albero in graffe annidate, il che è privo di ambiguità ma carico di punteggiatura. Per una config poco profonda i tre sembrano simili; oltre i tre o quattro livelli, YAML è visibilmente più snello e TOML visibilmente più ripetitivo. Quest’unica differenza spiega perché Kubernetes ha scelto YAML e Cargo ha scelto TOML.

Sensibilità al rientro

Solo a YAML importano gli spazi. In JSON e TOML puoi rientrare come preferisci, o non rientrare affatto, e il significato è identico. In YAML il rientro è la struttura, e i tab sono illegali, quindi un editor che inserisce un tab o un blocco incollato alla profondità sbagliata cambia il documento in silenzio o si rifiuta di caricarlo. Un elemento di elenco rientrato di uno spazio di troppo può attaccarsi alla chiave genitore sbagliata senza alcun errore, un bug esasperante da individuare a occhio perché il file sembra comunque a posto. Se i tuoi contributori usano editor e impostazioni diversi, è una tassa fissa che YAML impone e gli altri due no, ed è un ottimo motivo per far girare un linter in CI su qualsiasi config YAML di grandi dimensioni.

Stringhe multi-riga

JSON non può contenere un a capo letterale dentro una stringa; lo scrivi come escape \n. YAML e TOML hanno entrambi vere stringhe multi-riga.

{ "note": "line one\nline two" }

note: |
  line one
  line two

note = """
line one
line two
"""

Il | di YAML conserva gli a capo (un blocco > invece li ripiega in spazi), e il """ di TOML si comporta in modo simile, eliminando l’a capo che segue immediatamente gli apici di apertura. Per script incorporati, SQL o testi di aiuto, questo da solo può decidere il formato.

Virgole finali e rigore

JSON è il più rigoroso dei tre. Una virgola finale dopo l’ultimo elemento di un array è un errore di sintassi:

# TOML valido — la virgola finale va bene
ports = [
  8001,
  8002,
]

La stessa virgola finale dopo 8002 in JSON non viene analizzata, ed è per questo che aggiungere una riga a un array JSON così spesso significa anche sistemare la virgola sulla riga sopra. TOML consente la virgola finale, e la sintassi di YAML con un trattino per riga aggira del tutto la questione. Il rigore è una virtù per l’interscambio tra macchine e una seccatura per la modifica a mano, che è lo stesso compromesso visto dall’altro lato. È anche l’attrito che JSON5 e JSONC si sono proposti di eliminare, specificamente per JSON.

Interi grandi e il tetto di 2^53

Tutti e tre i formati possono scrivere un intero a 64 bit come testo. I guai iniziano quando quel valore passa attraverso JavaScript, perché i numeri JSON del browser sono double IEEE-754 e possono rappresentare esattamente gli interi solo fino a 2^53 − 1 (9007199254740991). Un ID Snowflake o un timestamp in nanosecondi è più grande di così, quindi un round-trip attraverso uno strumento basato su JS lo arrotonda e corrompe il valore:

snowflake = 1420070400000000000   # esatto nel testo TOML

{ "snowflake": "1420070400000000000" }

La soluzione affidabile in ogni formato è memorizzare valori simili come stringhe tra apici, così nessun parser numerico li tocca mai. Non è un difetto di un formato in particolare; è un limite del runtime che esegue la conversione. I nostri convertitori ti avvisano quando un intero supera quella soglia invece di corromperlo in silenzio.

Come scegliere — matrice decisionale e diagramma di flusso

Quando devi davvero decidere quale formato di configurazione usare, percorri le domande in ordine e fermati al primo sì convinto.

1. Il file è scritto e letto principalmente da programmi, oppure l’ecosistema impone già un formato? Se sì, usa JSON. Un payload di API è JSON. Un file accanto a package.json è JSON. Non combattere contro gli strumenti.
2. Le persone modificano a mano ogni giorno una configurazione profonda e annidata, dentro uno stack che se l’aspetta (Kubernetes, CI, Ansible)? Se sì, usa YAML, e adotta una convenzione sugli apici per schivare il problema Norvegia.
3. È la config di uno strumento o di un’applicazione, per lo più piatta con qualche sezione, modificata da contributori di diversa esperienza, dove tipizzato e ovvio batte conciso? Se sì, usa TOML.

Se due risposte pareggiano, decidi con questa mappa di assi:

Requisito	Scelta migliore	Perché
Commenti nel file	TOML o YAML	JSON non ne ha
Valori di data/ora nativi	TOML	Quattro tipi di data espliciti
Annidamento molto profondo	YAML	Il rientro resta compatto
Zero sorprese sugli spazi	JSON o TOML	Non sensibili al rientro
Vincolato a un file dell’ecosistema	JSON	package.json, tsconfig.json
Modifiche umane, poche sezioni	TOML	Tipi espliciti, header in stile INI
Scambio da macchina a macchina	JSON	Universale, rigoroso, veloce
L’inferenza di tipo non deve mai indovinare	JSON o TOML	YAML deduce in modo implicito

La maggior parte dei progetti finisce per usarne più di uno. Un repository potrebbe avere un package.json JSON che non tocca mai a mano, un pyproject.toml TOML per il suo tooling Python, workflow YAML in .github e un file .env per i segreti locali che non segue nessuna di queste grammatiche. Quel mix è normale, ed è proprio il punto: ogni file vive nel formato adatto a chi lo modifica. Se il livello .env fa parte del tuo setup, la nostra guida al formato dei file .env spiega dove si colloca accanto alla config JSON e come convertire tra i due.

Convertire tra TOML, JSON e YAML

Finisci per convertire tra questi formati più spesso di quanto ti aspetteresti. Un job CI legge un pyproject.toml scritto a mano e gli serve come JSON per alimentare una dashboard delle dipendenze. Una migrazione sposta un’app da una config YAML a TOML per una tipizzazione più rigorosa. Una code review è più facile quando confronti la forma JSON di due file invece dei loro originali sensibili agli spazi. Ogni direzione ha una sua trappola da conoscere prima di incollare.

Da TOML a JSON. Il rischio principale sono le date. Una data locale come 1979-05-27 dovrebbe restare una data di calendario, non diventare un timestamp UTC a mezzanotte che inventa un’ora e un fuso orario. Anche i commenti vengono persi, dato che JSON non può contenerli. Il convertitore da TOML a JSON preserva fedelmente ogni tipo di data, così i round-trip restano senza perdite.

Da JSON a TOML. TOML è più rigoroso sulla struttura, quindi due cose possono bloccare una conversione. Il primo livello deve essere un oggetto, perché un documento TOML è sempre una tabella alla radice; un array o uno scalare nudo non ha dove andare. E TOML non ha null, quindi un valore null di un oggetto viene scartato (con un avviso che elenca quali chiavi), mentre un null dentro un array non ha alcuna rappresentazione TOML valida. Il convertitore da JSON a TOML mette in evidenza entrambi i casi in modo esplicito invece di produrre output rotto.

JSON e YAML, in entrambe le direzioni. Qui la cosa da tenere d’occhio è il problema Norvegia: un NO o uno 0755 senza apici può cambiare tipo mentre attraversa il confine. Il convertitore da JSON a YAML e il convertitore da YAML a JSON gestiscono gli apici così una stringa resta una stringa.

Dopo qualsiasi conversione, vale la pena validare il risultato. Far passare l’output nel Formattatore JSON conferma che il JSON sia ben formato e con un rientro coerente prima di committarlo o inviarlo a valle. E poiché i file di configurazione contengono segreti (token di registry, credenziali di database, chiavi di deploy), tutti questi strumenti girano interamente nel tuo browser: nulla viene caricato, così un Cargo.toml con un token di registry privato o un file di values con credenziali non lascia mai la tua macchina.

FAQ

TOML è meglio di YAML?

Nessuno dei due è migliore in assoluto; la scelta tra TOML e YAML dipende dalla forma. TOML è più difficile da sbagliare grazie ai tipi espliciti e all’assenza di trappole di rientro, quindi vince per la config di tooling per lo più piatta. YAML esprime l’annidamento profondo in modo più compatto, quindi vince per grandi infrastrutture stratificate come Kubernetes.

Dovrei usare JSON o YAML per i file di configurazione?

Per una config modificata da una persona, preferisci YAML: permette i commenti e si legge in modo pulito, cosa che JSON non fa. Per una config che i programmi generano e consumano, preferisci JSON: è rigoroso, veloce e universale. La linea di demarcazione è chi fa la modifica, persona o macchina.

Perché JSON non permette i commenti?

Il creatore di JSON, Douglas Crockford, ha rimosso i commenti di proposito. Temeva che le persone vi incorporassero direttive di parsing rompendo l’interoperabilità tra parser. Se ti servono i commenti in un file a forma di JSON, usa JSON5 o JSONC, che li reintroducono senza cambiare la struttura di base.

Cos’è il problema Norvegia in YAML?

È YAML 1.1 che tratta certe parole senza apici come booleani, così country: NO diventa false invece della stringa "NO". YES, ON e OFF si comportano allo stesso modo. Mettere il valore tra apici lo evita; per la storia completa vedi la guida dedicata linkata sopra.

TOML supporta i commenti?

Sì. TOML usa # per i commenti, sia su una riga a sé sia dopo un valore, esattamente come YAML. Nota che i commenti si perdono quando converti TOML in JSON, dato che JSON non ha una sintassi per i commenti in cui contenerli.

TOML può rappresentare tutto ciò che JSON rappresenta?

Quasi. Il divario tra JSON e TOML è piccolo ma reale: TOML non ha un tipo null, quindi i null di JSON vengono scartati o rifiutati in fase di conversione, e un documento TOML deve essere una tabella al primo livello, quindi un array o uno scalare JSON nudo non può essere convertito senza prima essere incapsulato sotto una chiave.

YAML è un superset di JSON?

Dalla versione YAML 1.2, sì: qualsiasi documento JSON valido è anche YAML valido, quindi un parser YAML può leggere JSON direttamente. È un fatto utile, ma non farci affidamento come confine di sicurezza, perché i parser YAML aggiungono funzionalità (come gli anchor) che JSON non ha.

Quale formato di configurazione è più veloce da analizzare?

JSON è generalmente il più veloce, con i parser più maturi e ottimizzati in ogni linguaggio. YAML è il più lento e complesso da analizzare per via della sua ampia specifica e della tipizzazione implicita. TOML sta nel mezzo, più vicino a JSON per velocità che a YAML.