मुफ़्त JSON वैलिडेटर

वास्तविक समय में JSON सिंटैक्स को सत्यापित करें। पंक्ति संख्याओं के साथ विस्तृत त्रुटि संदेश प्राप्त करें, सामान्य समस्याओं को स्वचालित रूप से ठीक करें, और JSON को तुरंत फ़ॉर्मेट/मिनीफ़ाई करें।

✗ इनपुट की प्रतीक्षा में…

JSON सत्यापन: दो परतें, दो अलग सवाल

एक JSON सत्यापनकर्ता एक द्विआधारी सवाल का उत्तर देता है, क्या यह एक अच्छी तरह से बना JSON दस्तावेज़ है?, इनपुट को उसी पार्सर को सौंप कर जो ब्राउज़र आंतरिक रूप से उपयोग करता है और रिपोर्ट करते हुए कि क्या यह सिंटैक्स स्वीकार करता है। यह उपकरण वही करता है और केवल वही। यह जाँचता नहीं कि क्या दस्तावेज़ के अंदर डेटा वह अर्थ रखता है जो आपने चाहा था। वह दूसरा सवाल, क्या दस्तावेज़ की वह आकृति, प्रकार और बाधाएँ हैं जो आपकी एप्लिकेशन अपेक्षा करती है?, स्कीमा सत्यापन है, Ajv (नीचे कवर) जैसे उपकरणों का क्षेत्र। दो गतिविधियाँ एक-दूसरे की पूरक हैं और अलग सवालों के उत्तर देती हैं; एक का उपयोग करना जब आप दूसरा चाहते थे, एक श्रेणी त्रुटि है। एक उपयोगी सादृश्य वर्ड प्रोसेसर में स्पेलिंग-चेक / व्याकरण-चेक भेद है: स्पेलिंग चेक (सिंटैक्स) आपको बताती है कि प्रत्येक शब्द एक असली शब्द है या नहीं; व्याकरण चेक (स्कीमा) आपको बताती है कि वाक्य समझ में आता है या नहीं; दोनों उपयोगी हैं, कोई एक दूसरे की जगह नहीं लेता, और कोई आपको नहीं बताता कि निबंध अच्छा है या नहीं। {"phoneNumber": 12345} अच्छी तरह से बना JSON है, पर यदि आपकी एप्लिकेशन "+1-555-555-1234" के रूप में स्वरूपित स्ट्रिंग की अपेक्षा करती थी, यह ग़लत है, और एक सिंटैक्स सत्यापनकर्ता बता नहीं सकता।

सिंटैक्स-जाँच के अलावा, यह उपकरण «सामान्य समस्याएँ ठीक करें» का सर्वोत्तम-प्रयास पास भी प्रदान करता है जो उन चार सबसे लगातार तरीकों को फिर से लिखता है जिनसे डेवलपर अनजाने में अमान्य JSON लिखते हैं: अंतिम अल्पविराम, एक-उद्धरण स्ट्रिंग्स, बिना-उद्धरण कुंजियाँ, और undefined लिटरल्स (null के रूप में फिर से लिखे गए)। यह एक heuristic है, पार्सर नहीं, इसलिए अपनाने से पहले हमेशा सही किए गए आउटपुट की समीक्षा करें।

JSON का संक्षिप्त इतिहास

