CSV to JSON Converter

Yes. The parser follows RFC 4180 quoting rules: a field wrapped in double quotes can contain commas, quotes, or embedded line breaks, and a literal quote inside it is written as two double quotes (""), which the converter un-escapes automatically. A comma outside quotes is always a column separator, so "Doe, John" parses as a single field containing a comma rather than splitting into two fields — the same rule Excel and Google Sheets use when they export quoted CSV.

The later column silently overwrites the earlier one. Each row becomes a single JSON object keyed by header name, and JavaScript object keys can't repeat, so if your source file has two columns both labeled "Notes" (common after a spreadsheet merge or export bug), only the second column's values survive in the JSON — the first column's data is dropped without a warning. Rename duplicate headers before pasting if you need to keep both columns.

This page is comma-only, matching the plain "CSV to JSON" use case most people search for. If your file is semicolon- or tab-delimited — common in European locales where the comma is used as the decimal separator, or in files exported from database tools — use the full CSV/JSON converter, which auto-detects the delimiter or lets you choose comma, semicolon, tab, or pipe explicitly.

Rows are matched to headers by position, not by count, and nothing here throws an error. A short row (fewer fields than headers) fills the missing trailing values with null; a long row (more fields than headers) has its extra values silently discarded, since only as many fields as there are headers get read. Ragged CSV — often caused by a stray or missing delimiter partway through a file — won't be flagged, so check row lengths first if exact column alignment matters.

ऐसा इसलिए होता है क्योंकि converter हर सेल के टेक्स्ट पैटर्न से टाइप का अनुमान लगाता है, और 02138 या 4025 जैसी साधारण digit string integer पैटर्न से मैच कर जाती है, चाहे वह असल में किसी और चीज़ को दर्शाती हो। एक बार इसे नंबर मान लिया जाए, तो parseInt("02138") का नतीजा 2138 होता है — शुरुआती ज़ीरो गायब हो जाता है, क्योंकि JSON numbers में "padded" digits जैसा कोई कॉन्सेप्ट नहीं होता जैसा कि किसी string में होता है। CSV खुद किसी फ़ील्ड को "इसे टेक्स्ट ही रहने दो" कहकर फ़्लैग नहीं कर सकता: RFC 4180 की quoting सिर्फ़ यह तय करती है कि कॉमा, क्वोट्स, और लाइन ब्रेक्स को कैसे escape किया जाए, न कि quotes के अंदर मौजूद डेटा का टाइप क्या है, इसलिए quoted "02138" और unquoted 02138 दोनों एक जैसे ही पार्स होते हैं। अगर आप ZIP codes, फ़ोन नंबर, SKUs, या account numbers कन्वर्ट कर रहे हैं, तो पूरा CSV/JSON converter tool इस्तेमाल करें और टाइप इन्फरेंस बंद कर दें ताकि हर कॉलम स्ट्रिंग के रूप में सुरक्षित रहे, फिर जहाँ आपको वाक़ई नंबर चाहिए वहाँ चुनिंदा तरीके से टाइपिंग दोबारा जोड़ें।

सबसे आम मामला है किसी स्प्रेडशीट एक्सपोर्ट को ऐसी जगह ले जाना जो सिर्फ़ JSON समझती है। कोई मार्केटिंग टीम CRM से लीड्स की CSV एक्सपोर्ट करती है और उसे किसी webhook या Zapier/Make ऑटोमेशन को POST करना होता है जो JSON body की उम्मीद करता है। किसी बैकएंड डेवलपर के पास किसी वेंडर से प्रोडक्ट डेटा की CSV होती है और उसे MongoDB या Firestore में bulk-insert करना होता है, जो दोनों rows-and-columns की बजाय JSON-जैसे डॉक्यूमेंट स्टोर करते हैं। कोई QA इंजीनियर टेस्ट केसों की स्प्रेडशीट को JSON fixture फ़ाइल में बदलता है जिसे कोई टेस्ट रनर इस्तेमाल करता है। हर मामले में सोर्स ऑफ़ ट्रुथ टैबुलर होता है (एक स्प्रेडशीट, डेटाबेस एक्सपोर्ट, CRM डाउनलोड), लेकिन डेस्टिनेशन — एक API, डॉक्यूमेंट स्टोर, टेस्ट हार्नेस — सिर्फ़ JSON स्वीकार करता है, इसलिए एक तेज़, सटीक वन-ऑफ़ कन्वर्जन महीने में एक-दो बार होने वाले काम के लिए पार्सर लिखने से बचा देता है।

