YAML to TOML Converter
Convert YAML to TOML free in your browser, no sign-up or upload required. Automatically turns nested YAML into TOML tables and array-of-tables, with typed dates and clear null handling.
अपडेट किया गया
अक्सर पूछे जाने वाले प्रश्न
Are comments preserved when converting YAML to TOML?
No. Both formats support `#` line comments, but comments are trivia attached to the source text, not to the data model. The converter parses YAML into mappings, sequences, and scalars, then re-serializes that structure as TOML — any `#` comments in the original YAML are discarded in the process and won't appear in the TOML output.
How are YAML's inline (flow-style) mappings and lists converted?
YAML lets you write a mapping or sequence inline, like `{host: localhost, port: 5432}` or `[web, production]`, as an alternative to multi-line block style. TOML has a direct equivalent — inline tables (`{ host = "localhost", port = 5432 }`) and inline arrays (`["web", "production"]`). Since flow and block YAML parse to the identical data structure, the converter treats them the same way regardless of which style the source file used.
Does the converter preserve the order of keys from the source YAML?
Yes. TOML's spec doesn't require any particular key order for two documents to be considered equivalent, but the converter still emits keys in the order they appeared in the YAML source, since standard parsers (PyYAML, js-yaml, ruamel.yaml) retain document order by default — this keeps diffs against the original file predictable.
What happens if a YAML key isn't a valid TOML bare key?
TOML restricts unquoted ("bare") keys to ASCII letters, digits, underscores, and dashes. A YAML key like `first name` (a space) or `api.version` (a literal dot, which TOML would otherwise read as nested-table notation) doesn't fit that grammar, so the converter wraps it in quotes instead — producing `"first name" = "Jane"` — which TOML's spec defines as an equally valid alternative to a bare key.
क्या YAML के एंकर और एलियास को TOML में बदलने पर कुछ खो जाता है?
हाँ, लेकिन जो चीज़ खोती है वह आपसी संबंध है, डेटा नहीं। YAML के एंकर (`&name`) किसी ब्लॉक को दोबारा इस्तेमाल के लिए चिह्नित करते हैं, और एलियास (`*name`) उस सामग्री को उसी डॉक्यूमेंट में कहीं और कॉपी कर देते हैं — यह आमतौर पर साझा डिफॉल्ट्स के लिए इस्तेमाल होता है, जैसे किसी `&defaults` एंकर को `<<: *defaults` के ज़रिए कई एनवायरनमेंट कॉन्फ़िगरेशन में मर्ज करना। TOML में एंकर, एलियास या मर्ज-की जैसी कोई अवधारणा नहीं है, इसलिए TOML जेनरेट करने से पहले कन्वर्टर हर एलियास को उसकी पूरी, वास्तविक वैल्यू में हल कर देता है। नतीजा डेटा के लिहाज़ से बराबर होता है — हर फील्ड की वैल्यू वही रहती है — लेकिन "एक ही जगह से सच्चाई मिलने" वाली सुविधा खत्म हो जाती है: पहले अगर एंकर ब्लॉक बदलता था तो आप उसे YAML में एक ही जगह अपडेट करते थे, जबकि TOML में अब आपके पास कई अलग-अलग टेबल्स हैं जिन्हें हाथ से एडिट करना पड़ता है। कई डॉक्यूमेंट वाली YAML फ़ाइलें (कई `---`-सेपरेटेड डॉक्यूमेंट्स) भी एक अलग वजह से इसी दीवार से टकराती हैं: TOML फ़ाइल ठीक एक ही डॉक्यूमेंट होती है, इसलिए कन्वर्ज़न के बाद सिर्फ एक YAML डॉक्यूमेंट ही बचता है।
मुझे YAML कॉन्फ़िगरेशन को TOML में क्यों बदलना चाहिए, जबकि YAML ही रखा जा सकता है?
आमतौर पर इसलिए क्योंकि किसी खास टूलचेन को TOML ही चाहिए होता है और वह YAML को उसके विकल्प के तौर पर स्वीकार नहीं करता। Rust का Cargo `Cargo.toml` पढ़ता है; Python के Poetry, Hatch और PDM `pyproject.toml` पढ़ते हैं; Hugo कंटेंट फ़ाइलों में TOML फ्रंट मैटर स्वीकार करता है; और Rust की `toml` क्रेट या Go की BurntSushi/toml लाइब्रेरी पर बने किसी भी टूल को खासतौर पर TOML ही चाहिए होता है। जो टीमें पहले से इंफ्रास्ट्रक्चर या CI कॉन्फ़िगरेशन YAML में मेंटेन कर रही हैं — Ansible प्लेबुक्स, GitHub Actions वर्कफ़्लोज़, Kubernetes मैनिफेस्ट — उन्हें कभी-कभी उन फ़ाइलों से खास वैल्यूज़ (सर्विस नाम, पोर्ट, वर्ज़न पिन) निकालकर किसी TOML-आधारित प्रोजेक्ट या पैकेज मैनिफेस्ट में डालनी होती हैं, बिना हर फील्ड को हाथ से दोबारा टाइप किए और कोटेशन व टाइप को दोबारा जाँचे। सोर्स YAML फ्रैगमेंट को कन्वर्टर से गुज़ारना, नेस्टेड की को हाथ से ब्रैकेट वाली TOML टेबल में ट्रांसक्राइब करने से कहीं तेज़ और कम गलती-प्रवण है, खासकर कई स्तर की नेस्टिंग वाले बड़े कॉन्फ़िग ब्लॉक्स के लिए।
YAML और TOML कितने पुराने हैं, और इनके स्पेक्स को कैसे मेंटेन किया जाता है?
YAML एक दशक से भी ज़्यादा पुराना फॉर्मेट है: इसका वर्ज़न 1.0, 2004 में Clark Evans, Ingy döt Net और Oren Ben-Kiki ने पब्लिश किया था, और मौजूदा रिविज़न, YAML 1.2.2, 2021 में फाइनल हुआ, जो YAML को JSON के एक strict सुपरसेट के तौर पर परिभाषित करता है। TOML नया है और इसे 2013 में GitHub के सह-संस्थापक Tom Preston-Werner ने खासतौर पर एक न्यूनतम, स्पष्ट कॉन्फ़िगरेशन फॉर्मेट के तौर पर बनाया — YAML की जटिलता और INI के मानकीकरण की कमी दोनों का विकल्प। Rust का पैकेज मैनेजर Cargo इसका शुरुआती और प्रभावशाली अपनाने वाला था, जिसने TOML को Rust और बाद में Python पैकेजिंग मैनिफेस्ट के लिए डिफॉल्ट पसंद बनाने में मदद की। TOML को उसका पहला स्टेबल रिलीज़, v1.0.0, 2021 में मिला — YAML के नवीनतम रिविज़न वाले साल में ही — इसलिए आज आप जिन दोनों स्पेक्स के बीच कन्वर्ज़न कर रहे हैं, वे अपने सबसे मौजूदा, स्टेबल वर्ज़न में हैं।
क्या TOML बस YAML का एक सरल संस्करण है?
नहीं — कहीं-कहीं दिखने में मिलते-जुलते होने के बावजूद, इन्हें अलग-अलग डिज़ाइन किया गया था, और TOML की सिंटैक्स YAML की इंडेंटेशन-आधारित ब्लॉक स्टाइल से ज़्यादा INI फ़ाइलों (`[section]` हेडर, `key = value` लाइनें) से मिलती-जुलती है। TOML में जानबूझकर फ्लो बनाम ब्लॉक स्टाइल जैसी कोई अवधारणा नहीं है, न ही एंकर या एलियास, न कस्टम टाइप टैग, और न मल्टी-डॉक्यूमेंट फ़ाइलें — इसका मकसद यह है कि किसी भी दिए गए स्ट्रक्चर को लिखने का एक ही तरीका हो, और यही वजह है कि यह कन्वर्टर YAML की नेस्टेड मैपिंग्स को TOML टेबल्स में तय तरीके से मैप कर पाता है। यह रिश्ता सिर्फ एक ही दिशा में साफ-साफ चलता है: किसी भी वैध TOML डॉक्यूमेंट को बिना किसी नुकसान के YAML में दोबारा लिखा जा सकता है, लेकिन उल्टा सच नहीं है, क्योंकि YAML का फीचर सेट TOML के ग्रामर से जो कुछ भी व्यक्त किया जा सकता है, उसका एक strict सुपरसेट है।
कन्वर्ज़न डेट्स और टाइमस्टैम्प को कैसे संभालता है?
साफ-सुथरे तरीके से, क्योंकि दोनों फॉर्मेट इन्हें स्ट्रिंग नहीं बल्कि नेटिव टाइप के तौर पर मानते हैं। YAML का कोर स्कीमा `2024-01-15` या `2024-01-15T10:30:00Z` जैसे टाइमस्टैम्प स्केलर्स को पहचानता है और उन्हें टेक्स्ट की बजाय डेट के तौर पर टैग करता है; TOML v1.0.0 चार अलग-अलग डेट/टाइम टाइप परिभाषित करता है — offset date-time, local date-time, local date, और local time — जिनमें से हर एक का अपना ग्रामर है। कन्वर्टर किसी YAML टाइमस्टैम्प को TOML के इन चार टाइप में से जो भी उसमें मौजूद कॉम्पोनेंट्स से मेल खाता है, उसमें मैप कर देता है: सिर्फ `2024-01-15` एक TOML local date बन जाता है, जबकि `Z` या `+00:00` ऑफ़सेट वाला टाइमस्टैम्प offset date-time बन जाता है। दोनों फॉर्मेट इन वैल्यूज़ के लिए RFC 3339 फॉर्मेटिंग फॉलो करते हैं, इसलिए डेट स्ट्रिंग को दोबारा फॉर्मेट करने की ज़रूरत नहीं पड़ती — TOML की तरफ सिर्फ टाइप क्लासिफिकेशन बदलता है।
Embed This Tool
Add a free, live version of this widget to your own website or blog post — it runs entirely in your visitors' browsers, with a credit link back to The Toolbox.
<iframe src="https://getthetoolbox.com/embed/yaml-to-toml" title="YAML to TOML Converter — The Toolbox" width="100%" height="420" style="max-width:480px;border:1px solid #e2e8f0;border-radius:12px" loading="lazy"></iframe>
<p style="font-size:12px;margin:4px 0 0"><a href="https://getthetoolbox.com/converter-tools/yaml-to-toml?utm_source=embed&utm_medium=widget" target="_blank" rel="noopener">Free YAML to TOML Converter</a> by The Toolbox</p>संबंधित टूल
मुफ़्त ऑनलाइन लंबाई कनवर्टर
मीटर, फ़ुट, इंच, मील और अन्य लंबाई इकाइयों के बीच रूपांतरण करें। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में, बिना साइन-अप के।
मुफ़्त ऑनलाइन वज़न कनवर्टर
kg, पाउंड, औंस, ग्राम और अन्य वज़न इकाइयों के बीच रूपांतरण करें। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में, बिना साइन-अप के।
मुफ़्त तापमान कनवर्टर
Celsius, Fahrenheit और Kelvin पैमानों के बीच तापमान को तुरंत बदलें। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में, बिना साइन-अप के।
मुफ़्त ऑनलाइन क्षेत्रफल कनवर्टर
वर्ग मीटर, एकड़, हेक्टेयर और अन्य के बीच रूपांतरण करें। मुफ़्त, तेज़ और पूरी तरह आपके ब्राउज़र में, बिना साइन-अप के।
YAML to TOML कन्वर्टर के बारे में
YAML और TOML दोनों ही इंसानों के पढ़ने लायक, टाइप्ड कॉन्फ़िगरेशन फॉर्मेट बनने की कोशिश करते हैं, लेकिन "नेस्टिंग को कैसे दिखाया जाए" इस समस्या को दोनों लगभग विपरीत तरीकों से हल करते हैं। YAML इंडेंटेशन और डैश-प्रीफिक्स्ड सीक्वेंस (ब्लॉक स्टाइल) के ज़रिए स्ट्रक्चर को इशारे में दिखाता है, और उसी डेटा के लिए एक वैकल्पिक इनलाइन फ्लो स्टाइल भी देता है। दूसरी तरफ TOML स्ट्रक्चर को ब्रैकेट में लिखे सेक्शन हेडर से साफ-साफ दिखाता है और उसमें इंडेंटेशन-आधारित नेस्टिंग होती ही नहीं। यह कन्वर्टर आपके YAML को उसके अंदरूनी डेटा मॉडल — मैपिंग्स, सीक्वेंसेस और टाइप्ड स्केलर्स — में पार्स करता है और फिर उसी डेटा को TOML की टेबल सिंटैक्स में दोबारा लिखता है।
एक नेस्टेड YAML मैपिंग [table] हेडर बन जाती है। मान लीजिए आपके पास यह है:
database:
host: localhost
port: 5432
ssl: true
तो कन्वर्टर यह बनाता है:
[database]
host = "localhost"
port = 5432
ssl = true
किसी भी नेस्टेड ऑब्जेक्ट के लिए TOML को यह साफ [table] हेडर चाहिए ही होता है — सिर्फ ब्लॉक को आगे इंडेंट कर देने जैसा कोई विकल्प उसमें नहीं है। कन्वर्टर आपके YAML की नेस्टिंग डेप्थ से खुद-ब-खुद ये हेडर बना लेता है, और गहरे स्ट्रक्चर के लिए डॉट-सेपरेटेड पाथ भी बना देता है (जैसे database.replica मैपिंग [database.replica] बन जाती है)।
ऑब्जेक्ट्स के एरे भी इसी साफ-हेडर वाले लॉजिक को फॉलो करते हैं, बस डबल ब्रैकेट के साथ। मैपिंग्स का एक YAML सीक्वेंस:
servers:
- name: web1
ip: 10.0.0.1
- name: web2
ip: 10.0.0.2
TOML की array-of-tables सिंटैक्स बन जाता है:
[[servers]]
name = "web1"
ip = "10.0.0.1"
[[servers]]
name = "web2"
ip = "10.0.0.2"
हर [[servers]] हेडर servers एरे में एक और एलिमेंट जोड़ देता है — ऑब्जेक्ट्स की लिस्ट दिखाने का TOML में यही एकमात्र तरीका है, जबकि YAML का - सीक्वेंस मार्कर बिना किसी खास केस-हैंडलिंग के हर तरह के एलिमेंट्स — चाहे वे ऑब्जेक्ट हों या स्केलर — की लिस्ट संभाल लेता है।
टाइप्ड स्केलर्स ज़्यादातर एक-से-एक ट्रांसलेट होते हैं। दोनों स्पेसिफिकेशन स्ट्रिंग्स, इंटीजर्स, फ्लोट्स, बूलियन्स और डेट्स/डेटटाइम्स को नेटिव, नॉन-स्ट्रिंग टाइप के तौर पर परिभाषित करते हैं, इसलिए YAML में port: 5432 और enabled: true बिना किसी अतिरिक्त कोटेशन के TOML में port = 5432 और enabled = true बन जाते हैं — कन्वर्टर को टाइप का अंदाज़ा लगाने की ज़रूरत ही नहीं पड़ती, क्योंकि TOML सीरियलाइज़र तक पहुँचने से पहले ही YAML पार्सर उन्हें YAML 1.2 कोर स्कीमा टैग्स के हिसाब से रिज़ॉल्व कर चुका होता है।
असली अंतर वहाँ है जो YAML तो डिफाइन करता है लेकिन TOML के स्पेक में जिसके लिए कोई जगह ही नहीं है। YAML में एक स्पष्ट null होता है (जिसे ~ या null लिखा जाता है); TOML के टाइप सिस्टम में null नाम की कोई चीज़ है ही नहीं, इसलिए यह कन्वर्टर YAML के null वैल्यू को एक खाली स्ट्रिंग ("") में मैप करता है — शेप बनाए रखने के लिहाज़ से यही सबसे नज़दीकी विकल्प है, हालाँकि इसका मतलब यह है कि जो फील्ड पहले साफ तौर पर "कोई वैल्यू नहीं" थी, कन्वर्ज़न के बाद वह असल में खाली स्ट्रिंग वाली फील्ड से अलग पहचानी नहीं जा सकती। YAML में एंकर (&name) और एलियास (*name) भी होते हैं जो एक नोड को दूसरे नोड की सामग्री रेफरेंस के ज़रिए दोबारा इस्तेमाल करने देते हैं, साथ ही एक ही फ़ाइल के अंदर कई ----सेपरेटेड डॉक्यूमेंट्स भी हो सकते हैं; TOML के पास इनमें से किसी के लिए भी कोई तंत्र नहीं है, क्योंकि TOML फ़ाइल को एक फ्लैट डॉक्यूमेंट के तौर पर परिभाषित किया गया है जिसमें कोई इंटरनल क्रॉस-रेफरेंस नहीं होता।
डेवलपर्स आमतौर पर पसंद की वजह से नहीं, बल्कि अलग-अलग फॉर्मेट अपनाने वाले इकोसिस्टम्स के बीच कॉन्फ़िगरेशन ले जाने के लिए इस कन्वर्ज़न का सहारा लेते हैं — जैसे किसी YAML-आधारित CI पाइपलाइन या इंफ्रास्ट्रक्चर मैनिफेस्ट से वैल्यूज़ निकालकर किसी Rust Cargo.toml, Poetry या Hatch से इस्तेमाल होने वाली Python pyproject.toml, या किसी स्टैटिक-साइट जेनरेटर के TOML फ्रंट मैटर में डालना — ये सभी खासतौर पर TOML ही पार्स करते हैं और YAML को इसके विकल्प के तौर पर स्वीकार नहीं करते।