Markdown से HTML कन्वर्टर
लाइव पूर्वावलोकन के साथ Markdown सिंटैक्स को साफ़ HTML कोड में कनवर्ट करें।
लाइव पूर्वावलोकन
समर्थित Markdown सिंटैक्स
शीर्षक: # H1, ## H2, ### H3, आदि।
ज़ोर: *इटैलिक*, **बोल्ड**, ***बोल्ड इटैलिक***, ~~स्ट्राइक~~
लिंक: [टेक्स्ट](url)
छवियाँ: 
कोड: `इनलाइन कोड` और ``` के साथ बाड़दार कोड ब्लॉक
सूचियाँ: - अक्रमबद्ध आइटम, 1. क्रमबद्ध आइटम
उद्धरण: > उद्धृत टेक्स्ट
क्षैतिज विभाजक: --- या ***
इस कनवर्टर का उपयोग कैसे करें
- अपना Markdown पेस्ट करें। उपकरण CommonMark प्लस सबसे आम GFM एक्सटेंशन स्वीकार करता है, टेबल, भाषा संकेतों के साथ बंद कोड, स्ट्राइकथ्रू, ऑटोलिंक और टास्क लिस्ट आइटम।
- लाइव रूपांतरण देखें। दायाँ पैनल आपके टाइप करते समय कच्चा HTML आउटपुट दिखाता है; नीचे का पूर्वावलोकन पैनल इसे दृष्टि से प्रस्तुत करता है।
- HTML कॉपी करें। Copy HTML बटन का उपयोग करके अपने CMS, ईमेल क्लाइंट, स्थैतिक-साइट जनरेटर टेम्पलेट या HTML स्वीकार करने वाले किसी भी अन्य स्थान पर पेस्ट करने के लिए तैयार आउटपुट प्राप्त करें।
Markdown का एक संक्षिप्त इतिहास
Markdown को Daring Fireball वेबलॉग के पीछे के लेखक John Gruber ने Aaron Swartz से पर्याप्त डिज़ाइन फ़ीडबैक के साथ बनाया था। पहली सार्वजनिक रिलीज़, संस्करण 1.0, Gruber की साइट पर 9 मार्च 2004 को घोषित की गई थी; संस्करण 1.0.1, विहित संदर्भ रिलीज़, 17 दिसंबर 2004 को आया और अभी भी daringfireball.net/projects/markdown से जुड़ा संस्करण है। Markdown शुरुआत से ही दो चीज़ें एक साथ थीं: एक सादा-पाठ फ़ॉर्मेटिंग सिंटैक्स और मूल Perl स्क्रिप्ट जो इसे HTML में बदलती थी। Gruber का घोषित लक्ष्य था कि स्रोत पाठ जैसा है वैसा पठनीय होना चाहिए, सादा-पाठ संपादक में खोला गया Markdown दस्तावेज़ एक सोच-समझकर फ़ॉर्मेट किए गए ईमेल जैसा दिखना चाहिए, टैग सूप नहीं। वह पठनीयता की बाधा वह दार्शनिक रेखा है जो Markdown को XML-आधारित प्रारूपों और LaTeX जैसे भारी मार्कअप से अलग करती है, और यही कारण है कि हर बाद के एक्सटेंशन को अपने लिए तर्क देना पड़ा है कि यह स्रोत को कितनी बुरी तरह बाधित करता है। Aaron Swartz ने पहले atx (2002) नामक एक संबंधित हल्के मार्कअप को लिखा था, जिसने अब-परिचित # और ## हेडिंग शैली में योगदान दिया, कभी-कभी पार्सर स्पेक्स के अंदर अभी भी "atx-शैली के हेडिंग" कहलाते हैं।
CommonMark, अंडर-स्पेसिफिकेशन को ठीक करना
Gruber का 2004 का मूल सिंटैक्स विवरण प्रसिद्ध रूप से अनौपचारिक था, उदाहरणों के साथ एक गद्य दस्तावेज़, व्याकरण नहीं। इसने दर्जनों किनारे के मामलों को असंगत छोड़ दिया, और Gruber ने अपनी Perl स्क्रिप्ट के अलावा कभी संदर्भ पार्सर जारी नहीं किया, जिसका व्यवहार ऐसा अद्वितीय था कि अन्य कार्यान्वयनकर्ताओं को या तो कॉपी करना पड़ा या ओवरराइड करना पड़ा। 2010 के दशक की शुरुआत तक परिणाम यह था कि GitHub, Reddit, Stack Overflow, Pandoc और Discount C पार्सर सभी एक ही Markdown स्रोत को थोड़ा अलग तरीक़े से प्रस्तुत करते थे। 2012 में, Stack Overflow सह-संस्थापक Jeff Atwood और Pandoc लेखक John MacFarlane ने एक वास्तविक, परीक्षण योग्य विनिर्देश लिखने का प्रयास शुरू किया। परियोजना सितंबर 2014 में "Standard Markdown" के रूप में सार्वजनिक रूप से शुरू हुई; कुछ दिनों के भीतर Gruber ने निजी ईमेल में नाम पर आपत्ति जताई, Atwood ने परिवर्तन की व्याख्या करते हुए एक सार्वजनिक पोस्ट लिखा, और परियोजना का नाम बदलकर "CommonMark" कर दिया गया। पहली संख्यांकित रिलीज़ 25 अक्टूबर 2014 को आई। वर्तमान प्रकाशित संस्करण CommonMark 0.31.2, 28 जनवरी 2024 को जारी है। CommonMark स्पेक असामान्य है कि यह स्वयं एक CommonMark दस्तावेज़ है, इनलाइन 600+ निष्पादन योग्य परीक्षण मामलों के साथ; एक पार्सर उन परीक्षणों को पास करके अनुरूपता का दावा करता है। GitHub Flavored Markdown (GFM), 6 अप्रैल 2019 की औपचारिक स्पेक संस्करण 0.29-gfm, CommonMark के ऊपर पाँच एक्सटेंशन को परिभाषित करती है: टेबल, टास्क लिस्ट आइटम, स्ट्राइकथ्रू, बेयर URL के लिए ऑटोलिंक, और प्रतिबंधित कच्चा HTML (एक सुरक्षा प्रतिबंध जो लेखक-प्रदत्त HTML से खतरनाक टैग हटाता है)।
प्रमुख पार्सर
marked.js को 2011 में Christopher Jeffrey द्वारा बनाया गया था और 2018 से markedjs GitHub संगठन द्वारा बनाए रखा गया है, एक एकल-पास, लेक्सर-फिर-पार्सर डिज़ाइन जो कच्ची गति को प्राथमिकता देता है; ~36k सितारे और GitHub पर सबसे अधिक स्टार वाली Markdown परियोजना। यह वह पार्सर है जिसे यह उपकरण रूपांतरण के लिए उपयोग करता है। markdown-it 2014 में Vitaly Puzrin और Alex Kocharin द्वारा लॉन्च किया गया था, वैकल्पिक GFM टॉगल के साथ 100% CommonMark अनुरूपता का विज्ञापन करता है और एक आक्रामक प्लगइन पारिस्थितिकी तंत्र (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor और कई सौ अन्य)। यह VS Code के अंतर्निहित Markdown पूर्वावलोकन, GitLab के वेब UI और Eleventy द्वारा उपयोग किया गया पार्सर है। remark / unified.js एकल पार्सर नहीं है बल्कि एक पेड़-परिवर्तन फ्रेमवर्क है, unified सामूहिक mdast (Markdown AST) नामक एक अमूर्त सिंटैक्स ट्री स्पेक को परिभाषित करता है; remark Markdown को mdast में पार्स करता है, प्लगइन ट्री में हेरफेर करते हैं, और remark-rehype mdast को hast (HTML AST) में परिवर्तित करता है। marked की तुलना में धीमा लेकिन बहुत अधिक संरचना योग्य; उल्लेखनीय उपयोगकर्ताओं में Prettier, Gatsby, MDN और alex समावेशी-भाषा लिंटर शामिल हैं। Pandoc, 10 अगस्त 2006 को John MacFarlane द्वारा जारी, सार्वभौमिक दस्तावेज़ कनवर्टर है, Haskell में लिखा गया, लगभग 30 इनपुट प्रारूपों को पार्स करता है, लगभग 40 आउटपुट प्रारूपों में प्रस्तुत करता है; शैक्षणिक और तकनीकी प्रकाशन में सर्वव्यापी।
MD-से-HTML पाइपलाइन, यांत्रिक रूप से
एक Markdown पार्सर आमतौर पर दो पास में काम करता है। ब्लॉक-स्तरीय पार्सिंग इनपुट को ब्लॉक संरचनाओं में विभाजित करता है, अनुच्छेद, हेडिंग, सूचियाँ, कोड फेंस, ब्लॉक उद्धरण, क्षैतिज नियम, टेबल। ब्लॉक सीमाएँ खाली लाइनों और इंडेंटेशन द्वारा निर्धारित होती हैं; उन्हें सही पाना वही है जो CommonMark पार्सर को सही बनाता है। इनलाइन पार्सिंग फिर प्रत्येक ब्लॉक की सामग्री को चलाता है और इनलाइन सिंटैक्स से मेल खाता है: ज़ोर (*तिरछा*, **मोटा**), लिंक ([पाठ](url)), इनलाइन कोड स्पैन (`कोड`), छवियाँ (), स्ट्राइकथ्रू (GFM में ~~पाठ~~), और स्पष्ट ऑटोलिंक (<https://example.com>)। इनलाइन ज़ोर पार्सिंग किसी भी Markdown स्पेक का सबसे कठिन हिस्सा है, CommonMark स्पेक के कई पन्ने और दर्जनों परीक्षण मामले इस बात को निर्दिष्ट करने के लिए समर्पित करता है कि *foo*bar* कब <em>foo</em>bar* बनाम *foo<em>bar</em> उत्पन्न करना चाहिए। पार्सर फिर प्रत्येक टोकन को संबंधित HTML तत्व के रूप में प्रस्तुत करता है और परिणामों को संयोजित करता है। सुंदर मुद्रण, इंडेंटेशन और कोड-ब्लॉक सिंटैक्स हाइलाइटिंग रेंडरिंग विकल्पों द्वारा शीर्ष पर परतबद्ध होते हैं।
पहले स्थान पर MD को HTML में क्यों परिवर्तित करें?
- CMS आयात। कई हेडलेस CMS (Contentful, Sanity, Wagtail, Ghost) HTML स्वीकार करते हैं लेकिन Markdown नहीं। Markdown में मसौदा तैयार करना और प्रकाशन समय पर एक बार परिवर्तित करना संपादन अनुभव को सुखद रखता है।
- ईमेल रचना। ईमेल क्लाइंट HTML प्रस्तुत करते हैं; अधिकांश Markdown प्रस्तुत नहीं करते। न्यूज़लेटर प्लेटफ़ॉर्म (Mailchimp, ConvertKit, Substack) आमतौर पर अपने संपादक में पेस्ट किए गए HTML को स्वीकार करते हैं। अपने मसौदे को परिवर्तित करें, पेस्ट करें, भेजें।
- ब्लॉग पोस्ट के मसौदे। Markdown प्लगइन के बिना कुछ विरासत WordPress इंस्टॉल को पोस्ट बॉडी में HTML की आवश्यकता होती है; कुछ Shopify और Webflow शॉप पेज अपने रिच-टेक्स्ट फ़ील्ड में HTML लेते हैं।
- स्थैतिक-साइट जनरेटर स्निपेट। जब आपको Hugo शॉर्टकोड, Eleventy टेम्पलेट या Next.js MDX फ़ाइल के लिए इनलाइन HTML चंक की आवश्यकता हो, तो Markdown को एकल HTML टुकड़े में परिवर्तित करना SSG के अपने रूपांतरण पाइपलाइन से लड़ने की तुलना में तेज़ है।
- प्रस्तुत नोट साझा करना। Slack, Notion, Linear, ClickUp या अन्य रिच-टेक्स्ट गंतव्यों में "प्रस्तुत" Markdown पेस्ट करना कभी-कभी कच्चे Markdown के बजाय क्लिपबोर्ड पर HTML चाहता है।
- दस्तावेज़ीकरण संग्रहीत करना। Markdown स्रोत के साथ-साथ प्रस्तुत HTML को संग्रहीत करने का मतलब है कि आपका संग्रह बिना पार्सर के ब्राउज़र में मानव-पठनीय है, दीर्घकालिक संरक्षण के लिए उपयोगी।
जानने योग्य आउटपुट विकल्प
विभिन्न डाउनस्ट्रीम उपयोग रूपांतरित HTML से अलग चीज़ें चाहते हैं। पूर्ण दस्तावेज़ बनाम टुकड़ा। एक पूर्ण HTML दस्तावेज़ में <!DOCTYPE html>, <html>, मेटाडेटा के साथ <head>, और एक <body> रैपर शामिल है, उपयुक्त जब आप फ़ाइल को .html के रूप में सहेजेंगे और ब्राउज़र में खोलेंगे। एक टुकड़ा केवल बॉडी सामग्री है, कोई रैपर नहीं, उपयुक्त जब आप उस CMS फ़ील्ड में पेस्ट करेंगे जो पहले से ही दस्तावेज़ संरचना प्रदान करता है। यह उपकरण डिफ़ॉल्ट रूप से टुकड़े उत्सर्जित करता है; यदि आपको पूर्ण दस्तावेज़ की आवश्यकता है तो अपने स्वयं के बॉयलरप्लेट के साथ लपेटें। स्वच्छता। डिफ़ॉल्ट रूप से Markdown पार्सर कच्चे HTML को अपरिवर्तित पास करते हैं, इसलिए यदि आपके स्रोत में <script>alert(1)</script> है, तो वह स्क्रिप्ट टैग आउटपुट में दिखाई देगा। मल्टी-यूज़र सिस्टम में जाने वाले दस्तावेज़ों के लिए, DOM में इंजेक्ट करने से पहले DOMPurify (Cure53, फ़रवरी 2014 में शुरू) के माध्यम से आउटपुट चलाएँ। एक बार के व्यक्तिगत उपयोग के लिए, कच्चा आउटपुट ठीक है। हेडर ID। हेडिंग पर id विशेषताएँ उत्पन्न करना (हेडिंग टेक्स्ट से slugified) आपको एंकर लिंक के साथ सामग्री की तालिका बनाने देता है। सटीक slug एल्गोरिथम प्लेटफ़ॉर्मों के बीच भिन्न होता है, GitHub एक नियम का उपयोग करता है, MkDocs दूसरा, marked.js तीसरा, इसलिए एंकर लिंक तब टूट सकते हैं जब सामग्री सिस्टम के बीच चलती है। हार्ड लाइन ब्रेक। CommonMark को <br> को बाध्य करने के लिए या तो लाइन के अंत में दो ट्रेलिंग स्पेस या एक बैकस्लैश की आवश्यकता है; कुछ प्लेटफ़ॉर्म (Discord, GitHub इश्यू) एकल न्यूलाइन को ब्रेक के रूप में मानते हैं। चुनाव आपके स्रोत की अपेक्षित शैली पर निर्भर करता है।
सामान्य चेतावनियाँ
- स्मार्ट-कोट रूपांतरण। कुछ पार्सर (या Gruber के अपने SmartyPants जैसी पोस्ट-प्रोसेसिंग परतें) डिफ़ॉल्ट रूप से सीधे उद्धरणों को घुमावदार टाइपोग्राफ़िक उद्धरणों से बदल देते हैं। यदि आपको सीधे उद्धरण संरक्षित करने की आवश्यकता है (क्योंकि आपके आउटपुट को कोड के रूप में पार्स किया जा रहा है), तो जाँचें कि यह परिवर्तन बंद है।
- लिस्ट-मार्कर व्हाइटस्पेस संवेदनशीलता। एक ही सूची में
-और*और+को मिलाना, लिस्ट-कंटिन्यूएशन अनुच्छेदों को मार्कर की आवश्यकता से कम इंडेंट करना, या सूची आइटम के बीच एक खाली लाइन डालना तंग सूची को ढीली सूची में बदल सकता है (प्रत्येक आइटम<p>टैग में लपेटा जाता है)। आउटपुट में दृश्य अंतर नाटकीय है। - ऑटोलिंक की अति-उत्साह। GFM-शैली ऑटोलिंकिंग किसी भी बेयर URL को लिंक में बदल देती है, जो आम तौर पर वही है जो आप चाहते हैं, लेकिन कोष्ठक वाले URL (विशेष रूप से विकिपीडिया URL) या ट्रेलिंग विराम चिह्न को विकृत कर सकता है।
- टेबल जिन्हें एस्केप की आवश्यकता है। टेबल कोशिकाओं के अंदर पाइप वर्णों को
\|के रूप में एस्केप किया जाना चाहिए, अन्यथा उन्हें कॉलम विभाजक के रूप में पढ़ा जाता है। किसी भी व्यक्ति को पकड़ता है जो एक-लाइन कोड उदाहरण को कोशिका के अंदर डालने की कोशिश कर रहा है। - मिश्रित Markdown और HTML। Markdown को मनमाने HTML को पास करने के लिए डिज़ाइन किया गया था, इसलिए Markdown फ़ाइल में
<div class="callout">छोड़ना काम करता है। लेकिन जिस क्षण आप HTML ब्लॉक के अंदर Markdown सिंटैक्स डालते हैं, पार्सर अलग हो जाते हैं: CommonMark अधिकांश HTML ब्लॉकों को अपारदर्शी मानता है; Markdown Extra ने नेस्टेड पार्सिंग में चुनने के लिएmarkdown="1"पेश किया। - प्लेटफ़ॉर्मों में हेडिंग ID। विभिन्न slugify एल्गोरिदम एक ही हेडिंग के लिए अलग एंकर टुकड़े उत्पन्न करते हैं; जब सामग्री सिस्टम के बीच चलती है तो दस्तावेज़ के भीतर लिंक टूट सकते हैं।
यह उपकरण बनाम Markdown पूर्वावलोकनकर्ता
Absolutool दो संबंधित उपकरण भेजता है जो एक ही पार्सर पर ओवरलैप करते हैं। Markdown पूर्वावलोकनकर्ता लाइव संपादन के लिए है, बाईं ओर Markdown लिखें, दाईं ओर प्रस्तुत दृश्य आउटपुट देखें, "HTML आउटपुट" की कोई अवधारणा नहीं। यह Markdown-से-HTML कनवर्टर एक-बार के रूपांतरण के लिए है, Markdown पेस्ट करें, कच्चा HTML कॉपी करें, अपने CMS या ईमेल क्लाइंट में पेस्ट करें। जब आप मसौदा तैयार कर रहे हों और दृश्य प्रतिक्रिया की आवश्यकता हो तो पूर्वावलोकनकर्ता का उपयोग करें; जब आपके पास तैयार Markdown हो और HTML की आवश्यकता हो जिसे आप कहीं और ले जा सकें तो इस कनवर्टर का उपयोग करें। दोनों उपकरण हुड के तहत marked.js का उपयोग करते हैं और समान CommonMark + GFM बोली स्वीकार करते हैं, इसलिए उनके बीच रूपांतरण व्यवहार समान है।
गोपनीयता: क्यों केवल-ब्राउज़र यहाँ मायने रखता है
अप्रकाशित लेखन के मसौदे, प्रगति में ब्लॉग पोस्ट, आंतरिक दस्तावेज़ीकरण, NDA के तहत क्लाइंट डिलिवरेबल्स, पांडुलिपि अध्याय, शैक्षिक पेपर, ठीक उसी तरह का पाठ हैं जिसे आप तीसरे पक्ष की सेवा पर अपलोड नहीं करना चाहते। सर्वर-साइड Markdown कनवर्टर पूरे दस्तावेज़ को रिमोट एंडपॉइंट पर भेजने की आवश्यकता है, जिसका अर्थ है कि यह सर्वर के लॉग में बैठता है, संभवतः CDN कैश में, संभवतः एनालिटिक्स पाइपलाइन में, संभवतः बैकअप में। प्रकाशित पाठ के लिए मुद्दा निरर्थक है। मसौदा कार्य के लिए, वास्तुकला मायने रखती है। यह उपकरण JavaScript और marked.js के माध्यम से आपके ब्राउज़र में पूरी पाइपलाइन चलाता है। Markdown कभी नेटवर्क पार नहीं करता है, टाइप करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पेज को ऑफ़लाइन (हवाई जहाज मोड) ले जाएँ और पुष्टि करें कि कनवर्टर अभी भी काम करता है। गोपनीय मसौदों, क्लाइंट डिलिवरेबल्स, NDA के तहत पांडुलिपि अध्यायों, आंतरिक मेमो या किसी भी अन्य चीज़ के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं करना चाहेंगे।
अक्सर पूछे जाने वाले प्रश्न
यह कनवर्टर किस Markdown बोली का समर्थन करता है?
CommonMark सबसे आम GFM एक्सटेंशन सक्षम के साथ, टेबल (वैकल्पिक : संरेखण के साथ पाइप-सीमांकित), भाषा संकेतों के साथ बंद कोड ब्लॉक, ~~पाठ~~ के माध्यम से स्ट्राइकथ्रू, बेयर URL के लिए ऑटोलिंक, और [ ] और [x] के माध्यम से टास्क लिस्ट आइटम। हेडिंग, बोल्ड, इटैलिक, लिंक, छवियाँ, सूचियाँ, ब्लॉक उद्धरण, क्षैतिज नियम और इनलाइन कोड सभी वैसे काम करते हैं जैसा आप GitHub पर अपेक्षा करेंगे। रेंडरर marked.js है, वही पार्सर जिसे Markdown पूर्वावलोकनकर्ता उपयोग करता है।
क्या यह GitHub Flavored Markdown (GFM) का समर्थन करता है?
हाँ, पाइप के साथ टेबल, भाषा संकेतों के साथ बंद कोड ब्लॉक, टास्क लिस्ट, ऑटोलिंक और स्ट्राइकथ्रू सभी काम करते हैं। यदि GFM एक्सटेंशन रेंडर नहीं हो रहा है, तो दोबारा जाँचें कि इनपुट CommonMark/GFM सिंटैक्स नियमों का पालन करता है: ब्लॉक तत्वों के चारों ओर खाली लाइनें, बंद कोड ब्लॉक पर मिलान बैकटिक गिनती, हार्ड लाइन ब्रेक के लिए ठीक दो ट्रेलिंग स्पेस (या एक बैकस्लैश)। "GFM काम नहीं कर रहा है" का सबसे आम कारण एक संपादक है जो सहेजने पर ट्रेलिंग व्हाइटस्पेस को हटाता है, जो हार्ड-ब्रेक सिंटैक्स को मार देता है।
क्या आउटपुट GitHub पर समान दिखेगा?
संरचनात्मक HTML, अनुच्छेद, सूचियाँ, टेबल, हेडिंग, किसी भी इनपुट के लिए मेल खाएगा जो वैध CommonMark + GFM है। दो परतें अलग होंगी। GitHub अपना खुद का CSS थीम और सिंटैक्स-हाइलाइटिंग लागू करता है, इसलिए रंग, फ़ॉन्ट और रिक्ति अलग दिखेंगी। GitHub स्पेक के ऊपर पोस्ट-प्रोसेसिंग भी डालता है, इमोजी शॉर्टकोड (:smile:), @user उल्लेख, #issue ऑटो-लिंकिंग, रिपॉजिटरी-सापेक्ष छवि पथ, जो कोई स्पेक-अनुपालन कनवर्टर पुनरुत्पादित नहीं करता है। यह उपकरण जो HTML उत्सर्जित करता है वह संरचनात्मक रूप से पोर्टेबल है; दृश्य रूप गंतव्य में CSS पर निर्भर करता है।
क्या मुझे प्रकाशन से पहले आउटपुट को साफ करना चाहिए?
यदि स्रोत में उपयोगकर्ता द्वारा प्रदान की गई सामग्री शामिल हो सकती है, तो हाँ। Markdown पार्सर कच्चे HTML को अपरिवर्तित पास करते हैं, इसलिए <img src=x onerror="alert(1)"> वाला स्रोत आउटपुट में वह टैग उत्पन्न करेगा। मल्टी-यूज़र सिस्टम के लिए, DOM में इंजेक्ट करने से पहले DOMPurify (Cure53, फ़रवरी 2014, वास्तविक JavaScript सैनिटाइज़र) के माध्यम से आउटपुट चलाएँ। एक-बार के व्यक्तिगत उपयोग के लिए जहाँ स्रोत आपका अपना लेखन है, यह मुद्दा नहीं है, सबसे बुरा जो आप अपने पेज को कर सकते हैं वह अपना खुद का HTML पेस्ट करना है।
क्या मुझे head और body के साथ पूर्ण HTML दस्तावेज़ मिल सकता है?
वर्तमान में यह उपकरण केवल बॉडी टुकड़ा उत्सर्जित करता है, परिवर्तित Markdown सिमेंटिक HTML टैग में लपेटा गया लेकिन पूर्ण <html>/<head>/<body> दस्तावेज़ में नहीं। एक स्टैंडअलोन .html फ़ाइल के रूप में सहेजने के लिए, आउटपुट को स्वयं लपेटें: <!DOCTYPE html><html><head><meta charset="utf-8"><title>...</title></head><body>[टुकड़ा]</body></html>। या टेम्पलेट-संचालित CSS के साथ पूरी तरह से स्टैंडअलोन आउटपुट के लिए --standalone ध्वज के साथ Pandoc का उपयोग करें।
क्या मेरा Markdown कहीं भेजा जाता है?
नहीं। रूपांतरण marked.js के माध्यम से आपके ब्राउज़र में पूरी तरह से चलता है। आप जो Markdown पेस्ट करते हैं वह कभी नेटवर्क पार नहीं करता है, टाइप करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पेज को ऑफ़लाइन (हवाई जहाज मोड) ले जाएँ और पुष्टि करें कि कनवर्टर अभी भी काम करता है। गोपनीय मसौदों, NDA के तहत क्लाइंट डिलिवरेबल्स, पांडुलिपि अध्यायों या किसी भी पाठ के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं करना चाहेंगे।