JSON की जीवनी उल्लेखनीय रूप से छोटी है। संक्षिप्त नाम State Software, Inc. में गढ़ा गया था, एक छोटी परामर्श कंपनी जिसे Douglas Crockford और Chip Morningstar ने मार्च 2001 में सह-संस्थापित किया, जिसे बाद में Ajax वेब एप्लिकेशन कहा जाएगा। पहला JSON संदेश अप्रैल 2001 में Morningstar के बे-एरिया गैरेज में एक कंप्यूटर से भेजा गया था। Crockford JSON का आविष्कार करने का दावा नहीं करते, यह प्रारूप JavaScript भाषा के अंदर पहले से ही ऑब्जेक्ट-लिटरल सबसेट के रूप में मौजूद था; उनका योगदान इसे अलग करना, इसे एक नाम देना, एक वेबसाइट बनाना (json.org 2002 में तीन नोटेशन में व्याकरण के विवरण और JavaScript संदर्भ पार्सर के साथ खड़ा हुआ), और अपनाने के लिए लॉबी करना था। दिसंबर 2005 वह क्षण है जिसे अधिकांश इतिहासकार JSON के मुख्यधारा में आने के रूप में इंगित करते हैं: उस महीने, Yahoo! ने अपनी कुछ वेब सेवाएँ JSON में पेश करना शुरू किया। IETF ने इसे आगे उठाया: RFC 4627 («The application/json Media Type for JSON»), स्वयं Crockford द्वारा लिखी गई, जुलाई 2006 में सूचनात्मक दस्तावेज़ के रूप में प्रकाशित हुई, Standards Track नहीं। मानक निकायों ने 2013-2014 में पकड़ा: ECMA-404 पहला संस्करण अक्टूबर 2013 में (जानबूझकर न्यूनतम, सारगर्भित सामग्री के छह पन्ने), RFC 7159 मार्च 2014 में (शीर्ष-स्तर प्रतिबंध को ढीला किया ताकि कोई भी JSON मान, केवल वस्तुएँ और सरणियाँ नहीं, एक पूरा दस्तावेज़ हो सके), और वर्तमान जोड़ी दिसंबर 2017 में: RFC 8259 (अब Internet Standard STD 90) और इसके साथ नियामक रूप से संरेखित ECMA-404 दूसरा संस्करण। दोनों जोड़ी-बद्ध हैं: प्रत्येक दूसरे का नियामक रूप से संदर्भ देता है और संगत रखने की प्रतिबद्धता रखता है। ISO/IEC 21778:2017 के रूप में भी प्रकाशित।

200 शब्दों में JSON व्याकरण

