मुफ़्त Markdown प्रीव्यूअर ऑनलाइन

Markdown चीट शीट

Markdown के बारे में

Markdown को John Gruber ने बनाया, जो Daring Fireball weblog के पीछे लेखक हैं, Aaron Swartz से पर्याप्त डिज़ाइन feedback के साथ। पहली सार्वजनिक रिलीज़, संस्करण 1.0, 9 मार्च 2004 को Gruber की साइट पर घोषित की गई; संस्करण 1.0.1, canonical reference रिलीज़, 17 दिसंबर 2004 को आई और अभी भी daringfireball.net/projects/markdown से लिंक की गई संस्करण है। Markdown एक साथ दो चीज़ें हैं: एक plain-text formatting syntax और मूल Perl script जो उस syntax को HTML में परिवर्तित करती है। Gruber का घोषित लक्ष्य यह था कि स्रोत text जैसा है वैसा ही पठनीय हो, एक plain-text editor में खोला गया Markdown document एक सोच-समझ कर formatted email जैसा दिखना चाहिए, tag soup नहीं। यह पठनीयता बाधा वह दार्शनिक रेखा है जो Markdown को XML-आधारित formats और LaTeX जैसी भारी markup से अलग करती है, और यही कारण है कि हर बाद के विस्तार को इस संदर्भ में अपनी पैरवी करनी पड़ी है कि यह स्रोत को कितनी बुरी तरह बाधित करता है।

Gruber Markdown की acknowledgements में Swartz को विस्तार से श्रेय देते हैं: «Aaron Swartz Markdown की formatting syntax के डिज़ाइन पर अपने feedback के लिए जबरदस्त मात्रा में श्रेय के हकदार हैं।» Swartz ने पहले एक संबंधित हल्के markup को atx (2002) नाम से लिखा था, जिसने अब परिचित # और ## heading style का योगदान दिया, कभी-कभी अभी भी parser specs के अंदर «atx-style headings» कहा जाता है। Swartz की भागीदारी उनकी व्यापक विरासत का एक हिस्सा है: उन्होंने किशोर के रूप में RSS 1.0 का सह-निर्माण किया, 2007 तक Reddit के सह-मालिक रहे, और 2013 में अपनी मृत्यु तक खुले web standards को प्रभावित करना जारी रखा। एक trivia जिसे सही पाना उचित है: file extension .md अब लगभग सार्वभौमिक है, लेकिन Gruber का मूल उपकरण .text उपयोग करता था, .md में migration एक सामुदायिक परंपरा थी जो Markdown के blogging niche से बाहर निकलने के बाद कायम हुई।

Markdown ने web क्यों जीता

एक markup language उन platforms द्वारा अपनाई जाने से जीतती है जो दुनिया का अधिकांश text प्रकाशित करते हैं। एक तंग पाँच साल की खिड़की में, Markdown को उन platforms ने अपनाया जो long-form discussion, code collaboration और developer documentation पर हावी हो गए। Stack Overflow 15 सितंबर 2008 को Markdown के साथ प्रश्नों, उत्तरों और टिप्पणियों के लिए formatting syntax के रूप में लॉन्च हुआ, AttackLab के John Fraser द्वारा बनाए गए WMD (Wysiwym Markdown) नामक editor का उपयोग करते हुए; Stack Overflow team ने बाद में इसे open-source PageDown editor के रूप में फिर से लिखा जो github.com/StackExchange/pagedown पर बनाए रखा जाता है। Reddit, 2005 में Steve Huffman और Alexis Ohanian द्वारा स्थापित, Aaron Swartz के थोड़े समय बाद जुड़ने के साथ, लॉन्च के तुरंत बाद टिप्पणियों के लिए Markdown लाया और syntax को बहुत व्यापक, गैर-डेवलपर दर्शकों तक ले गया। GitHub 2008 में लॉन्च हुआ और एक साल के भीतर README.md और issue comments में Markdown render कर रहा था; 2009 में इसने अपनी खुद की बोली, GitHub Flavored Markdown, का दस्तावेज़ीकरण और शिपिंग शुरू किया। Discord, मई 2015 में लॉन्च, ने bold, italic, strikethrough, inline code, code fences और blockquotes के लिए एक Markdown-flavoured chat syntax उठाई, जो अधिकांश 25 से कम के गैर-डेवलपर अब «किसी चीज़ के चारों ओर तारे लगाना» के रूप में सोचते हैं। कौशल बढ़ता है: एक लेखक जो एक बार Markdown सीखता है, Jekyll/Hugo/Eleventy में blog posts, MkDocs/Docusaurus/Read the Docs में documentation, Marp और Reveal.js में presentations, Obsidian/Bear/Logseq/Notion में notes, Slack और Discord में chat, और मूल रूप से हर आधुनिक open-source project में source-code documentation लिख सकता है।

