JSON, TOML, YAML या CSON: कॉन्फ़िगरेशन format चुनना

मुख्य बात: Config फ़ाइलों को comments, dates और multi-line text चाहिए, जहीं JSON कम पड़ता है। JSON, TOML, YAML और CSON की तुलना करें, और देखें कि रूपांतरण में हमेशा क्या खोता है।

शुरुआती~9 मिनट पढ़ें2026-10-31 को प्रकाशित2026-10-31 को अपडेट किया गया

JSON, TOML, YAML और CSON configuration formats की तुलना का कवर

सार: मशीन आदान-प्रदान के लिए JSON इस्तेमाल करें, और मनुष्यों द्वारा बनाए रखी जाने वाली configuration के लिए पारिस्थितिकी तंत्र के अनुसार TOML या YAML चुनें (Kubernetes और CI के लिए YAML, सपाट structures या native dates के लिए TOML); JSONC पर तभी लौटें जब आप अनिश्चित हों कि reader dialect समर्थन करता है या नहीं।

JSON मशीनों के डेटा आदान-प्रदान के लिए है; कॉन्फ़िगरेशन फ़ाइल लोग लोगों के लिए लिखते हैं। दोनों को मिला दें और आपको ऐसा config.json मिलेगा जिसमें comment नहीं आ सकता और जिसे कोई छूने की हिम्मत नहीं करता।

1. दो अलग तरह की फ़ाइलों से शुरू करें

डेटा आदान-प्रदान और configuration का लक्ष्य एक नहीं है, भले एक ही व्यक्ति अक्सर दोनों एक ही मशीन पर लिखता है।

आयाम	डेटा आदान-प्रदान	Configuration
कौन लिखता है	कोई प्रोग्राम जो मान serialize करता है	कोई मनुष्य, या generated आउटपुट संपादित करता मनुष्य
कौन पढ़ता है	किसी और का प्रोग्राम	आपका अपना प्रोग्राम
क्या मायने रखता है	शून्य अस्पष्टता, आकार, parse गति	पठनीयता, comments, review योग्य diffs
परिवर्तन आवृत्ति	हर request	कभी-कभी, review के साथ
गलती की कीमत	500 response	ऐसी service जो शुरू नहीं होगी

JSON बाएँ स्तंभ में लगभग पूरे अंक देता है: न्यूनतम grammar, हर भाषा में parser, और comments न होना मतलब "comment मान से भटक गया" की समस्या नहीं। दाएँ स्तंभ में, उसकी सख्ती शुद्ध घर्षण है: comments नहीं, trailing commas नहीं, dates नहीं, और multi-line text को \n के साथ एक पंक्ति में समेटना पड़ता है।

2. चार प्रतिस्पर्धी और उनका syntax

JSON: RFC 8259 और ECMA-404 द्वारा परिभाषित, ठीक छह value types के साथ: object, array, string, number, boolean और null। यह de facto interchange मानक है और एकमात्र format है जिसके लिए किसी चयन निर्णय की ज़रूरत नहीं।
TOML: Tom Preston-Werner द्वारा बनाया गया, v1.0.0 जनवरी 2021 में प्रकाशित। इसका घोषित लक्ष्य न्यूनतम configuration format है जिसके semantics स्पष्ट हों और जो hash table पर अस्पष्टता-रहित map हो। Cargo.toml और pyproject.toml इसे डिफ़ॉल्ट रूप से इस्तेमाल करते हैं।
YAML: वर्तमान specification 1.2.2 है। Indentation पदानुक्रम व्यक्त करता है, और यह comments, anchors तथा multiple documents समर्थित करता है। Kubernetes manifests, GitHub Actions और Ansible सब इस पर निर्भर हैं, कीमत बड़ी specification और implementation अंतरों की है।
CSON: CoffeeScript Object Notation, जो CoffeeScript object literals से configuration लिखता है। Atom का config.cson इसे इस्तेमाल करता था। यह comments, unquoted keys और trailing commas समर्थित करता है, पर उसका पारिस्थितिकी तंत्र JavaScript दुनिया से कभी बाहर नहीं गया।

2.1 क्षमता तुलना

