TOML vs JSON vs YAML: welk configuratieformaat kiezen?

Hier is de korte versie van TOML vs JSON vs YAML: JSON is de standaard voor uitwisseling tussen machines die elke taal kan inlezen, YAML is het mensvriendelijke formaat dat Kubernetes en CI-pijplijnen laat draaien, en TOML is het expliciete, getypeerde formaat gebouwd voor tool- en applicatieconfiguratie zoals Cargo.toml en pyproject.toml. Geen enkel formaat wint overal. Het juiste configuratieformaat hangt van drie dingen af: wie het bewerkt, of je commentaar nodig hebt, en hoe strikt de typen moeten zijn.

Een snelle vuistregel. Schrijft een machine het en leest een machine het, grijp dan naar JSON. Bewerkt een mens elke dag met de hand diep geneste infrastructuur, dan verdient YAML zijn complexiteit. Wil je duidelijke, getypeerde configuratie die moeilijk te verknoeien is, dan is TOML de veiligste keuze. Deze formaten zijn geen concurrenten. Ze bezetten verschillende banen: JSON voor machines, YAML voor DevOps, TOML voor toolconfiguratie. De rest van deze gids onderbouwt dat met voorbeelden naast elkaar, de verschillen die echt bugs veroorzaken, en een beslismatrix voor je volgende project.

Het antwoord in 30 seconden

Heb je maar een halve minuut, dan is deze tabel de vergelijking van configuratieformaten waarvoor je kwam.

	JSON	YAML	TOML
