JSON फ़ॉर्मैटर और वैलिडेटर

JSON फ़ॉर्मैटर का उपयोग कैसे करें

1. अपना JSON इनपुट बॉक्स में पेस्ट करें।
2. इसे प्रिटी-प्रिंट करने के लिए फ़ॉर्मैट / ब्यूटिफ़ाई पर क्लिक करें (2-स्पेस, 4-स्पेस या टैब इंडेंट चुनें), खाली जगह हटाने के लिए मिनिफ़ाई, या केवल जाँचने के लिए वैलिडेट।
3. यदि JSON अमान्य है, तो संदेश समस्या की ठीक-ठीक लाइन और कॉलम दिखाता है।
4. परिणाम को कॉपी या डाउनलोड करें।

फ़ॉर्मैट बनाम वैलिडेट बनाम मिनिफ़ाई

वैलिडेट करना जाँचता है कि आपका टेक्स्ट सही-गठित (well-formed) JSON है या नहीं। फ़ॉर्मैट करना (ब्यूटिफ़ाई) मान्य JSON को दोबारा इंडेंट कर देता है ताकि कोई इंसान नेस्टेड संरचनाएँ पढ़ सके। मिनिफ़ाई करना हर ग़ैर-ज़रूरी स्पेस और न्यूलाइन हटा देता है ताकि पेलोड यथासंभव छोटा हो जाए — नेटवर्क पर JSON भेजने या उसे एम्बेड करने से पहले उपयोगी। इनमें से कोई भी आपका डेटा नहीं बदलता: कीज़, वैल्यूज़, टाइप और की-ऑर्डर ठीक वैसे ही रहते हैं जैसे लिखे गए थे; केवल खाली जगह भिन्न होती है।

JSON के अमान्य होने के आम कारण