क्षमता	JSON	TOML	YAML	CSON
Comments	✗	✓ `#`	✓ `#`	✓ `#`
Trailing commas	✗	✓ (arrays, inline tables)	✓ (flow collections)	✓
Unquoted keys	✗	✓	✓	✓
Native date-time	✗ (केवल string)	✓ चार date-time types	✓ (1.1 में स्वतः parsed)	✗
Multi-line strings	✗ (`\n` escapes)	✓ `"""` और `'''`	✓ block और folded scalars	✓ heredoc
Integer range	Spec में unbounded, व्यवहार में double	Signed 64-bit, lossless होना चाहिए	Arbitrary precision और `.inf`/`.nan`	JavaScript का पालन
Nesting	Braces और brackets	Tables, arrays of tables, dotted keys	Indentation	Indentation
Indentation-sensitive	✗	✗	✓	✓
`null`	✓	✗	✓	✓
Tool coverage	हर भाषा	मुख्यधारा भाषाएँ	हर भाषा, अलग implementations	केवल JavaScript

दो cells ध्यान देने योग्य हैं। TOML में null नहीं है, जो JSON से रूपांतरण करते समय सबसे आम failure है। YAML का "native date" व्यवहार मतलब 1.1 parser 2026-10-31 को स्वतः date object बना देता है, इसलिए भाषाओं के बीच type खिसक जाता है।

3. Comments: JSON की एक कमज़ोरी

पहले निष्कर्ष: अगर कोई मनुष्य फ़ाइल बनाए रखता है और यह समझाना चाहता है कि कोई मान वैसा क्यों है, तो मानक JSON इस्तेमाल न करें।

चार व्यावहारिक रास्ते हैं, जितने invasive हैं उस क्रम में:

JSONC पर जाएँ, जो मानक JSON + comments + trailing commas है। VS Code का settings.json और tsconfig.json इसे इस्तेमाल करते हैं। कीमत यह है कि reader को jsonc-parser जैसा comment-सजग parser इस्तेमाल करना होगा; सादा JSON.parse fail होता है। विवरण JSON5 और JSONC: comments वाला JSON में हैं।
Sidecar दस्तावेज़ रखें। config.json मशीन-पठनीय रहे, जबकि config.md बताए कि हर field का क्या अर्थ है और उसका मान वैसा क्यों है। दोनों एक ही directory में रहें और एक ही commit में बदलें।
व्याख्याएँ schema में रखें। JSON Schema के description और $comment keywords fields का दस्तावेज़ीकरण कर सकते हैं, पर schemas शायद ही runtime configuration के साथ भेजे जाते हैं, इसलिए config पढ़ने वाले को वे कभी न दिखें।
TOML या YAML पर जाएँ, जिससे format खुद comments दे जो हर parser समझता हो।

复制{
  // 8080 पर निश्चित: frontend build script इस port को proxy के लिए पढ़ता है
  "port": 8080,
  // CI में inodes खत्म होने से बचने के लिए watching बंद करें
  "watch": false
}

JSONC अब भी एक dialect है: extension .json रहता है, पर केवल कुछ उपकरण उसे समझते हैं। जब डेटा टीम से बाहर जाता है या किसी service सीमा को पार करता है, तो JSONC और मानक JSON के बीच की रेखा document करनी पड़ती है।

4. Dates और multi-line strings: TOML का क्षेत्र

TOML date-time को first-class type बनाता है, चार रूपों के साथ: offset date-time, local date-time, local date और local time। Multi-line strings के पास समर्पित syntax है जो line breaks सुरक्षित रखता है:

复制title = "json-toolkit"
created = 2026-10-31T09:00:00+08:00
description = """
A JSON toolkit for developers.
Every operation runs locally in the browser.
"""

JSON में वही जानकारी date को string में नीचे करना और line breaks escape करना पड़ता है:

复制{
  "title": "json-toolkit",
  "created": "2026-10-31T09:00:00+08:00",
  "description": "A JSON toolkit for developers.\nEvery operation runs locally in the browser."
}

JSON में, "created" बस एक string है जो संयोग से date जैसी दिखती है, इसलिए type जानकारी एक field अनुबंध में रहनी पड़ती है: दोनों पक्ष सहमत हों कि field हमेशा RFC 3339 है। TOML parser को असली date object देता है बिना किसी मौखिक सहमति के।

YAML भी multi-line text रख सकता है, पर दो block शैलियों का अर्थ अलग है: | line breaks सुरक्षित रखता है जबकि > उन्हें spaces में fold करता है। गलत वाला चुनें और कोई address या SQL statement एक पंक्ति में सिमट जाता है, ऐसी गलती जिसे review में पकड़ना बहुत कठिन है।

5. Numbers: सबसे अधिक छूटा जाने वाला अंतर