CSV किसी भी formal specification से दशकों पहले से मौजूद है — स्प्रेडशीट और मेनफ़्रेम टूल्स 1970 के दशक से ही comma-delimited टेक्स्ट फ़ाइलें लिख रहे थे, हर एक की quoting और line endings को लेकर अपनी अजीबियत के साथ। RFC 4180, जिसे Y. Shafranovich ने 2005 में प्रकाशित किया, आम कन्वेंशन (CRLF line endings, वैकल्पिक डबल-क्वोट रैपिंग, escaping के लिए डबल क्वोट्स) दर्ज करता है लेकिन यह स्पष्ट रूप से informational है, कोई बाध्यकारी standard नहीं। व्यवहार में, "CSV" अब भी अलग-अलग होता है: कुछ यूरोपीय locales में Excel semicolon-delimited फ़ाइलें एक्सपोर्ट करता है क्योंकि वहाँ कॉमा decimal separator होता है, कुछ टूल्स CRLF की जगह सिर्फ़ LF इस्तेमाल करते हैं, और Windows एक्सपोर्ट्स से BOM-prefixed UTF-8 आम है। इसके उलट, JSON के पीछे असली standards हैं — ECMA-404 और RFC 8259 — यही एक वजह है कि यह हर जगह एक जैसा पार्स होता है जबकि CSV parsers को अब भी dialect का अंदाज़ा लगाना पड़ता है।

नहीं — यह एक आम ग़लतफ़हमी है। CSV की rows और columns हमेशा सिर्फ़ फ़्लैट objects की एक फ़्लैट JSON array ही बनाती हैं; CSV में nesting दर्शाने का कोई तरीका नहीं है, इसलिए यह converter (या कोई भी CSV-to-JSON tool) डेटा चाहे जैसे भी व्यवस्थित हो, nested objects या arrays आउटपुट नहीं कर सकता। हर वैल्यू का टाइप भी तय नहीं होता: क्योंकि CSV सब कुछ टेक्स्ट के रूप में स्टोर करता है, "42" का मतलब context के हिसाब से नंबर 42 या स्ट्रिंग "42" हो सकता है, और अलग-अलग tools अलग-अलग नियमों से टाइप का अनुमान लगाते हैं। इस converter के नियम (booleans के लिए true/false, numbers के लिए digit पैटर्न, null के लिए empty/null/n-a) एक उचित डिफ़ॉल्ट सेट हैं, यह कोई गारंटी नहीं कि यह हर दूसरे CSV parser के आउटपुट से मेल खाएगा, जिसमें स्प्रेडशीट सॉफ़्टवेयर का अपना CSV import भी शामिल है।

Header row सीधे JSON की key names देती है, कैरेक्टर-दर-कैरेक्टर, जिसमें स्पेस, punctuation, या emoji भी शामिल हैं अगर आपकी सोर्स फ़ाइल में हों — JSON keys सिर्फ़ strings होती हैं, इसलिए लगभग कुछ भी valid है। एकमात्र अपवाद है पूरी तरह ख़ाली header cell: बिना नाम वाली key बनाने की बजाय, converter row में सेल की पोज़िशन के मुताबिक़ column1, column2 जैसे placeholder पर वापस चला जाता है, ताकि हर वैल्यू आउटपुट object में कहीं न कहीं ज़रूर आए, बस missing लेबल की जगह एक जेनेरिक नाम के साथ। अगर आप साफ़-सुथरे, कोड-फ्रेंडली key names चाहते हैं — बिना स्पेस, consistent केसिंग, बिना ऐसे स्पेशल कैरेक्टर्स के जिनके लिए JavaScript में bracket notation चाहिए — तो पेस्ट करने से पहले अपनी सोर्स स्प्रेडशीट में header row का नाम बदल लेना बेहतर होगा, क्योंकि converter headers को जैसा है वैसा ही मैप करता है, उन्हें normalize या sanitize नहीं करता।