CommonMark, under-specification को ठीक करना

Gruber का 2004 का मूल syntax विवरण कुख्यात रूप से अनौपचारिक था, उदाहरणों के साथ एक prose document, एक grammar नहीं। इसने दर्जनों edge cases को unspecified छोड़ दिया («emphasis किसी शब्द के बीच में underscores के साथ कैसे interact करता है?»; «एक blockquote के अंदर एक list क्या blockquote को बंद करती है?»; «एक tight बनाम loose list के रूप में क्या गिना जाता है?»), और Gruber ने अपनी Perl script के अलावा कोई reference parser कभी जारी नहीं किया, जिसका व्यवहार ऐसे तरीकों से विशिष्ट था कि अन्य implementers को या तो copy करना पड़ा या override करना पड़ा। 2010 के दशक की शुरुआत तक परिणाम यह था कि GitHub, Reddit, Stack Overflow, Pandoc और Discount C parser सभी एक ही Markdown source को थोड़ा अलग तरीके से render करते थे, और एक ही input platforms के बीच टूट सकता था।

2012 में, Stack Overflow के सह-संस्थापक Jeff Atwood (उस समय तक Discourse चला रहे थे) और Pandoc लेखक John MacFarlane ने एक वास्तविक, परीक्षण योग्य specification लिखने का प्रयास शुरू किया। उनके साथ David Greenspan (Meteor), Vicent Marti (GitHub), Neil Williams (Reddit) और Benjamin Dumke-von der Ehe (Stack Exchange) शामिल हुए। यह project सितंबर 2014 में «Standard Markdown» के रूप में सार्वजनिक रूप से लॉन्च हुआ; कुछ ही दिनों में Gruber ने निजी email में नाम पर आपत्ति जताई, Atwood ने परिवर्तन की व्याख्या करते हुए एक सार्वजनिक पोस्ट लिखी, और project का नाम बदलकर «CommonMark» कर दिया गया। पहली numbered release 25 अक्टूबर 2014 को आई। वर्तमान प्रकाशित संस्करण CommonMark 0.31.2 है, 28 जनवरी 2024 को जारी, एक «1.0» 2019 के लिए वादा किया गया था और नहीं आया है क्योंकि कुछ pathological edge cases (विशेष रूप से emphasis parsing और HTML embedding के आसपास) ने सर्वसम्मत संकल्प नहीं उत्पन्न किए हैं। व्यवहार में 0.31.2 को production-stable माना जाता है। CommonMark spec असामान्य है क्योंकि यह स्वयं एक CommonMark document है, 600+ executable test cases inline के साथ; एक parser उन परीक्षणों को पास करके अनुपालन का दावा करता है।

GitHub Flavored Markdown, ऊपर पाँच विस्तार