JSON specification numeric precision पर कोई सीमा नहीं रखती, पर RFC 8259 यह भी चेतावनी देता है कि interoperability सबसे सुरक्षित तब है जब संख्याओं को IEEE 754 doubles माना जाए। JavaScript में, 2^53 - 1 से ऊपर के integers चुपचाप सटीकता खो देते हैं:

复制JSON.parse('{"id":9007199254740993}').id
// 9007199254740992: आखिरी अंक गया

TOML माँगता है कि signed 64-bit integers losslessly संभाले जाएँ और चुपचाप truncate करने के बजाय error दें; floats binary64 का पालन करते हैं और inf या nan भी हो सकते हैं। YAML 1.1 पुराना बोझ उठाता है: 1:30 90 (sexagesimal) के रूप में parsed होता है, और booleans yes, no, on व off स्वीकार करते हैं। इसीलिए वह प्रसिद्ध "Norway problem", जहाँ देश कोड NO false बन जाता है।

पैसे के लिए, इनमें से किसी भी format में floating point पर निर्भर न रहें: integer minor units, strings या database decimal type इस्तेमाल करें। Formatting और precision पर अधिक गहराई से JSON, YAML और XML रूपांतरण की सीमाएँ में चर्चा है।

6. Tables और nesting: TOML की कठोर सीमाएँ

TOML nesting को tables और arrays of tables से व्यक्त करता है:

复制[server]
port = 8080

[[routes]]
path = "/parse"
method = "POST"

[[routes]]
path = "/minify"
method = "POST"

रूपांतरण से पहले दो कठोर सीमाएँ जानना ज़रूरी है:

TOML document का root एक table है, इसलिए जिस JSON document का top level array है (जैसे [1, 2, 3]) उसका कोई वैध TOML प्रतिनिधित्व नहीं; उसे {"items": [...]} के रूप में लपेटना पड़ता है;
TOML में null नहीं है, इसलिए JSON का null field या तो हटाना पड़ता है या खाली string या sentinel मान से बदलना, और semantics उपभोक्ता पर डालने पड़ते हैं।

YAML उलटा है: nesting depth असीमित है, और anchors तथा merge keys fragments का पुनरुपयोग कर सकते हैं:

复制defaults: &defaults
  retries: 3
  timeoutMs: 5000

server:
  <<: *defaults
  port: 8080

Anchors YAML-केवल क्षमता हैं और रूपांतरण में गारंटीड नुकसान: JSON में कोई reference syntax नहीं, इसलिए expanded फ़ाइल बढ़ जाती है और कोई दर्ज नहीं करता कि दोनों sections पहले एक ही configuration थे।

7. परिदृश्य के अनुसार चयन

परिदृश्य	सुझाव	कारण
Public APIs, message queues, caches	JSON	अधिकतम सार्वभौमिकता, शून्य negotiation लागत
Application config, सपाट और typed	TOML	Comments, dates, lossless integers, स्थिर parser व्यवहार
Kubernetes, CI, Ansible	YAML	पारिस्थितिकी तंत्र तय है; format बदलना उपकरण बदलना है
VS Code, `tsconfig.json`	JSONC	मूल रूप से समर्थित, कोई नया format नहीं लाना
Configuration fragments का पुनरुपयोग	YAML	Anchors और merge keys ही तैयार विकल्प हैं
Generated और केवल-मशीन	JSON (minified)	Comments की ज़रूरत नहीं, सर्वोत्तम आकार और parse लागत
Legacy Atom या CoffeeScript प्रोजेक्ट्स	CSON, पर migration की योजना बनाएँ	पारिस्थितिकी तंत्र सीमांत है और migration लागत समय के साथ बढ़ती है

एक सामान्य नियम: configuration format पारिस्थितिकी तंत्र को चुनने दें, व्यक्तिगत पसंद को नहीं। Rust लिखना मतलब Cargo.toml, Kubernetes पर deploy करना मतलब YAML, और VS Code extension बनाना मतलब JSONC। केवल ऐसे नए प्रोजेक्ट में जहाँ कोई पारिस्थितिकी तंत्र बाधा नहीं, "कौन-सा लिखने में अच्छा है" असली प्रश्न बनता है।

8. रूपांतरण सीमाएँ

दिशा	हमेशा खोने वाली जानकारी	सलाह
JSON → TOML	`null`, top-level arrays, ऐसी keys जो व्यक्त नहीं हो सकतीं	पहले structure normalize करें और खाली fields हटाएँ
TOML → JSON	Comments, date types, `inf` / `nan`	Dates को RFC 3339 strings में बदलें
YAML → JSON	Comments, anchors और merge keys, tags, multiple documents	पहले anchors expand करें, फिर document-दर-document बदलें
JSON → YAML	कोई structural नुकसान नहीं, पर date strings स्वतः parsed हो सकती हैं	Date strings को quote करें
CSON → JSON	Comments, CoffeeScript expressions	एक बार migrate करें; दोनों दिशाओं में sync न करें