एक JSON दस्तावेज़ एक एकल मान है, वैकल्पिक रूप से सफ़ेद-स्थान से घिरा हुआ। ठीक छह मान प्रकार हैं: ऑब्जेक्ट, शून्य या अधिक नाम/मान जोड़ियों का एक अव्यवस्थित संग्रह, {"k": v, "k2": v2} लिखा हुआ; एरे, एक क्रमबद्ध अनुक्रम, [v, v2, v3] (spec द्वारा एरे क्रम बनाए रखते हैं); स्ट्रिंग, दोहरे उद्धरण चिह्नों में लिपटा Unicode वर्णों का अनुक्रम (एकल उद्धरण चिह्न अनुमत नहीं; बैकस्लैश एस्केप \", \\, \/, \b, \f, \n, \r, \t साथ ही \uXXXX; नियंत्रण वर्ण U+0000 से U+001F तक एस्केप किए जाने चाहिए); नंबर, एक सख्त ASCII रूप (वैकल्पिक माइनस चिह्न, बिना अग्रणी शून्य के पूर्णांक भाग, वैकल्पिक भिन्न भाग, e या E के साथ वैकल्पिक घातांक); true / false, JSON बूलियन, केवल छोटे अक्षर; null, मान की अनुपस्थिति, केवल छोटे अक्षर। टोकनों के बीच सफ़ेद-स्थान अनुमत और अनदेखा है। कोई टिप्पणियाँ नहीं। कोई अंतिम अल्पविराम नहीं। ऑब्जेक्ट कुंजियाँ दोहरे-उद्धृत स्ट्रिंग होनी चाहिए। व्याकरण एक पन्ने में फ़िट हो जाता है। सख्त संख्या रूप hex (0xFF), अष्टक (0777), + चिह्न, Infinity, NaN, और 1. जैसे अंतिम दशमलव बिंदुओं को निषेध करता है; यह उन सभी को पकड़ता है जो ऐसे वातावरण में हाथ से JSON लिख रहे हैं जो ढीले ECMAScript संख्यात्मक रूप स्वीकार करते हैं, सबसे आम तौर पर, उन्हें जो कभी एक hex रंग कोड को JSON फ़ाइल में पेस्ट कर चुके हैं।

व्याकरण इतना सख्त क्यों है, Crockford के डिज़ाइन विकल्प

दो जानबूझकर की गई चूक उन घर्षणों के अधिकांश के लिए ज़िम्मेदार हैं जो उपयोगकर्ता हाथ से JSON लिखते समय महसूस करते हैं। कोई टिप्पणियाँ नहीं। JavaScript के पास // और /* */ दोनों टिप्पणियाँ हैं; JavaScript उपसेट JSON के पास कोई नहीं। Crockford का घोषित कारण, 2012 में Google+ पर पोस्ट किया गया, तब से हज़ारों बार उद्धृत किया गया है: «मैंने JSON से टिप्पणियाँ हटा दीं क्योंकि मैंने देखा कि लोग उन्हें पार्सिंग निर्देशिकाएँ रखने के लिए उपयोग कर रहे थे, एक अभ्यास जो इंटरऑपरेबिलिटी को नष्ट कर देता। मुझे पता है कि टिप्पणियों की कमी कुछ लोगों को दुखी करती है, पर ऐसा नहीं होना चाहिए।» तर्क यह है कि टिप्पणियाँ विस्तार के लिए आमंत्रित करती हैं, यदि // @schema foo.json आपकी config में है और आपका उपकरण इसे पढ़ता है, तो आपकी config फ़ाइल अब JSON नहीं है। कोई अंतिम अल्पविराम नहीं। अल्पविराम एक विभाजक है, टर्मिनेटर नहीं। [1, 2, 3] क़ानूनी है पर [1, 2, 3,] नहीं है। कारण टिप्पणियों के समान है: व्याकरण की सादगी और पार्सरों में एकरूपता। लागत यह है कि कोई भी जो एक बहु-पंक्ति JSON ऑब्जेक्ट संपादित करता है, एक प्रॉपर्टी जोड़ता है, प्रॉपर्टीज़ पुनर्व्यवस्थित करता है, अंतिम प्रॉपर्टी हटाता है, उसे अल्पविराम के बारे में सोचना पड़ता है। कोई undefined नहीं। JavaScript के पास undefined है; JSON के पास नहीं। null उपयोग करें या प्रॉपर्टी को पूरी तरह से छोड़ दें। इनपुट में BOM। JSON दस्तावेज़ की शुरुआत में एक बाइट-ऑर्डर मार्क (U+FEFF) प्रेषित JSON में निषिद्ध है, पर पार्सर एक को अनदेखा कर सकते हैं यदि वह दिखे। व्यवहार में, पुराने Windows संपादकों द्वारा «UTF-8 with BOM» के रूप में सहेजी गई फ़ाइलें कुछ पार्सरों को चुपचाप तोड़ती हैं और दूसरों में चुपचाप काम करती हैं।

सामान्य JSON त्रुटियाँ:

JSON Schema, आकार सत्यापन के लिए मानक

JSON Schema JSON दस्तावेज़ों की संरचना और बाधाओं का वर्णन करने के लिए JSON-आधारित शब्दावली है। पहला प्रस्ताव Kris Zyp द्वारा अक्टूबर 2007 में प्रस्तुत किया गया; IETF Internet-Draft श्रृंखला 5 दिसंबर 2009 को draft-zyp-json-schema-00 से शुरू हुई। उत्तरोत्तर ड्राफ्ट अगले डेढ़ दशक में आधा दर्जन लेखकों और संपादकों के माध्यम से विकसित हुए। वर्तमान स्थिर संस्करण 2020-12 ड्राफ्ट है (नाम «2020-12» उस विकास स्नैपशॉट को संदर्भित करता है जिससे यह व्युत्पन्न हुआ; वास्तविक औपचारिक रिलीज़ 16 जून 2022 था)। चार सबसे अधिक उपयोग किए जाने वाले अभिकथन कीवर्ड दैनिक कार्य का अधिकांश हिस्सा संभालते हैं: type (एक मान को छह JSON प्रकारों में से एक या स्वीकार्य प्रकारों की सूची तक सीमित करता है), required (प्रॉपर्टी नामों की सूची जो एक ऑब्जेक्ट में होनी चाहिए), properties (प्रॉपर्टी नाम से मान के लिए उप-स्कीमा का मानचित्र), और items (एरे के प्रत्येक तत्व पर लागू एक स्कीमा)। minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, आदि) और सम्मिश्र कीवर्ड (allOf, anyOf, oneOf, not) के साथ संयुक्त, JSON Schema लगभग किसी भी «आकार» बाधा को व्यक्त कर सकता है जिसे आपके डेटा को संतुष्ट करना है। स्कीमा स्वयं एक JSON दस्तावेज़ है, जो एक ऐसे तरीके से पुनरावर्ती है जिसे कुछ लोग सुरुचिपूर्ण और कुछ चक्करदार पाते हैं।