औपचारिक GFM specification, 2017 में प्रकाशित और हाल ही में 6 अप्रैल 2019 को 0.29-gfm के रूप में version किया गया, CommonMark के ऊपर पाँच विस्तार परिभाषित करता है: tables (pipe-delimited blocks dashes और प्रति-column alignment के लिए : का उपयोग करते हुए एक delimiter row के साथ); task list items (list entries जो uncheck के लिए [ ] या check के लिए [x] से शुरू होती हैं, disabled HTML checkboxes के रूप में render होती हैं, GitHub अतिरिक्त रूप से logged-in users को इन्हें clicking द्वारा toggle करने देता है, जो spec के ऊपर एक UX layer है, स्वयं spec का हिस्सा नहीं); strikethrough (text को ~~ में लपेटना <del> उत्पन्न करता है, CommonMark स्वयं इसे specify नहीं करता); autolinks extension (running text में नंगी URLs और email पते स्वतः-लिंक होते हैं, जहाँ CommonMark केवल explicit angle-bracket autolinks के लिए ऐसा करता है); और disallowed raw HTML (एक सुरक्षा प्रतिबंध जो <script>, <iframe>, <style>, <title>, <plaintext>, <textarea>, <xmp>, <noembed>, <noframes> और कुछ अन्य खतरनाक tags हटाता है)। एक छठी सुविधा जो आमतौर पर GFM के लिए जिम्मेदार ठहराई जाती है लेकिन सावधानी से व्यवहार करने योग्य है, वह है language identifiers के साथ fenced code blocks: fenced code blocks स्वयं CommonMark का हिस्सा हैं; opening fence के बाद language hint भी CommonMark है; उस hint के आधार पर GitHub जो syntax-highlighting लागू करता है वह GitHub का rendering व्यवहार है, spec नहीं। GitHub का renderer अतिरिक्त post-processing भी चलाता है, अपने in-house html-pipeline gem के माध्यम से HTML sanitization, emoji shortcode विस्तार (:smile:), @user और #issue autolinking, जिनमें से कोई भी GFM में नहीं हैं।

प्रमुख parsers

marked.js को Christopher Jeffrey ने बनाया, मूल copyright 2011 का है, और 2018 से markedjs GitHub संगठन द्वारा रखरखाव किया गया है। यह एक single-pass, lexer-then-parser design है जो raw speed को प्राथमिकता देता है; docs इसे स्पष्ट रूप से «low-level compiler for parsing markdown without caching or blocking» के रूप में रखते हैं। यह parser है जिसका यह previewer वर्तमान में live render के लिए उपयोग करता है। Marked छोटा, तेज़, token hooks के माध्यम से विस्तार योग्य है, और GitHub पर सबसे अधिक starred markdown projects में से एक (~36k stars)।

markdown-it 2014 में Vitaly Puzrin और Alex Kocharin द्वारा लॉन्च किया गया। दोनों ने पहले Remarkable नामक एक parser में लगभग सारा code योगदान दिया था; जब leadership विवादों ने प्रगति को अवरुद्ध कर दिया तो उन्होंने उसी authorship को markdown-it के चारों ओर पुनर्संगठित किया। Project tables और strikethrough के लिए वैकल्पिक GFM toggles के साथ 100% CommonMark अनुपालन का विज्ञापन करता है, साथ ही एक आक्रामक plugin ecosystem (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor, markdown-it-task-lists और कई सौ अन्य)। यह VS Code की built-in Markdown preview, GitLab की web UI, और Eleventy सहित static-site generators की एक लंबी सूची द्वारा उपयोग किया जाने वाला parser है।

remark / unified.js एक एकल parser नहीं है बल्कि एक tree-transformation framework है। Unified collective, लगभग 2014 में शुरू हुआ, mdast (Markdown Abstract Syntax Tree) नामक एक abstract syntax tree spec परिभाषित करता है; remark Markdown को mdast में parse करता है, plugins tree को manipulate करते हैं, और remark-rehype mdast को emission के लिए hast (HTML AST) में परिवर्तित करता है। Model marked की तुलना में धीमा है लेकिन व्यापक रूप से अधिक composable। उल्लेखनीय users में Prettier (जो remark का उपयोग करके Markdown format करता है), Gatsby, MDN, Node.js documentation pipeline, और alex inclusive-language linter शामिल हैं। Unified collective अपने सभी packages में 312 projects और लगभग 6.3 बिलियन मासिक npm downloads सूचीबद्ध करता है।

MDX, पहली बार 2017 के अंत में John Otander और Compositor design tools company से जुड़े अन्य लोगों द्वारा committed, ZEIT Day 2018 में सार्वजनिक रूप से घोषित किया गया था और 11 अप्रैल 2019 को 1.0 shipped किया। MDX Markdown content को JSX components के साथ जोड़ता है, इसलिए एक लेखक prose में सीधे एक <Chart /> या <Tweet id="123" /> छोड़ सकता है। यह Next.js docs, Docusaurus और अधिकांश React-आधारित documentation sites को शक्ति प्रदान करता है। MDX का CommonMark से अलग अपना parser है; v1 remark पर आधारित था, v2+ paragraph context के अंदर JSX expressions को सही ढंग से संभालने के लिए एक समर्पित MDX grammar का उपयोग करता है।