Commentaar	Nee	Ja (#)	Ja (#)
Datatypen	Expliciet, minimaal	Impliciet (afgeleid uit vorm)	Expliciet, rijk
Native datums	Nee	Versieafhankelijk	Ja (vier typen)
Nestingstijl	Accolades {}	Inspringing	[section]-headers
Inspringingsgevoelig	Nee	Ja (tabs verboden)	Nee
Multiregelstrings	Nee (alleen \n)	Ja (| en >)	Ja (""")
Afsluitende komma’s	Verboden	N.v.t.	Toegestaan in arrays
Superset van JSON	—	Ja (1.2)	Nee
Beste voor	API’s, gegevensuitwisseling	K8s, CI, Ansible	Rust/Python-toolconfiguratie

Dat levert drie oordelen van één regel op:

• Kies JSON wanneer het bestand door programma’s wordt geproduceerd en geconsumeerd: API-payloads, package.json, tsconfig.json, alles wat een systeemgrens overschrijdt.
• Kies YAML wanneer mensen diep geneste configuratie met de hand bewerken en het ecosysteem dat al verwacht: Kubernetes-manifesten, GitHub Actions, Docker Compose, Ansible-playbooks.
• Kies TOML wanneer je een duidelijke, getypeerde configuratie voor een tool of applicatie wilt, grotendeels plat met een paar secties, bewerkt door bijdragers van uiteenlopend niveau: Cargo.toml, pyproject.toml, Hugo, Netlify.

Wil je begrijpen waarom die oordelen kloppen, lees dan door: in de redenen schuilen de echte bugs.

Dezelfde configuratie, op drie manieren

Niets legt het verschil sneller uit dan één configuratie die drie keer is geschreven. Hier is een kleine serviceconfiguratie: een naam en versie, een paar top-level vlaggen, een lijst met features en een genest databaseblok.

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

Alle drie beschrijven exact dezelfde gegevens. Kijk waar je oog over struikelt. JSON draagt de meeste interpunctie: elke sleutel staat tussen dubbele aanhalingstekens, elk niveau voegt accolades toe, en één verdwaalde afsluitende komma is een syntaxfout. YAML streept bijna dat alles weg, zodat de structuur alleen uit de inspringing volgt, wat prettig leest tot er een tab binnensluipt. TOML zit ertussenin: aanhalingstekens alleen op strings, key = value-paren, en een [database]-header die het geneste blok benoemt zoals een oud INI-bestand dat zou doen. Merk op dat het veld released in alle drie een string tussen aanhalingstekens is, zodat de gegevens hier identiek blijven. Dat is opzettelijk: datums zijn precies waar deze formaten uiteenlopen, en dat komt hierna aan bod.

JSON — de standaard voor uitwisseling tussen machines

JSON is het formaat waar je zonder nadenken naar grijpt, en meestal klopt dat instinct. Elke gangbare taal levert een parser mee, elke HTTP-API spreekt het, en de grammatica is klein genoeg om in je hoofd te houden. Het is strikt en ondubbelzinnig: een string is een string, 5432 is een getal, true is een boolean, en er is precies één manier om elk te schrijven. Die striktheid maakt JSON veilig om te versturen tussen systemen die elkaar nooit hebben ontmoet. Wanneer een Node-service JSON naar een Go-service post, zijn beide het byte voor byte eens over de betekenis.

Diezelfde starheid is waarom JSON zijn eigen terrein domineert. package.json, tsconfig.json en composer.json zijn JSON omdat tools ze constant genereren en herschrijven, en machinaal geschreven configuratie wil een machinaal strikt formaat. Voor API-payloads en berichtenwachtrijen is er simpelweg geen reden om iets anders te kiezen.

De zwakke punten van JSON komen allemaal boven op het moment dat een mens het met de hand moet bewerken. Er is geen commentaar. Er zijn geen afsluitende komma’s, dus een lijst herordenen betekent komma’s herstellen. Er zijn geen multiregelstrings, alleen \n-escapes. Elke sleutel heeft dubbele aanhalingstekens nodig. En er is geen datumtype, dus 2026-07-02 moet als string tussen aanhalingstekens bestaan en volgens afspraak worden ingelezen. Voor een configuratiebestand dat een mens onderhoudt, tellen die gaten op tot wrijving.

Het probleem “JSON heeft geen commentaar”

De meestgevraagde JSON-feature is degene die Douglas Crockford bewust wegliet: commentaar. Zijn redenering was dat commentaar mensen uitnodigde om parseerdirectieven in configuratiebestanden te smokkelen, waardoor de interoperabiliteit brak. Wat je ook van die keuze vindt, je kunt een gewone JSON-configuratie niet annoteren, wat pijnlijk is voor alles wat mensen onderhouden. De praktische oplossing is een superset. JSON5 voegt commentaar, afsluitende komma’s, sleutels zonder aanhalingstekens en enkele aanhalingstekens toe; JSONC (JSON with Comments) is de lichtere variant die VS Code gebruikt voor zijn instellingen. Beide behouden de vorm van JSON terwijl ze het bewerkbaar maken. Heb je commentaar nodig maar wil je in de JSON-familie blijven, lees dan onze gids voor JSON5- en JSONC-opmaak over wanneer je welke gebruikt en hoe je je tooling tevredenhoudt.

YAML — de mensvriendelijke DevOps-standaard

YAML optimaliseert voor de mens achter het toetsenbord. Het ondersteunt commentaar, de op inspringing gebaseerde opmaak houdt diep geneste structuren overzichtelijk, en anchors laten je een blok één keer definiëren en met een alias hergebruiken in plaats van kopiëren en plakken:

defaults: &defaults
  timeout: 30
  retries: 3

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

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

De &defaults-anchor benoemt een blok, en <<: *defaults voegt het in beide omgevingen samen, zodat een wijziging aan de gedeelde timeout op één plek gebeurt. Noch JSON noch TOML heeft daar iets van weg. Die leesbaarheid is waarom YAML de lingua franca van operations werd: Kubernetes-manifesten, GitHub Actions-workflows, Docker Compose-bestanden en Ansible-playbooks zijn allemaal YAML. Wanneer je configuratie vijf niveaus diep is en een mens er dagelijks aan sleutelt, is de lage interpunctie van YAML een echte verademing.

De prijs is complexiteit en verrassing. De YAML 1.2-specificatie is groot, en volledige naleving is zeldzaam, dus verschillende parsers zijn het aan de randen oneens. Inspringing is betekenisvol, tabs zijn ronduit verboden, en een verkeerd uitgelijnde spatie kan de betekenis veranderen of niet inlezen. De scherpste rand is impliciete typering: YAML raadt het type van een scalar zonder aanhalingstekens uit zijn vorm, en het raadt vaak genoeg verkeerd om een bijnaam te hebben.

Het Noorwegen-probleem in één alinea

Schrijf country: NO in YAML en veel parsers geven je de boolean false, niet de string "NO", omdat YAML 1.1, dat de meeste Kubernetes-tooling nog volgt, NO, YES, ON, OFF, Y en N als booleans behandelt. De landcode van Noorwegen wordt stilletjes false, zonder enige foutmelding. Dezelfde impliciete typering maakt van 0755 een octaal getal en van 1.20 een 1.2. De oplossing is saai maar betrouwbaar: zet strings die met iets anders verward kunnen worden tussen aanhalingstekens. Deze valkuil is beroemd genoeg om een eigen verdieping te verdienen, inclusief echte storingen en de geschiedenis van YAML 1.1 versus 1.2, in onze gids over het Noorwegen-probleem in YAML. Voor dit artikel is de kernboodschap eenvoudig: het gemak van YAML en het gevaar ervan komen uit dezelfde feature.

YAML wint wanneer mensen elke dag diep geneste configuratie bewerken en het omringende ecosysteem het al vereist. Schrijf je een Helm-chart, dan schrijf je YAML, en dat is prima.

TOML — expliciete configuratie gebouwd voor tooling

TOML (Tom’s Obvious, Minimal Language, gemaakt door Tom Preston-Werner) werd ontworpen om het configuratieformaat te zijn dat YAML-gebruikers wilden dat ze hadden: leesbaar, maar zonder het raden. De bepalende eigenschap is explicietheid. Typen zijn ondubbelzinnig, dus port = 5432 is altijd een integer en name = "acme" is altijd een string, zonder op vorm gebaseerde inferentie die je een beentje licht. TOML-syntaxis leent de [section]-header van INI-bestanden, waardoor het bovenste niveau van een configuratie scanbaar wordt, en het is niet inspringingsgevoelig, dus witruimte verandert de betekenis nooit. De TOML 1.0.0-specificatie is klein en stabiel, wat een pluspunt is: er is minder om verkeerd te onthouden.

De belangrijkste troef van TOML is native datum- en tijdtypen, die noch JSON noch gewone YAML netjes afhandelen. Er zijn er vier: offset date-time met een tijdzone (1979-05-27T07:32:00Z), local date-time zonder, local date (1979-05-27, alleen een kalenderdag) en local time (07:32:00). Dat betekent dat een deploymentdatum een echte datum blijft in plaats van een string die je opnieuw moet inlezen.

Drie stukjes TOML-syntaxis doen het meeste werk. Een [section]-header opent een table; een header met puntnotatie zoals [tool.ruff] nest één table binnen een andere zonder extra inspringing; en een inline table { version = "1.0", features = ["derive"] } pakt een klein object op één regel. Herhaalde secties gebruiken een dubbele header, de array of tables:

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

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

Dat blok wordt een JSON-array van twee objecten onder de sleutel servers. Het leest goed voor een platte lijst, wat precies is wat de meeste toolconfiguratie nodig heeft.

De zwakke punten zijn echt maar beperkt. TOML heeft geen null-type, dus een afwezige waarde is simpelweg een weggelaten sleutel. Diepe nesting wordt breedsprakig, omdat elk niveau van een herhaalde geneste structuur de volledige [[path]]-header herhaalt, wat rumoeriger groeit dan het YAML-equivalent. En TOML is jonger en minder universeel dan JSON of YAML, dus niet elke tool spreekt het. TOML komt het best tot zijn recht voor configuratie die grotendeels plat is met een handvol gelabelde secties, wat de overweldigende meerderheid van toolconfiguratie beschrijft.

Waarom TOML voor Rust en Python?

De opkomst van TOML volgt twee ecosystemen die het als standaard omarmden. Rust’s package manager, Cargo, gebruikt Cargo.toml voor elke crate, dus elke Rust-ontwikkelaar leest en schrijft TOML vanaf dag één. Python volgde: PEP 518 introduceerde pyproject.toml om buildvereisten te declareren, en PEP 621 standaardiseerde projectmetadata (naam, versie, dependencies en [tool.*]-secties) in datzelfde bestand, ter vervanging van een verzameling setup.py, setup.cfg en per-tool configuraties. Buiten die twee kiezen Hugo, Netlify, Poetry en Foundry allemaal standaard TOML. De rode draad is toolconfiguratie die bijdragers met de hand bewerken en die profiteert van duidelijk zijn in plaats van slim.

Kop aan kop — de verschillen die echt bijten

Featuretabellen zijn netjes. Bugs zijn dat niet. Dit zijn de specifieke verschillen die echte problemen veroorzaken, elk met een klein voorbeeld dat je door elke parser kunt halen.

Commentaar

JSON heeft helemaal geen commentaarsyntaxis. TOML en YAML gebruiken beide # tot einde regel.

# TOML: a leading comment
port = 5432  # and a trailing one

# YAML: identical comment style
port: 5432   # trailing comment

Op het moment dat je een // of # in strikte JSON plakt, mislukt het inlezen. Dit is niet cosmetisch. Een configuratie die een mens zonder commentaar onderhoudt, verzamelt stamkennis die alleen in iemands hoofd leeft.

Datatypen en datums

JSON’s typen zijn expliciet maar schaars, zonder datumtype. TOML’s typen zijn expliciet en rijk. YAML’s zijn impliciet en, zoals hierboven behandeld, af en toe verkeerd. Datums zijn de duidelijkste scheidslijn. TOML drukt alle vier de soorten native uit:

odt = 1979-05-27T07:32:00Z   # offset date-time (has timezone)
ldt = 1979-05-27T07:32:00    # local date-time (no timezone)
ld  = 1979-05-27             # local date (a calendar day)
lt  = 07:32:00               # local time

Zet die TOML om naar JSON en elke waarde wordt een string die zijn betekenis behoudt: een local date blijft "1979-05-27" in plaats van te worden opgeblazen tot een nep-middernachttimestamp. Onze TOML-naar-JSON-converter behoudt die datumsoort exact, wat veel naïeve converters verkeerd doen. YAML behandelt 1979-05-27 intussen wel of niet als datum, afhankelijk van de parser en schemaversie, wat precies de dubbelzinnigheid is die je niet wilt in productieconfiguratie.

Nestingdiepte

Hoe dieper je configuratie nest, hoe meer de formaten uiteenlopen. Neem een kleine boom in Docker Compose-stijl:

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

YAML drukt diepte uit met pure inspringing, en het blijft compact. Dezelfde structuur in TOML dwingt je om het volledige pad in elke header uit te schrijven, en om scalaire waarden vóór de child tables te plaatsen:

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

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

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

JSON draagt de boom in geneste accolades, wat ondubbelzinnig maar interpunctiezwaar is. Voor ondiepe configuratie voelen de drie vergelijkbaar; voorbij drie of vier niveaus is YAML zichtbaar slanker en TOML zichtbaar herhalender. Dat ene verschil verklaart waarom Kubernetes voor YAML koos en Cargo voor TOML.

Inspringingsgevoeligheid

Alleen YAML geeft om witruimte. In JSON en TOML kun je inspringen zoals je wilt, of helemaal niet, en de betekenis is identiek. In YAML is inspringing de structuur, en tabs zijn illegaal, dus een editor die een tab invoegt of een blok dat op de verkeerde diepte is geplakt, verandert het document stilletjes of weigert te laden. Een lijstitem dat één spatie te ver is ingesprongen, kan zich zonder enige foutmelding aan de verkeerde ouder-sleutel hechten, wat een tergende bug is om met het oog te vinden omdat het bestand er nog steeds redelijk uitziet. Gebruiken je bijdragers gemengde editors en instellingen, dan is dat een staande belasting die YAML heft en de andere twee niet, en het is een sterke reden om een linter in CI te draaien op elke grote YAML-configuratie.

Multiregelstrings

JSON kan geen letterlijke newline binnen een string bevatten; je escapet het als \n. YAML en TOML hebben beide echte multiregelstrings.

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

note: |
  line one
  line two

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

YAML’s | behoudt newlines (een >-blok vouwt ze in plaats daarvan tot spaties), en TOML’s """ gedraagt zich vergelijkbaar, waarbij het de newline direct na de openingsquotes wegsnijdt. Voor ingebedde scripts, SQL of helptekst kan dit alleen al het formaat bepalen.

Afsluitende komma’s en striktheid

JSON is de striktste van de drie. Een afsluitende komma na het laatste array-element is een syntaxfout:

# valid TOML — the trailing comma is fine
ports = [
  8001,
  8002,
]

Dezelfde afsluitende komma na 8002 in JSON kan niet worden ingelezen, en daarom betekent een regel toevoegen aan een JSON-array zo vaak ook de komma op de regel erboven herstellen. TOML staat de afsluitende komma toe, en YAML’s lijstsyntaxis met een streepje per regel omzeilt de vraag helemaal. Striktheid is een deugd voor uitwisseling tussen machines en een ergernis voor handmatig bewerken, wat dezelfde afweging is, gezien vanaf de andere kant. Dit is ook de wrijving die JSON5 en JSONC specifiek voor JSON wilden wegnemen.

Grote integers en het 2^53-plafond

Alle drie de formaten kunnen een 64-bits integer als tekst schrijven. Het probleem begint wanneer die waarde door JavaScript gaat, omdat JSON-getallen in de browser IEEE-754-doubles zijn en integers alleen exact kunnen weergeven tot 2^53 − 1 (9007199254740991). Een Snowflake-ID of een nanoseconde-timestamp is groter dan dat, dus een retourslag door een JS-gebaseerde tool rondt het af en beschadigt de waarde:

snowflake = 1420070400000000000   # exact in TOML text

{ "snowflake": "1420070400000000000" }

De betrouwbare oplossing in elk formaat is zulke waarden op te slaan als strings tussen aanhalingstekens, zodat geen enkele numerieke parser ze ooit aanraakt. Dit is geen gebrek in enig formaat; het is een beperking van de runtime die de conversie uitvoert. Onze converters waarschuwen je wanneer een integer die grens overschrijdt in plaats van het stil te beschadigen.

Hoe kies je — beslismatrix en stroomschema

Wanneer je beslist welk configuratieformaat je gebruikt, loop dan de vragen op volgorde af en stop bij het eerste stellige ja.

1. Wordt het bestand hoofdzakelijk door programma’s geschreven en gelezen, of schrijft het ecosysteem al een formaat voor? Zo ja, gebruik JSON. Een API-payload is JSON. Een bestand naast package.json is JSON. Vecht niet tegen de tooling.
2. Bewerken mensen dagelijks met de hand diep geneste configuratie, binnen een stack die het verwacht (Kubernetes, CI, Ansible)? Zo ja, gebruik YAML, en hanteer een aanhalingstekenafspraak om het Noorwegen-probleem te ontwijken.
3. Is het tool- of applicatieconfiguratie, grotendeels plat met een paar secties, bewerkt door bijdragers van uiteenlopend niveau, waar getypeerd en duidelijk het wint van beknopt? Zo ja, gebruik TOML.

Als twee antwoorden gelijk staan, breek de gelijkstand dan op deze assenkaart:

Vereiste	Beste keuze	Waarom
Commentaar in het bestand	TOML of YAML	JSON heeft er geen
Native datum-/tijdwaarden	TOML	Vier expliciete datumtypen
Zeer diepe nesting	YAML	Inspringing blijft compact
Nul witruimteverrassingen	JSON of TOML	Niet inspringingsgevoelig
Vastgezet op een ecosysteembestand	JSON	package.json, tsconfig.json
Menselijke bewerking, weinig secties	TOML	Expliciete typen, INI-achtige headers
Uitwisseling tussen machines	JSON	Universeel, strikt, snel
Typeinferentie mag nooit raden	JSON of TOML	YAML leidt impliciet af

De meeste projecten gebruiken uiteindelijk meer dan één. Een repository heeft misschien een JSON-package.json die het nooit met de hand aanraakt, een TOML-pyproject.toml voor zijn Python-tooling, YAML-workflows in .github, en een .env-bestand voor lokale secrets dat geen van deze grammatica’s volgt. Die mix is normaal: elk bestand leeft in het formaat dat bij zijn editor past. Is de .env-laag deel van je opzet, dan behandelt onze gids over het .env-bestandsformaat waar het naast JSON-configuratie past en hoe je tussen de twee omzet.

Omzetten tussen TOML, JSON en YAML

Je zet vaker tussen deze formaten om dan je zou verwachten. Een CI-job leest een handgeschreven pyproject.toml en heeft het als JSON nodig om een dependency-dashboard te voeden. Een migratie verplaatst een app van een YAML-configuratie naar TOML voor striktere typering. Een code review is makkelijker wanneer je de JSON-vorm van twee bestanden diff’t in plaats van hun witruimtegevoelige originelen. Elke richting heeft een valkuil die je moet kennen voordat je plakt.

TOML naar JSON. Het grootste risico zijn datums. Een local date zoals 1979-05-27 moet een kalenderdatum blijven, niet een middernacht-UTC-timestamp worden die een tijd en tijdzone verzint. Commentaar wordt ook weggelaten, aangezien JSON het niet kan bevatten. De TOML-naar-JSON-converter behoudt elke datumsoort getrouw zodat retourslagen zonder verlies blijven.

JSON naar TOML. TOML is strikter over structuur, dus twee dingen kunnen een conversie blokkeren. Het bovenste niveau moet een object zijn, omdat een TOML-document altijd een table aan zijn wortel is; een kale array of scalar kan nergens heen. En TOML heeft geen null, dus een null-objectwaarde wordt weggelaten (met een waarschuwing die opsomt welke sleutels), terwijl een null binnen een array helemaal geen geldige TOML-weergave heeft. De JSON-naar-TOML-converter brengt beide gevallen expliciet naar boven in plaats van kapotte uitvoer te produceren.

JSON en YAML, beide richtingen. Hier is het Noorwegen-probleem het ding om op te letten: een NO of 0755 zonder aanhalingstekens kan van type wisselen wanneer het de grens overschrijdt. De JSON-naar-YAML-converter en YAML-naar-JSON-converter regelen de aanhalingstekens zodat een string een string blijft.

Na elke conversie is het de moeite waard om het resultaat te valideren. De uitvoer door de JSON Formatter halen bevestigt dat de JSON welgevormd en consistent ingesprongen is voordat je het commit of stroomafwaarts verstuurt. En omdat configuratiebestanden secrets dragen (registry-tokens, databasegegevens, deploy-keys), draaien deze allemaal volledig in je browser: er wordt niets geüpload, dus een Cargo.toml met een privé-registry-token of een values-bestand met inloggegevens verlaat je machine nooit.

FAQ

Is TOML beter dan YAML?

Geen van beide is universeel beter; de keuze TOML vs YAML komt neer op vorm. TOML is moeilijker fout te doen dankzij expliciete typen en geen inspringingsvallen, dus het wint voor grotendeels platte toolconfiguratie. YAML drukt diepe nesting compacter uit, dus het wint voor grote gelaagde infrastructuur zoals Kubernetes.

Moet ik JSON of YAML gebruiken voor configuratiebestanden?

Voor configuratie die een mens bewerkt, geef de voorkeur aan YAML: het staat commentaar toe en leest overzichtelijk, wat JSON niet doet. Voor configuratie die programma’s genereren en consumeren, geef de voorkeur aan JSON: het is strikt, snel en universeel. De scheidslijn is wie het bewerkt, mens of machine.

Waarom staat JSON geen commentaar toe?

De maker van JSON, Douglas Crockford, verwijderde commentaar met opzet. Hij vreesde dat mensen er parseerdirectieven in zouden inbedden en de interoperabiliteit tussen parsers zouden breken. Heb je commentaar nodig in een JSON-vormig bestand, gebruik dan JSON5 of JSONC, die het weer toevoegen zonder de kernstructuur te veranderen.

Wat is het Noorwegen-probleem in YAML?

Het is dat YAML 1.1 bepaalde woorden zonder aanhalingstekens als booleans behandelt, dus country: NO wordt false in plaats van de string "NO". YES, ON en OFF gedragen zich hetzelfde. De waarde tussen aanhalingstekens zetten voorkomt het; zie de speciale gids die hierboven is gelinkt voor het hele verhaal.

Ondersteunt TOML commentaar?

Ja. TOML gebruikt # voor commentaar, zowel op een eigen regel als achter een waarde, precies zoals YAML. Merk op dat commentaar verloren gaat wanneer je TOML naar JSON omzet, aangezien JSON geen commentaarsyntaxis heeft om het te bevatten.

Kan TOML alles weergeven wat JSON kan?

Bijna. Het gat tussen JSON en TOML is klein maar echt: TOML heeft geen null-type, dus JSON-nulls worden weggelaten of geweigerd bij conversie, en een TOML-document moet een table op het bovenste niveau zijn, dus een kale JSON-array of scalar kan niet converteren zonder eerst onder een sleutel te worden gewikkeld.

Is YAML een superset van JSON?

Sinds YAML 1.2, ja: elk geldig JSON-document is ook geldige YAML, dus een YAML-parser kan JSON direct lezen. Het is een handig feit, maar leun er niet op als beveiligingsgrens, omdat YAML-parsers features toevoegen (zoals anchors) die JSON niet heeft.

Welk configuratieformaat is het snelst in te lezen?

JSON is over het algemeen het snelst, met de meest volwassen en geoptimaliseerde parsers in elke taal. YAML is het traagst en het complexst om in te lezen vanwege zijn grote specificatie en impliciete typering. TOML zit ertussenin, qua snelheid dichter bij JSON dan bij YAML.