Ajv, प्रमुख JavaScript स्कीमा सत्यापनकर्ता

यदि आप JavaScript में स्कीमा सत्यापन करना चाहते हैं, तो विहित उत्तर Evgeny Poberezkin का Ajv (Another JSON Schema Validator) है। इसकी चाल स्कीमा को अनुकूलित JavaScript में संकलित करना है: रनटाइम पर स्कीमा और डेटा पेड़ चलने के बजाय, यह एक फ़ंक्शन उत्पन्न करता है जो हर जाँच को हार्ड-कोड करता है और मूल गति से चलता है। यह इसे बड़े दस्तावेज़ों और गर्म सत्यापन पथों पर भोले सत्यापनकर्ताओं से नाटकीय रूप से तेज़ बनाता है। Ajv JSON Schema drafts 04, 06, 07, 2019-09 और 2020-12 का समर्थन करता है; यह express-validator, AWS API Gateway अनुरोध सत्यापन और कई प्रमुख Node.js फ़्रेमवर्क में निर्मित सत्यापनकर्ता है। Python के लिए, विहित विकल्प Julian Berman का jsonschema है; Java के लिए, Networknt का json-schema-validator। बिंदु यह है कि स्कीमा सत्यापन एक हल किया गया, परिपक्व, अच्छी तरह से उपकरण-संपन्न समस्या है, पर यह एक ऐसी समस्या है जिसमें आपको स्कीमा लिखकर ऑप्ट-इन करना होता है। यह उपकरण आपके लिए स्कीमा नहीं लिखता; यह केवल सिंटैक्टिक सत्यापन करता है।

JSON5 और JSONC, ढीले महासुपरसेट