Pandoc, सार्वभौमिक converter

Pandoc को John MacFarlane ने जारी किया, तब University of California, Berkeley में दर्शनशास्त्र के professor थे, 10 अगस्त 2006 को। यह Haskell में लिखा गया है, और इसका डिज़ाइन लगभग 30 input formats (Markdown, reStructuredText, HTML, LaTeX, DocBook, Textile, MediaWiki और DokuWiki markup, Org-mode, Microsoft Word .docx, OpenDocument, EPUB, JATS XML, Jupyter .ipynb और अन्य) को एक साझा abstract document model में parse करने पर केंद्रित है, फिर उस model को लगभग 40 output formats (HTML, LaTeX या wkhtmltopdf के माध्यम से PDF, .docx, .odt, ePub2/3, Beamer और reveal.js सहित slide formats, और कई अन्य) में render करता है। यह academic और technical publishing में सर्वव्यापी है क्योंकि यह CSL JSON / BibTeX के माध्यम से citations ले जाता है और उन्हें किसी भी प्रमुख citation styles के लिए formatted references में हल करता है। Markdown बोली जिसे Pandoc default रूप से parse करता है («Pandoc Markdown») स्वयं footnotes, definition lists, fenced divs, math (LaTeX-style $...$ और $$...$$) और table captions के लिए विस्तार के साथ एक CommonMark superset है। Pandoc GPL v2-or-later के तहत licensed है और यह वह है जिसका उपयोग अधिकांश academic departments Markdown manuscripts को journal-ready Word documents में compile करने के लिए करते हैं।

MultiMarkdown, Markdown Extra और SmartyPants