रूपांतरण उपकरण मानों की गारंटी देते हैं, comments की कभी नहीं। इसलिए दो-तरफ़ा pipeline डिज़ाइन न करें जहाँ "JSON स्रोत है और YAML build artifact"। या एक ही दिशा में generate करें, या एक ही स्रोत फ़ाइल बनाए रखें।

9. जाँच सूची

[ ] Document करें कि किस फ़ाइल प्रकार के लिए कौन-सा format है, और अनुमत dialects की सूची बनाएँ;
[ ] मनुष्यों द्वारा बनाए रखी configuration के लिए TOML या YAML पसंद करें, और मशीन आदान-प्रदान के लिए JSON;
[ ] JSON में dates को RFC 3339 strings के रूप में रखें और schema में format चिह्नित करें;
[ ] पैसे और 2^53 से बड़े integers को strings या minor units में व्यक्त करें, floats में कभी नहीं;
[ ] CI में हर format को उसके अपने parser से validate करें, YAML के लिए JSON.parse से कभी नहीं;
[ ] Formats को एक ही दिशा में migrate करें, और पुरानी फ़ाइल हटाएँ ताकि दोनों भटक न सकें।

सामान्य प्रश्न

JSON को TOML में बदलना कुछ fields पर क्यों fail होता है?

TOML में null नहीं है, और TOML document का root एक table है, इसलिए JSON का null field हटाना या खाली string या sentinel से बदलना पड़ता है, और top-level array को {"items": [...]} के रूप में लपेटना पड़ता है। Comments, date types और inf/nan भी उलटी दिशा में जाने पर खोते हैं, इसीलिए रूपांतरण एकतरफ़ा होना चाहिए।

क्या मुझे अलग-अलग formats में दो configuration फ़ाइलें रखनी चाहिए?

नहीं। रूपांतरण उपकरण मानों की गारंटी देते हैं पर comments की कभी नहीं, इसलिए जहाँ "JSON स्रोत है और YAML build artifact" वह pipeline भटक जाएगा। या केवल एक दिशा में generate करें, या एक ही स्रोत फ़ाइल बनाए रखें और migrate के बाद पुरानी हटा दें।

JSON configuration फ़ाइल में comments कैसे जोड़ें?

मानक JSON में comments नहीं हैं। आप JSONC पर जा सकते हैं (VS Code dialect, jsonc-parser से पढ़ें), हर field समझाने वाला sidecar दस्तावेज़ रख सकते हैं, या TOML व YAML पर जा सकते हैं। अन्य सिस्टम को भेजी जाने वाली फ़ाइलें मानक JSON ही रहनी चाहिए, व्याख्याएँ documentation या schema में रहें।

Application configuration के लिए TOML बेहतर है या YAML?

TOML तब चुनें जब structure सपाट हो, ज़्यादातर key-value pairs हो, और native dates मायने रखें; इसके semantics अधिक predictable हैं और parser अंतर छोटे। YAML तब चुनें जब आपको गहरा nesting, multiple documents, anchor reuse चाहिए, या target पारिस्थितिकी तंत्र YAML-first हो, जैसे Kubernetes या CI। दोनों comments समर्थित करते हैं, इसलिए असली भेद structural जटिलता और ecosystem lock-in है।

YAML में NO false क्यों बन जाता है?

YAML 1.1 yes, no, on, off, y और n को booleans मानता है, इसलिए Norway का देश कोड NO false के रूप में parsed होता है। यह "Norway problem" है। YAML 1.2 का पालन करने वाला implementation इस्तेमाल करके, या हर ऐसी string को quote करके बचें जिसकी गलत व्याख्या हो सकती है।

क्या CSON अब भी इस्तेमाल करने योग्य है?

नए प्रोजेक्ट्स के लिए नहीं। CSON CoffeeScript पारिस्थितिकी तंत्र पर निर्भर है, उसके कुछ ही maintained उपकरण हैं, और editor व CI समर्थन सीमित है; Atom के maintained रहना बंद करने के बाद उसके उपयोग-मामले और सिकुड़ गए। अगर किसी प्रोजेक्ट में पहले से CSON configuration है, तो उसमें और जोड़ने के बजाय JSON, TOML या YAML में एकबारगी migration की योजना बनाएँ।