• ट्रेलिंग कॉमा — {"a":1,} अमान्य है; JSON अंतिम आइटम के बाद कोई कॉमा नहीं मानता।
• सिंगल कोट्स — स्ट्रिंग और कीज़ में "डबल कोट्स" होने चाहिए, कभी ' नहीं।
• बिना कोट वाली कीज़ — {name:"x"} को {"name":"x"} होना चाहिए।
• कमेंट — JSON में कोई // या /* */ कमेंट नहीं होते।
• ग़लत लिटरल — बूलियन और null वैल्यू लोअरकेस में होनी चाहिए (true, false, null); केवल-JavaScript के कीवर्ड मान्य JSON नहीं हैं।
• बेमेल ब्रैकेट — हर { और [ को अपना समापन साथी चाहिए।

क्या यह निजी है?

हाँ। यह टूल आपके ब्राउज़र के मूल JSON.parse और JSON.stringify का उपयोग करता है — कुछ भी किसी सर्वर पर नहीं भेजा जाता, इसलिए आंतरिक API रिस्पॉन्स, टोकन या कॉन्फ़िग पेस्ट करना सुरक्षित है। पेज लोड होने के बाद यह ऑफ़लाइन भी काम करता है।

JSON क्या है, और यह कहाँ से आया?

JSON (JavaScript Object Notation) संरचित डेटा के आदान-प्रदान के लिए एक हल्का, टेक्स्ट-आधारित फ़ॉर्मैट है। इसे Douglas Crockford ने नाम दिया और लोकप्रिय बनाया, जिन्होंने 2002 में json.org डोमेन पंजीकृत किया और वहाँ इसका व्याकरण प्रकाशित किया। JSON का सिंटैक्स JavaScript भाषा के ऑब्जेक्ट और ऐरे लिटरल से लिया गया है (विशेष रूप से 1999 के ECMAScript 3 मानक से), पर JSON स्वयं भाषा-निरपेक्ष है: लगभग हर प्रोग्रामिंग भाषा के लिए पार्सर और सीरियलाइज़र मौजूद हैं। यही ठीक-ठीक वजह है कि यह किसी ब्राउज़र, मोबाइल ऐप और सर्वर — जो अक्सर तीन अलग भाषाओं में लिखे होते हैं — के आपस में बात करने का डिफ़ॉल्ट तरीक़ा बन गया।

JSON को पहली बार IETF विनिर्देश के रूप में RFC 4627 (2006) में लिखा गया। बाद में इसे अक्टूबर 2013 में ECMA-404 के रूप में एक औपचारिक, मानक-निकाय व्याकरण दिया गया, और वर्तमान प्रामाणिक विनिर्देश RFC 8259 (2017) है, जो इंटरनेट स्टैंडर्ड STD 90 के रूप में भी प्रकाशित है। RFC 8259 ने एक नियम स्पष्ट किया जिसे पुराने दस्तावेज़ धुँधला छोड़ देते थे: सिस्टमों के बीच आदान-प्रदान किया गया JSON टेक्स्ट UTF-8 में एन्कोड किया जाना चाहिए। दोनों जीवंत विनिर्देश, ECMA-404 और RFC 8259, जानबूझकर एक-समान रखे गए हैं, और उनके संपादक सहमत हैं कि यदि कभी किसी एक में बदलाव हो तो दोनों को साथ-साथ अपडेट करें।

JSON के छह डेटा टाइप

किसी JSON दस्तावेज़ में हर वैल्यू बस छह टाइप में से एक होती है — इसके अलावा कुछ नहीं:

• Object — ब्रेसेस में लिपटे "key": value जोड़ों का एक अनक्रमित समूह। कीज़ डबल-कोटेड स्ट्रिंग होनी चाहिए।
• Array — वर्ग-कोष्ठकों में लिपटी वैल्यूज़ की एक क्रमित सूची। वैल्यूज़ मिश्रित टाइप की हो सकती हैं।
• String — डबल कोट्स में टेक्स्ट, बैकस्लैश एस्केप जैसे \n, \t, \" और \uXXXX के साथ।
• Number — एक दशमलव संख्या जैसे 42, -3.14 या 6.022e23। कोई अलग इंटीजर टाइप नहीं है, और NaN, Infinity तथा अग्रणी शून्य (leading zeros) की अनुमति नहीं है।
• Boolean — लोअरकेस लिटरल true या false।
• Null — लोअरकेस लिटरल null, अर्थात "कोई वैल्यू नहीं"।

एक JSON दस्तावेज़ बस इन्हीं टाइप में से एक की एक वैल्यू है — सबसे आम रूप में शीर्ष स्तर पर एक ऑब्जेक्ट या एक ऐरे, हालाँकि RFC 8259 किसी भी वैल्यू (यहाँ तक कि एक अकेले true या एकल संख्या) को एक पूर्ण JSON टेक्स्ट के रूप में अकेले खड़ा होने की अनुमति देता है।

JSON को इतना सख़्त क्यों होना पड़ता है

JSON जानबूझकर JavaScript सिंटैक्स का एक सख़्त उपसमुच्चय (subset) है — और उन ऑब्जेक्ट से भी अधिक सख़्त जो आप कोड में लिखते हैं। वह सख़्ती एक विशेषता है: एक कठोर व्याकरण का मतलब है कि हर अनुरूप पार्सर किसी दस्तावेज़ को एक ही तरह पढ़ता है, बिना किसी अस्पष्टता के। जो नियम लोगों को सबसे ज़्यादा उलझाते हैं वे इसी डिज़ाइन के सीधे परिणाम हैं। कोई कमेंट नहीं होते — Crockford ने उन्हें जानबूझकर हटा दिया ताकि कोई किसी डेटा फ़ाइल में पार्सिंग निर्देश न छिपा सके। कोई ट्रेलिंग कॉमा नहीं होते, क्योंकि कॉमा एक विभाजक है और अंतिम तत्व के बाद प्रकट नहीं हो सकता। कीज़ और स्ट्रिंग वैल्यूज़ दोनों के लिए केवल डबल कोट्स की अनुमति है; JavaScript में जो सिंगल कोट्स और बिना कोट वाली कीज़ आप इस्तेमाल कर सकते हैं वे मान्य JSON नहीं हैं। और कीवर्ड true, false तथा null केस-संवेदी हैं, इसलिए True या NULL विफल हो जाएगा।

संख्या-परिशुद्धता का जाल

JSON किसी संख्या के आकार या परिशुद्धता पर कोई सीमा नहीं लगाता, पर अधिकांश पार्सर — आपके ब्राउज़र के JSON.parse सहित — संख्याओं को 64-बिट IEEE 754 फ़्लोटिंग-पॉइंट वैल्यू में पढ़ते हैं। यह इंटीजर को सुरक्षित रूप से केवल 2⁵³ − 1 (9007199254740991, JavaScript में Number.MAX_SAFE_INTEGER के रूप में उपलब्ध) तक ही निरूपित करता है। उससे बड़ा कोई 64-बिट डेटाबेस ID या बहुत लंबा संख्यात्मक टोकन पार्स होते समय चुपचाप गोल (rounded) हो जाएगा। मानक समाधान यह है कि ऐसी वैल्यूज़ को स्ट्रिंग के रूप में भेजा जाए और केवल वहीं परिवर्तित किया जाए जहाँ बिग-इंटीजर टाइप उपलब्ध हो। यह एक सूक्ष्म बग है जिसके बारे में कोई फ़ॉर्मैटर आपको चेतावनी नहीं दे सकता, क्योंकि गोलाई पार्सर के भीतर होती है इससे पहले कि वैल्यू पेज तक पहुँचे।

JSON बनाम XML बनाम YAML

JSON से पहले, XML प्रमुख आदान-प्रदान फ़ॉर्मैट था। XML शक्तिशाली है — यह एट्रिब्यूट, नेमस्पेस, स्कीमा (XSD) और वैलिडेशन का समर्थन करता है — पर यह वाचाल है: हर तत्व को एक खुलने और बंद होने वाला टैग चाहिए, जो पेलोड आकार और पार्सिंग लागत बढ़ा देता है। JSON वही डेटा कहीं कम टेक्स्ट में व्यक्त करता है और अधिकांश भाषाओं की मूल संरचनाओं (ऑब्जेक्ट, ऐरे, मैप, लिस्ट) पर सीधे मैप होता है, यही वजह है कि REST API भारी बहुमत से इस पर आ गए।

YAML JSON का एक निकट-अधिसमुच्चय (near-superset) है जो कमेंट, एंकर और खाली-जगह-आधारित लेआउट जोड़ता है, जिससे यह इंसान-द्वारा-संपादित कॉन्फ़िगरेशन जैसे CI पाइपलाइन और Kubernetes मैनिफ़ेस्ट के लिए लोकप्रिय है। इसका ट्रेड-ऑफ़ यह है कि YAML की इंडेंटेशन-संवेदनशीलता उसे हाथ से आसानी से तोड़ देने योग्य बनाती है, जबकि JSON के स्पष्ट ब्रैकेट असंदिग्ध होते हैं। एक उपयोगी नियम: मशीनों के लिए JSON, इंसानों के लिए YAML, समृद्ध मार्कअप और मिश्रित सामग्री वाले दस्तावेज़ों के लिए XML।

ढीले रिश्तेदार: JSON5, JSONC और NDJSON

कई विस्तार JSON के नियमों को विशिष्ट कामों के लिए ढीला कर देते हैं। JSONC ("JSON with Comments") बस // और /* */ कमेंट की अनुमति देता है और यही Visual Studio Code अपनी सेटिंग्स फ़ाइलों के लिए उपयोग करता है। JSON5 आगे जाकर सिंगल कोट्स, बिना कोट वाली कीज़, ट्रेलिंग कॉमा और हेक्साडेसिमल संख्याओं की अनुमति देता है ताकि हाथ से संपादित फ़ाइलें अधिक क्षमाशील हों। NDJSON (जिसे JSON Lines भी कहते हैं) प्रति पंक्ति एक स्वतंत्र JSON ऑब्जेक्ट संग्रहीत करता है, जो स्ट्रीमिंग लॉग और बड़े डेटासेट के लिए आदर्श है क्योंकि एक रीडर पूरी फ़ाइल लोड किए बिना एक बार में एक रिकॉर्ड संसाधित कर सकता है। इनमें से कोई भी सख़्त JSON के साथ विनिमेय नहीं है — यदि कोई सर्वर RFC 8259 JSON की अपेक्षा करता है, तो कमेंट और ट्रेलिंग कॉमा अस्वीकृत हो जाएँगे, जो किसी "ठीक दिखने वाले" पेलोड के पार्स न होने का सबसे आम अकेला कारण है।

JSON आपको कहाँ मिलेगा

एक बार देखना शुरू करें तो JSON हर जगह है। यह अधिकांश REST और GraphQL API का बॉडी फ़ॉर्मैट है; अनगिनत टूलों की कॉन्फ़िगरेशन भाषा (package.json, tsconfig.json, composer.json); MongoDB जैसे NoSQL डेटाबेस का मूल दस्तावेज़ फ़ॉर्मैट; और हर JSON Web Token का पेलोड। विशेष उपभाषाएँ इसे नए क्षेत्रों में विस्तारित करती हैं: GeoJSON मानचित्र और भौगोलिक आकृतियाँ एन्कोड करता है, JSON-LD उन संरचित-डेटा स्निपेट को शक्ति देता है जिन्हें सर्च इंजन पढ़ते हैं, और JSON Schema अन्य JSON दस्तावेज़ों के आकार का वर्णन और वैलिडेशन करता है। JSON को अच्छी तरह जानना आधुनिक सॉफ़्टवेयर के सबसे उच्च-लाभ कौशलों में से एक है, क्योंकि वही फ़ॉर्मैट इतनी जगहों पर फिर-फिर दिखता है।

प्रिटी-प्रिंट या मिनिफ़ाई? यह पाठक पर निर्भर है

ब्यूटिफ़ाई किया गया JSON, इंडेंटेशन और लाइन-ब्रेक के साथ, एक पाठक के लिए है: इंसान। मिनिफ़ाई किया गया JSON, हर वैकल्पिक स्पेस हटाकर, एक अलग पाठक के लिए है: नेटवर्क। जिस डेटा को आप वायर पर भेजने वाले हैं उसे मिनिफ़ाई करें — पर याद रखें कि HTTP रिस्पॉन्स लगभग हमेशा gzip- या Brotli-संपीड़ित होते हैं, और संपीड़न पहले ही दोहराई गई खाली जगह को बहुत कुशलता से समेट देता है, इसलिए संपीड़न के बाद वास्तविक आकार-अंतर आमतौर पर मामूली होता है। मिनिफ़ाई करने का बड़ा लाभ केवल पार्स करने के लिए कम बाइट होना है। जो कुछ भी आप पढ़ रहे हैं, डीबग कर रहे हैं, वर्शन कंट्रोल में कमिट कर रहे हैं या किसी बग रिपोर्ट में पेस्ट कर रहे हैं, उसे पहले ब्यूटिफ़ाई करें: एक साफ़, इंडेंटेड संरचना किसी छूटे हुए ब्रैकेट या ग़लत जगह रखी वैल्यू को एक नज़र में स्पष्ट कर देती है।

JSON और सुरक्षा पर एक टिप्पणी

JSON को पार्स करना सुरक्षित है; उसे मूल्यांकित (evaluate) करना नहीं। शुरुआती दिनों में कुछ डेवलपर JSON को JavaScript के eval() को पास करके पार्स करते थे, जो टेक्स्ट में छिपे किसी भी कोड को निष्पादित कर देता — एक गंभीर भेद्यता। हमेशा JSON.parse (जिसे यह टूल इस्तेमाल करता है) जैसे किसी असली पार्सर का उपयोग करें और कभी eval का नहीं। एक सूक्ष्मता जानने योग्य है: अविश्वसनीय JSON में __proto__ नामक की, कुछ लाइब्रेरियों में, "प्रोटोटाइप-प्रदूषण" (prototype-pollution) हमलों के लिए इस्तेमाल की गई है। अच्छी तरह अनुरक्षित पार्सर अब इससे बचाव करते हैं, पर यह अविश्वसनीय JSON को संवेदनशील ऑब्जेक्ट-मर्जिंग कोड में सीधे न डालने का एक अच्छा कारण है।

JSON में कोई डेट टाइप नहीं है

एक आम आश्चर्य यह है कि JSON में तारीख़ों, समय या बाइनरी डेटा के लिए कोई मूल निरूपण नहीं है — केवल ऊपर बताए छह टाइप। भारी बहुमत परंपरा के अनुसार, तारीख़ें ISO 8601 स्ट्रिंग जैसे "2026-06-30T14:00:00Z" के रूप में ले जाई जाती हैं, और बाइनरी ब्लॉब Base64-एन्कोडेड स्ट्रिंग के रूप में। जब आप किसी JavaScript Date को JSON.stringify से सीरियलाइज़ करते हैं तो आपको स्वतः एक ISO 8601 स्ट्रिंग मिलती है, पर उसे वापस पार्स करने पर आपको एक स्ट्रिंग मिलती है, कोई Date नहीं — उसे आपको स्वयं परिवर्तित करना होता है। हर टाइमस्टैम्प को UTC (अंतिम Z) मानना और केवल प्रदर्शन के लिए स्थानीय समय में बदलना टाइमज़ोन बग से बचने का सबसे विश्वसनीय तरीक़ा है।

डुप्लिकेट कीज़ और की-ऑर्डर

दो और बातें लोगों को उलझाती हैं। पहली, RFC 8259 कहता है कि किसी ऑब्जेक्ट के भीतर के नाम अद्वितीय होने चाहिए पर डुप्लिकेट को मना नहीं करता, और यह उस पार्सर के व्यवहार को अपरिभाषित छोड़ देता है जो कोई दोहराई गई की से मिलता है। व्यवहार में अधिकांश पार्सर, ब्राउज़र के सहित, अंतिम घटना रखते हैं — पर आपको उस पर कभी निर्भर नहीं होना चाहिए, और डुप्लिकेट कीज़ अंतरसंचालनीयता बग का एक क्लासिक स्रोत हैं। दूसरी, हालाँकि एक JSON ऑब्जेक्ट औपचारिक रूप से एक अनक्रमित संग्रह है, हर मुख्यधारा पार्सर कीज़ के प्रविष्टि-क्रम को संरक्षित करता है, और यह फ़ॉर्मैटर ब्यूटिफ़ाई या मिनिफ़ाई करते समय आपकी कीज़ को ठीक उसी क्रम में रखता है जिस क्रम में आपने लिखीं। यदि आपका ऐप्लिकेशन वास्तव में किसी विशेष क्रम पर निर्भर करता है, तो उसे स्पष्ट रूप से एन्कोड करें — उदाहरण के लिए जोड़ों की एक ऐरे के रूप में — न कि ऑब्जेक्ट की-ऑर्डर पर भरोसा करके।

JSON में नेविगेट करना: JSONPath और JSON Pointer

जैसे-जैसे दस्तावेज़ बढ़ते हैं, आपको उनके भीतर गहराई में किसी वैल्यू का पता देने का तरीक़ा चाहिए। दो छोटे मानक ठीक यही करते हैं। JSON Pointer (RFC 6901) एक स्लैश-पृथक्कृत पथ जैसे /users/0/email का उपयोग एक ठीक-ठीक स्थान की ओर इशारा करने के लिए करता है — यही JSON Patch और JSON Schema आंतरिक रूप से किसी नोड को संदर्भित करने के लिए उपयोग करते हैं। JSONPath एक अधिक अभिव्यंजक, क्वेरी-जैसा सिंटैक्स है (XML के लिए XPath से प्रेरित) जो एक साथ कई नोड चुन सकता है, शर्त से फ़िल्टर कर सकता है और वाइल्डकार्ड इस्तेमाल कर सकता है — उदाहरण के लिए हर उपयोगकर्ता का ईमेल निकालने के लिए $.users[*].email। Pointer "यह एक जगह" का उत्तर देता है; JSONPath "जो कुछ भी मेल खाए" का। यह जानना कि ये मौजूद हैं, किसी बड़े ब्यूटिफ़ाई किए दस्तावेज़ में हाथ से खोजबीन बहुत बचा देता है।

बड़े JSON के साथ काम करने की युक्तियाँ

ब्राउज़र-आधारित टूल, इस टूल सहित, कई-मेगाबाइट फ़ाइलों को सहजता से संभाल लेते हैं क्योंकि काम आपकी मशीन पर स्थानीय रूप से होता है। जब दस्तावेज़ सचमुच बड़े हो जाएँ तो कुछ आदतें मदद करती हैं। पढ़ने से पहले ब्यूटिफ़ाई करें ताकि संरचना दिखाई दे, पर परिवहन के लिए एक मिनिफ़ाई की गई प्रति रखें। जो फ़ाइलें एक बार में मेमोरी में रखने के लिए बहुत बड़ी हों, उनके लिए NDJSON (प्रति पंक्ति एक ऑब्जेक्ट) को प्राथमिकता दें और उसे पंक्ति-दर-पंक्ति संसाधित करें, या किसी स्ट्रीमिंग पार्सर का उपयोग करें जो पूरा ट्री बनाने के बजाय पढ़ते-पढ़ते वैल्यूज़ उत्सर्जित करता है। और जब कोई API एक बड़ा संग्रह लौटाए, तो सब कुछ एक साथ माँगने के बजाय पेजिनेशन — एक next कर्सर या पेज पैरामीटर — ढूँढें; अच्छे डिज़ाइन वाले API कभी अपेक्षा नहीं करते कि आप एक ही रिस्पॉन्स में दस लाख रिकॉर्ड डाउनलोड करें।

अक्सर पूछे जाने वाले सवाल

क्या मेरा JSON किसी सर्वर पर अपलोड होता है?

नहीं। फ़ॉर्मैटिंग, वैलिडेशन और मिनिफ़िकेशन — सब कुछ आपके ब्राउज़र में JavaScript से चलता है। आपका डेटा कभी आपके डिवाइस से बाहर नहीं जाता, जो टूल को तेज़ और संवेदनशील पेलोड के लिए सुरक्षित बनाता है।

मेरा JSON अमान्य क्यों है?

सबसे आम कारण हैं — अंतिम आइटम के बाद ट्रेलिंग कॉमा, डबल कोट्स की जगह सिंगल कोट्स, बिना कोट वाली ऑब्जेक्ट कीज़, कमेंट (JSON में कोई नहीं होते), या कोई छूटा हुआ ब्रैकेट/ब्रेस। यह टूल आपको ठीक-ठीक वह लाइन और कॉलम बताता है जहाँ पार्सिंग विफल हुई।

फ़ॉर्मैटिंग, वैलिडेशन और मिनिफ़िकेशन में क्या अंतर है?

वैलिडेट करना जाँचता है कि टेक्स्ट सही-गठित (well-formed) JSON है या नहीं। फ़ॉर्मैट (ब्यूटिफ़ाई) करना मान्य JSON को दोबारा इंडेंट कर देता है ताकि वह पढ़ने योग्य हो। मिनिफ़ाई करना सारी खाली जगह हटा देता है ताकि पेलोड परिवहन के लिए यथासंभव छोटा हो जाए। यह टूल तीनों काम एक ही बॉक्स से करता है।

क्या फ़ॉर्मैटिंग मेरा डेटा बदल देती है?

नहीं। ब्यूटिफ़ाई और मिनिफ़ाई केवल खाली जगह बदलते हैं — कीज़, वैल्यूज़, टाइप और संरचना समान रहती है। ऑब्जेक्ट की-ऑर्डर वैसा ही रखा जाता है जैसा लिखा गया था।

यह कितनी बड़ी फ़ाइल संभाल सकता है?

चूँकि यह आपके ब्राउज़र में चलता है, यह आम API रिस्पॉन्स और कॉन्फ़िग फ़ाइलों (कई MB) को सहजता से संभाल लेता है। बहुत बड़ी फ़ाइलें केवल आपके डिवाइस की मेमोरी से सीमित होती हैं, किसी अपलोड सीमा से नहीं।

संबंधित डेवलपर टूल

• JSON से CSV
• JSON से XML
• JSON से HTML टेबल
• CSV से JSON
• Base64 एन्कोडर / डिकोडर

सभी डेवलपर और डेटा रूपांतरण देखें →