दो पहले के विस्तार बोलियाँ CommonMark से पहले की हैं और GFM और Pandoc दोनों को प्रभावित किया। MultiMarkdown को Fletcher T. Penney ने मई 2007 में प्रारंभिक रिलीज़ के साथ बनाया (project कार्य 2005-2006 में शुरू हुआ), academic लेखन से प्रेरित, Penney चाहते थे कि Markdown footnotes, citations, mathematics, definition lists और YAML-style document metadata के साथ एक प्रकाशन योग्य manuscript उत्पन्न करने में सक्षम हो। MultiMarkdown ने pipe-character tables, [^id] footnote markers, math notation, files के शीर्ष पर document-level metadata blocks, और image और table captions को पेश या लोकप्रिय किया। Markdown Extra को Michel Fortin (PHP Markdown लेखक) द्वारा 2005-2006 में बनाया गया और pipe tables, ~~~ (बाद में ``` भी) के साथ fenced code blocks, footnotes, definition lists, abbreviations, और headings के लिए {#id .class} attribute syntax जोड़ी। इसका सबसे विशिष्ट योगदान Markdown-inside-HTML नियमों की छूट थी, markdown="1" attribute जो आपको HTML block के अंदर Markdown nest करने देता है। fenced code और tables के आसपास कई CommonMark और GFM design choices Markdown Extra तक वापस जाते हैं। अलग से, SmartyPants: Gruber का अपना 2002 का typography साथी, typographic substitutions करता है: सीधे ASCII quotes curly quotes बन जाते हैं, double और triple hyphens en- और em-dashes बन जाते हैं, तीन periods एक सच्चा ellipsis बन जाते हैं। Markdown structure संभालता है; SmartyPants polish संभालता है; कई parsers SmartyPants-style व्यवहार को एक post-processing step के रूप में bundle करते हैं (markdown-it-smartypants, remark-smartypants), और Pandoc ने इसे एक --smart flag के पीछे built in किया है।

सामान्य pitfalls, दस चीज़ें जो नए लेखकों को काटती हैं

एक live previewer अधिकांश parsing आश्चर्यों को तुरंत स्पष्ट करता है, लेकिन यह समझना कि वे क्यों होते हैं, एक लेखक को पहली बार में स्रोत सही करने में मदद करता है।

1. Smart-quote रूपांतरण जो code samples तोड़ता है। SmartyPants-style filters खुशी से उन quotes को convert करते हैं जो prose की तरह दिखते हैं (कभी-कभी inline code spans या HTML attribute values के अंदर सहित) आपको टूटी markup के साथ छोड़ देते हैं। अधिकांश modern parsers code spans को typographic substitution से बाहर करते हैं, लेकिन custom pipelines वाले blog platforms अक्सर नहीं करते।
2. List-marker detection whitespace-संवेदनशील है। एक ही list के अंदर -, * और + मिलाना, marker की आवश्यकता से कम list continuation paragraphs indent करना, या list items के बीच एक blank line रखना एक tight list को loose list (प्रत्येक item <p> tags में लिपटा) में पलट सकता है, स्रोत में अदृश्य लेकिन output में नाटकीय अंतर।
3. Autolink अति-उत्साह। GFM-style autolinking किसी भी नंगी URL को link में बदल देती है, जो आमतौर पर वही है जो आप चाहते हैं, लेकिन यह उन URLs को भी विकृत कर सकती है जो code span होनी चाहिए थीं, या parentheses वाली URLs (विशेष रूप से Wikipedia URLs)। «यह URL कहाँ समाप्त होती है?» का नियम parsers के बीच भिन्न होता है।
4. Code-fence language hints। Opening triple-backtick के बाद text, ```js बनाम ```javascript बनाम ```ts बनाम ```typescript: एक संकेत है, spec नहीं। विभिन्न syntax highlighters विभिन्न aliases को पहचानते हैं; Highlight.js, Prism, Shiki और GitHub renderer प्रत्येक के अपने language dictionaries हैं।
5. Tables जिन्हें escaping की आवश्यकता है। Table cells के अंदर pipe characters को \| के रूप में escape किया जाना चाहिए, अन्यथा उन्हें column separators के रूप में पढ़ा जाता है। यह किसी को भी पकड़ता है जो table cell के अंदर एक-line code उदाहरण रखने की कोशिश करता है।
6. Hard line breaks। एक paragraph के अंदर, एक single newline को whitespace के रूप में माना जाता है और lines जुड़ जाती हैं; आपको line के अंत में दो trailing spaces रखने होंगे, या एक backslash उपयोग करना होगा, parser के आधार पर। CommonMark दोनों की अनुमति देता है। कुछ पुराने parsers एक स्पष्ट <br> की आवश्यकता रखते हैं।
7. मिश्रित Markdown और HTML। Markdown को मनमाना HTML through pass करने के लिए डिज़ाइन किया गया था, इसलिए एक Markdown file में <div class="callout"> छोड़ना काम करता है। लेकिन जिस क्षण आप एक HTML block के अंदर Markdown syntax डालते हैं, parsers विचलित होते हैं: CommonMark अधिकांश HTML blocks को opaque मानता है; Markdown Extra ने nested parsing में opt in करने के लिए markdown="1" पेश किया।
8. HTML entities और character escapes। एक URL में एक ampersand & को Markdown link के अंदर escaping की आवश्यकता नहीं है, लेकिन वही & link के बाहर HTML तक pass किया जाएगा और सख्त HTML5 अनुपालन के लिए & होने की आवश्यकता हो सकती है। अधिकांश renderers इसे स्वचालित रूप से संभालते हैं; कुछ नहीं।
9. Heading IDs। GitHub heading text से एक slugify नियम का उपयोग करके URL fragment IDs को स्वतः-उत्पन्न करता है; कई parsers भी ऐसा करते हैं, लेकिन slugify algorithms भिन्न होते हैं। एक ही heading, platforms के बीच भिन्न anchor, content systems के बीच जाने पर टूटे intra-document links का एक बारहमासी कारण।
10. Trailing whitespace और editor settings। Editors जो save पर trailing whitespace strip करते हैं, Markdown के two-trailing-spaces line-break syntax को चुपचाप delete कर देंगे। Editors जो tabs को spaces में convert करते हैं (या इसके विपरीत), indentation पर निर्भर code blocks को तोड़ देंगे।

Markdown और सुरक्षा, XSS और sanitization

Markdown एक विशिष्ट तरीके से खतरनाक है: हर mainstream parser raw HTML को बिना बदलाव के through pass करता है। यह design से है (यही Markdown को हाथ से कोडित callouts और embeds के लिए उपयोगी बनाता है) लेकिन इसका मतलब यह भी है कि एक Markdown previewer जो parser output को सीधे DOM में inject करता है, default रूप से, एक XSS vector है। एक Markdown editor में <img src=x onerror="alert(1)"> paste करना और बिना sanitization के output render करना alert को execute करेगा। दो रक्षा परतें मानक हैं। पहला, parser-level configuration: marked.js, markdown-it और remark सभी raw HTML को disable करने या output पर escape करने के लिए options उजागर करते हैं (markdown-it में default रूप से html: false है; remark/rehype में rehype-sanitize है)। GFM अतिरिक्त रूप से «disallowed raw HTML» extension specify करता है जो खतरनाक elements की एक hard-coded सूची strip करता है। दूसरा और अधिक मजबूत, parsing के बाद HTML sanitization: DOMPurify, फरवरी 2014 से शुरू होकर बर्लिन सुरक्षा फर्म Cure53 द्वारा लिखित, de facto JavaScript sanitizer है। यह एक HTML string लेता है, इसे एक DOM में parse करता है, tree को elements और attributes के एक configurable safe subset को अनुमति देते हुए चलता है, और result को serialize करता है। DOMPurify <script> हटाता है, inline event handlers ब्लॉक करता है, javascript: URLs strip करता है, और सौ सूक्ष्म XSS bypasses (SVG <use> दुरुपयोग, MathML attribute polyglots) को संभालता है जिन्हें एक भोला regex sanitizer चूक जाएगा। raw HTML स्वीकार करने वाले किसी भी browser-आधारित previewer के लिए अनुशंसित pipeline है: markdownString → parser → htmlString → DOMPurify.sanitize() → innerHTML। CommonMark स्पष्ट रूप से parsers को autolinks में javascript: URIs अस्वीकार करने की आवश्यकता भी रखता है; अधिकांश parsers उस अस्वीकृति को सभी link रूपों तक बढ़ाते हैं।

Markdown vs reStructuredText vs AsciiDoc

Markdown प्रमुख हल्की markup language है लेकिन एकमात्र नहीं। reStructuredText (reST) जून 2001 में पहली बार David Goodger द्वारा Python Doc-SIG के हिस्से के रूप में जारी किया गया, StructuredText नामक एक पहले Zope format से विकसित। यह 2002 में Python का आधिकारिक documentation format बन गया और Sphinx के लिए input language है, documentation generator जो लगभग सभी Python project docs के पीछे है (आधिकारिक Python language docs, NumPy, SciPy, Django, Flask, scikit-learn, pandas, 2016 से Linux kernel documentation, CMake, LLVM)। RST का design दर्शन अनिवार्य रूप से Markdown के विपरीत है: यह output में अधिक semantic precision के बदले स्रोत में अधिक दृश्य noise स्वीकार करता है। RST में «directives» (.. note::, .. code-block:: python) और «roles» (:func:, :ref:) के माध्यम से एक built-in extension mechanism है जो एक project को format छोड़े बिना domain-specific markup परिभाषित करने देता है। AsciiDoc को 2002 में Stuart Rackham ने एक Python tool के रूप में बनाया जो जानबूझकर DocBook XML semantics को लक्षित करता है (हर AsciiDoc document साफ-सुथरा DocBook में map होता है) इसे उन projects के लिए पसंद की markup बनाता है जिन्हें publication-quality books, technical specifications और manuals की आवश्यकता है। AsciiDoc वह है जिसमें Git project का documentation लिखा गया है, जिसका O’Reilly Media अपनी कई किताबों के लिए उपयोग करता है, जिसका Red Hat और Mozilla कई product documentation sets के लिए उपयोग करते हैं, और जिसे GitHub और GitLab एक README.adoc विकल्प के रूप में नेटिव रूप से support करते हैं। मूल Python implementation को Asciidoctor द्वारा बदल दिया गया है, 2013 में जारी एक Ruby implementation। व्यावहारिक मार्गदर्शन: blog posts, READMEs, chat, notes और अधिकांश documentation के लिए Markdown चुनें; Sphinx द्वारा संसाधित Python documentation के लिए reStructuredText; long-form books या specifications के लिए AsciiDoc जिन्हें पूर्ण semantic fidelity के साथ एक साथ DocBook, PDF और EPUB में render करने की आवश्यकता है।

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

कौन-कौन सी Markdown सुविधाएँ समर्थित हैं?

यह प्रीव्यूअर हेडिंग्स, बोल्ड, इटैलिक, लिंक, छवियाँ, सूचियाँ, ब्लॉककोट, कोड ब्लॉक, टेबल, क्षैतिज रेखाएँ और स्ट्राइकथ्रू को समर्थन करता है। यह CommonMark स्पेक और सामान्य एक्सटेंशन्स को कवर करता है।

क्या मैं रेंडर किए गए HTML को निर्यात कर सकता हूँ?

आप प्रीव्यू पैनल से रेंडर किया गया आउटपुट कॉपी कर सकते हैं। कच्चे HTML के लिए, प्रीव्यू पर राइट-क्लिक करें और उत्पन्न मार्कअप कॉपी करने के लिए अपने ब्राउज़र की "Inspect" या "View Source" सुविधा का उपयोग करें।

क्या मेरा टेक्स्ट सहेजा जाता है?

नहीं। सब कुछ आपके ब्राउज़र में चलता है और कुछ भी संग्रहीत या सर्वर पर नहीं भेजा जाता। टैब बंद करें और आपका टेक्स्ट चला जाता है। यदि आप सहेजना चाहते हैं तो जाने से पहले अपना Markdown कॉपी करें।

क्या मेरा text कहीं save या भेजा जाता है?

नहीं। Markdown parser JavaScript के माध्यम से पूरी तरह से आपके browser में चलता है। कुछ भी अपलोड नहीं होता, कोई API कॉल नहीं की जाती, कोई logs नहीं लिखे जाते। tab बंद करें और text चला गया। यदि आप जो लिखा है उसे रखना चाहते हैं, तो page छोड़ने से पहले उसकी प्रतिलिपि बनाएं। आप page को offline भी उपयोग कर सकते हैं एक बार जब यह load हो गया है, service-worker caching का मतलब है कि parser internet कनेक्शन के बिना उपलब्ध रहता है।

क्या previewer raw HTML को sanitize करता है?

Parser raw HTML को through pass करता है, जो standard CommonMark व्यवहार है, कभी-कभार <div> या <details> block embedding के लिए उपयोगी। क्योंकि input आपके अपने browser session से आता है और output केवल आपके अपने tab में render होता है, यह एक-व्यक्ति preview उपयोग के मामले के लिए सुरक्षित है जिसके लिए इसे बनाया गया है। यदि आप output को एक multi-user system (एक CMS, एक forum, एक documentation site जो user submissions स्वीकार करती है) पर प्रकाशित कर रहे हैं तो आपको हमेशा rendered HTML को एक sanitizer जैसे DOMPurify के माध्यम से चलाना चाहिए इससे पहले कि आप इसे एक सार्वजनिक page में inject करें, Markdown plus raw HTML किसी भी system में एक XSS vector है जहाँ लेखक और पाठक भिन्न लोग हैं।

क्या file size पर सीमाएँ हैं?

कोई कठोर सीमा नहीं। Parser एक विशिष्ट laptop पर बिना किसी समस्या के Markdown की हजारों lines को संभालता है। Live re-render हर keystroke पर चलता है, इसलिए बहुत बड़े documents (एक ही file में एक पूरी किताब) धीमी devices पर सुस्त लगने लगेंगे। अध्यायों में विभाजन, या एक बार render करने के लिए content paste करना और फिर offline editing, समाधान है। Page आपके browser को freeze नहीं करेगा, marked.js उपलब्ध सबसे तेज़ Markdown parsers में से एक है।

संबंधित उपकरण