JSON5 JSON का एक औपचारिक सुपरसेट है, json5.org पर निर्दिष्ट, मूल रूप से Aseem Kishore द्वारा 2012 में डिज़ाइन किया गया और अब Jordan Tucker द्वारा अनुरक्षित। यह वह सब कुछ अनुमति देता है जो सख्त JSON निषेध करता है: टिप्पणियाँ (// और /* */), अंतिम अल्पविराम, एक-उद्धरण स्ट्रिंग्स, बिना-उद्धरण ऑब्जेक्ट कुंजियाँ (जब वे वैध ECMAScript पहचानकर्ता हैं), हेक्साडेसिमल संख्याएँ, अग्रणी/अनुगामी दशमलव बिंदु (.5 या 5.), Infinity और NaN, और चिह्नित संख्याएँ। JSON5 दस्तावेज़ आम तौर पर .json5 एक्सटेंशन का उपयोग करते हैं और json5 npm पैकेज जैसे पुस्तकालयों द्वारा पार्स किए जाते हैं। JSONC Microsoft का अनौपचारिक «JSON with Comments» मोड है, जिसका उपयोग VS Code की सेटिंग फ़ाइलों (settings.json, launch.json, tasks.json) में किया जाता है। टिप्पणियाँ spec द्वारा अनुमत हैं; अंतिम अल्पविराम संदर्भ पार्सर द्वारा सहन किए जाते हैं पर चेतावनी के साथ चिह्नित होते हैं। ढीले रूप मानव-संपादित कॉन्फ़िगरेशन फ़ाइलों के लिए हैं जहाँ सख्त JSON का अनुशासन बाधा बनता है; मशीन-से-मशीन डेटा आदान-प्रदान के लिए, सख्त JSON अभी भी सही विकल्प है। यह उपकरण ब्राउज़र के सख्त JSON.parse का उपयोग करता है और इसलिए दोनों को अस्वीकार करेगा, पेस्ट करने से पहले टिप्पणियाँ और अंतिम अल्पविराम हटाएँ, या पहले सख्त JSON में परिवर्तित करने के लिए JSON5/JSONC पार्सर का उपयोग करें।

बहुत बड़े इनपुट के लिए स्ट्रीमिंग सत्यापनकर्ता

ब्राउज़र JSON.parse पूरे दस्तावेज़ को मेमोरी में एकल ऑब्जेक्ट ट्री के रूप में लोड करता है। अधिकांश इनपुट के लिए यह ठीक है; लॉग फ़ाइलों, बहु-गीगाबाइट API निर्यात या सेंसर-डेटा डंप के लिए नहीं। स्ट्रीमिंग दृष्टिकोण दस्तावेज़ को टोकन धारा के रूप में उपभोग करना और घटनाएँ («एरे प्रारंभ», «स्ट्रिंग मान», «ऑब्जेक्ट कुंजी») उत्सर्जित करना है बिना पूरी संरचना को कभी मेमोरी में रखे। Marak Squires का clarinet विहित Node.js स्ट्रीमिंग JSON पार्सर है, SAX XML पार्सर पैटर्न पर मॉडल किया गया। Jim Higson का Oboe.js (उनकी 2013 की थीसिस में उत्पन्न) ब्राउज़र-अनुकूल समतुल्य है, fetch पर JSON का उपभोग करने के लिए डिज़ाइन किया गया जैसे यह स्ट्रीम होता है और हर मेल खाने वाले JSONPath के लिए घटनाएँ उत्सर्जित करता है; यह अब सक्रिय रूप से अनुरक्षित नहीं है पर इसने जो तकनीक शुरू की वह अभी भी उपयोगी है। npm पर JSONStream पाइप-अनुकूल Node उपयोग के लिए clarinet को लपेटता है। इस तरह का शुद्ध-ब्राउज़र उपकरण उपलब्ध मेमोरी से बंधा है; यदि आप गीगाबाइट-स्केल JSON सत्यापित कर रहे हैं, Node में एक स्ट्रीमिंग पार्सर चलाएँ या कमांड लाइन पर jq --stream का उपयोग करें।

वास्तविक वर्कफ़्लो में JSON सत्यापन कहाँ मायने रखता है

कॉन्फ़िगरेशन फ़ाइलें सबसे अधिक उत्तोलन वाला मामला हैं: tsconfig.json, package.json, ESLint और Prettier configs, Docker Compose, AWS IAM नीतियाँ। एक एकल अमान्य वर्ण build तोड़ सकता है; एक सिंटैक्टिक सत्यापनकर्ता इसे build से पहले पकड़ लेता है। API प्रतिक्रियाएँ अगली हैं: किसी बाहरी API के विरुद्ध विकास करने का मतलब अक्सर एक payload को घूरते हुए पूछना होता है «क्या यह वास्तव में वैध JSON है?» कोड में गहराई से एक पार्सिंग बग का पीछा करने से पहले। वेबहुक पेलोड, Stripe ईवेंट, GitHub Actions ट्रिगर, Slack incoming वेबहुक, JSON हैं; एक त्वरित पेस्ट-और-सत्यापित उन मामलों को पकड़ता है जहाँ एक विकृत हस्ताक्षर या एक भटका हुआ बाइट बॉडी को भ्रष्ट कर चुका हो। लॉग प्रविष्टियाँ (Splunk, Datadog, Loki संरचित लॉग) पंक्ति-सीमांकित JSON हैं; एक खराब पंक्ति पूरी ingest पाइपलाइन को तोड़ देती है। उत्पन्न JSON फ़ाइलें (lockfiles, build manifests, परीक्षण fixtures) कभी-कभी सामान्य विकास के दौरान शोरगुल वाले तरीकों से बहती हैं; एक सिंटैक्स सत्यापनकर्ता उन मामलों को पकड़ता है जहाँ उत्पादन कदम स्वयं विफल हुआ।

केवल-सिंटैक्स सत्यापनकर्ता की ईमानदार सीमाएँ

एक सिंटैक्टिक सत्यापनकर्ता तर्क त्रुटियाँ नहीं पकड़ सकता। यह आपको नहीं बता सकता कि एक «phone number» फ़ील्ड स्ट्रिंग के बजाय एक पूर्णांक है; कि एक «date» स्ट्रिंग विकृत है पर वैध स्ट्रिंग होती है; कि एक आवश्यक फ़ील्ड गायब है; कि एक संख्या जो धनात्मक होनी चाहिए ऋणात्मक है; कि दो फ़ील्ड जो मेल खानी चाहिए नहीं मेल खाती। ये सब स्कीमा-सत्यापन समस्याएँ हैं। एक उत्पादन प्रणाली के लिए सही पाइपलाइन है: (1) सिंटैक्टिक सत्यापन पहले गेट के रूप में, क्या यह JSON के रूप में पार्स होता है? (2) स्कीमा सत्यापन दूसरे गेट के रूप में, क्या इसकी अपेक्षित आकृति है? (3) व्यावसायिक-तर्क सत्यापन तीसरे गेट के रूप में, क्या अन्य स्थिति को देखते हुए डेटा समझ में आता है? तीनों परतों के लिए उपकरण मौजूद हैं; यह केवल पहली को संभालता है। एक payload को पहले एक सिंटैक्टिक सत्यापनकर्ता में चिपकाने का लाभ यह है कि यह सबसे सस्ते, सबसे आम विफलता मोड (एक भटका हुआ अल्पविराम, एक गायब ब्रेस) को अधिक महंगी स्कीमा त्रुटियों से अलग करता है जो अन्यथा उन्हें डुबा देतीं।

गोपनीयता: यहाँ केवल-ब्राउज़र क्यों मायने रखता है

सर्वर पर JSON सत्यापन के लिए दस्तावेज़ अपलोड करना आवश्यक है। साधारण सार्वजनिक-डेटा उदाहरणों के लिए यह हानिरहित है। प्रमाणीकरण टोकन, ग्राहक PII, आंतरिक कर्मचारी रिकॉर्ड, कॉन्फ़िगरेशन रहस्य, या अप्रकाशित उत्पाद डेटा वाली API प्रतिक्रियाओं के लिए, यह नहीं है। सबसे ईमानदार हटाने की नीति के साथ भी, अपलोड सर्वर लॉग में बैठता है, संभवतः CDN कैश में, संभवतः एक एनालिटिक्स पाइपलाइन में, संभवतः एक बैकअप में। यह उपकरण JavaScript के माध्यम से आपके ब्राउज़र में JSON.parse चलाता है। चिपकाया गया दस्तावेज़ कभी नेटवर्क पार नहीं करता, एक बटन क्लिक करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) करें और पुष्टि करें कि सत्यापनकर्ता अभी भी काम करता है। रहस्यों के साथ webhook पेलोड, ऑथ हेडर वाले API प्रतिक्रियाएँ, डेटाबेस क्रेडेंशियल्स वाली कॉन्फ़िगरेशन फ़ाइलें, या किसी अन्य JSON को सत्यापित करने के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं देखना चाहते।

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

मान्य JSON क्या है?

मान्य JSON इनमें से एक प्रकार होना चाहिए: ऑब्जेक्ट ({}), ऐरे ([]), स्ट्रिंग (""), संख्या, बूलियन (true/false) या null।

"सामान्य समस्याएँ ठीक करें" क्या करता है?

"ठीक करें" स्वचालित रूप से सामान्य त्रुटियाँ ठीक करने का प्रयास करता है: पीछे के कॉमा, एकल उद्धरण दोहरे उद्धरण में, कुंजियों को उद्धरित करना।

अपने एप्लिकेशन में JSON कैसे सत्यापित करें?

JavaScript में: JSON.parse() का उपयोग करें और त्रुटियाँ पकड़ें। Node.js में: fs.readFileSync() + JSON.parse()। Python में: json.loads()।

क्या मैं JSON5 या JSONC (टिप्पणियों के साथ JSON) सत्यापित कर सकता हूँ?

सीधे नहीं। यह उपकरण ब्राउज़र के सख्त JSON.parse का उपयोग करता है, जो RFC 8259 का पालन करता है, टिप्पणियाँ, अंतिम अल्पविराम, एकल उद्धरण और बिना-उद्धरण कुंजियाँ सिंटैक्स त्रुटियाँ हैं। यदि आपका इनपुट JSON5 (json5.org, Aseem Kishore 2012, Jordan Tucker द्वारा अनुरक्षित) या VS Code का JSONC है, तो json5 npm पैकेज या jsonc-parser पैकेज स्थापित करें, सख्त JSON में परिवर्तित करें, फिर सत्यापित करें। «सामान्य समस्याएँ ठीक करें» पास अंतरों के एक उपसमुच्चय को संभालता है पर पूर्ण JSON5 / JSONC पार्सर नहीं है।

क्या आकार सीमा है?

कोई कठोर सीमा नहीं, पर ब्राउज़र का JSON.parse पूरे दस्तावेज़ को मेमोरी में एकल ऑब्जेक्ट ट्री के रूप में लोड करता है। हज़ारों लाइनें आराम से काम करती हैं; बहु-गीगाबाइट लॉग डंप मेमोरी ख़त्म कर देंगे। बहुत बड़े JSON के लिए, एक स्ट्रीमिंग पार्सर चलाएँ जैसे clarinet (Marak Squires) या Oboe.js (Jim Higson, 2013), या कमांड लाइन पर jq --stream का उपयोग करें, जो मनमाने आकार के दस्तावेज़ों को बिना पूरी सामग्री लोड किए संसाधित कर सकता है।

क्या मेरे JSON दस्तावेज़ अपलोड होते हैं?

नहीं। JSON.parse JavaScript के माध्यम से आपके ब्राउज़र में चलता है। चिपकाया गया दस्तावेज़ कभी नेटवर्क पार नहीं करता, Validate क्लिक करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पृष्ठ को ऑफ़लाइन करें और पुष्टि करें कि उपकरण अभी भी काम करता है। रहस्यों के साथ webhook पेलोड, ऑथ हेडर वाले API प्रतिक्रियाएँ, या डेटाबेस क्रेडेंशियल्स वाली कॉन्फ़िगरेशन फ़ाइलें सत्यापित करने के लिए सुरक्षित।

संबंधित टूल

निःशुल्क JSON फॉर्मेटर और वैलिडेटर JSON से CSV JSON से YAML