Gratis Markdown Previewer Online
Tulis Markdown di sebelah kiri dan lihat pratinjau yang dirender secara langsung di sebelah kanan. Mendukung heading, bold, italic, blok kode, tabel, daftar, dan lainnya.
Contekan Markdown
## Heading 2 · sub-heading
**bold** · teks tebal
*italic* · teks miring
~~strike~~ ·
`code` · kode inline
 · gambar
- item · daftar tidak berurutan
1. item · daftar berurutan
> quote · blockquote
--- · garis horizontal
Tentang Markdown
Markdown dibuat oleh John Gruber, penulis di balik weblog Daring Fireball, dengan masukan desain substansial dari Aaron Swartz. Rilis publik pertama, versi 1.0, diumumkan di situs Gruber pada 9 Maret 2004; versi 1.0.1, rilis referensi kanonis, mengikuti pada 17 Desember 2004 dan masih merupakan versi yang ditautkan dari daringfireball.net/projects/markdown. Markdown adalah dua hal sekaligus: sintaks pemformatan teks-biasa dan skrip Perl asli yang mengonversi sintaks itu ke HTML. Tujuan yang dinyatakan Gruber adalah bahwa teks sumber harus dapat dibaca apa adanya: dokumen Markdown yang dibuka di editor teks-biasa harus terlihat seperti email yang diformat dengan bijak, bukan sup tag. Batasan keterbacaan itu adalah garis filosofis yang memisahkan Markdown dari format berbasis-XML dan dari markup yang lebih berat seperti LaTeX, dan itu adalah alasan setiap ekstensi kemudian harus berargumen untuk dirinya sendiri dalam hal seberapa buruk itu mengganggu sumber.
Gruber memuji Swartz panjang lebar dalam ucapan terima kasih Markdown: "Aaron Swartz layak mendapat banyak penghargaan untuk masukannya pada desain sintaks pemformatan Markdown." Swartz sebelumnya telah menulis markup ringan terkait yang disebut atx (2002), yang berkontribusi pada gaya heading # dan ## yang sekarang akrab: kadang-kadang masih disebut "atx-style headings" dalam spesifikasi parser. Keterlibatan Swartz adalah bagian dari warisannya yang lebih luas: ia ikut membangun RSS 1.0 sebagai remaja, adalah pemilik bersama di Reddit hingga 2007, dan terus mempengaruhi standar web terbuka hingga kematiannya pada 2013. Trivia yang layak dibetulkan: ekstensi file .md sekarang hampir universal, tetapi alat asli Gruber menggunakan .text: migrasi ke .md adalah konvensi komunitas yang berlaku setelah Markdown meninggalkan ceruk blogging.
Mengapa Markdown Memenangkan Web
Bahasa markup menang dengan diadopsi oleh platform yang menerbitkan sebagian besar teks dunia. Dalam jendela lima tahun yang ketat, Markdown diadopsi oleh platform yang datang untuk mendominasi diskusi long-form, kolaborasi kode, dan dokumentasi pengembang. Stack Overflow diluncurkan pada 15 September 2008 dengan Markdown sebagai sintaks pemformatan untuk pertanyaan, jawaban, dan komentar, menggunakan editor yang disebut WMD (Wysiwym Markdown) oleh John Fraser dari AttackLab; tim Stack Overflow kemudian menulis ulang sebagai editor PageDown sumber-terbuka yang dipelihara di github.com/StackExchange/pagedown. Reddit, didirikan oleh Steve Huffman dan Alexis Ohanian pada 2005 dengan Aaron Swartz bergabung tak lama setelahnya, mengirimkan Markdown untuk komentar tidak lama setelah peluncuran dan membawa sintaks ke audiens yang jauh lebih luas, non-pengembang. GitHub diluncurkan pada 2008 dan dalam setahun merender Markdown di README.md dan komentar issue; pada 2009 mulai mendokumentasikan dan mengirim dialeknya sendiri, GitHub Flavored Markdown. Discord, diluncurkan pada Mei 2015, mengadopsi sintaks chat berasa-Markdown untuk bold, italic, strikethrough, code inline, code fence, dan blockquote: apa yang sebagian besar non-pengembang di bawah 25 sekarang anggap sebagai "meletakkan bintang di sekitar sesuatu." Keterampilan ini menumpuk: penulis yang belajar Markdown sekali dapat menulis pos blog di Jekyll/Hugo/Eleventy, dokumentasi di MkDocs/Docusaurus/Read the Docs, presentasi di Marp dan Reveal.js, catatan di Obsidian/Bear/Logseq/Notion, chat di Slack dan Discord, dan dokumentasi kode sumber di pada dasarnya setiap proyek sumber-terbuka modern.
CommonMark: Memperbaiki Sub-Spesifikasi
Deskripsi sintaks asli Gruber 2004 terkenal tidak formal: dokumen prosa dengan contoh, bukan tata bahasa. Itu meninggalkan puluhan kasus tepi tidak terspesifikasi ("bagaimana penekanan berinteraksi dengan underscore di tengah kata?"; "apakah daftar di dalam blockquote menutup blockquote?"; "apa yang dianggap sebagai daftar tight versus loose?"), dan Gruber tidak pernah merilis parser referensi selain skrip Perl-nya, yang perilakunya idiosinkratik dengan cara yang harus disalin atau ditimpa oleh implementer lain. Hasilnya pada awal 2010-an adalah bahwa GitHub, Reddit, Stack Overflow, Pandoc, dan parser Discount C semua merender sumber Markdown yang sama sedikit berbeda, dan input yang sama dapat rusak di berbagai platform.
Pada 2012, salah satu pendiri Stack Overflow Jeff Atwood (saat itu menjalankan Discourse) dan penulis Pandoc John MacFarlane memulai upaya untuk menulis spesifikasi nyata yang dapat diuji. Mereka bergabung dengan David Greenspan (Meteor), Vicent Marti (GitHub), Neil Williams (Reddit), dan Benjamin Dumke-von der Ehe (Stack Exchange). Proyek ini diluncurkan secara publik pada September 2014 sebagai "Standard Markdown"; dalam beberapa hari Gruber keberatan dengan nama tersebut dalam email pribadi, Atwood menulis pos publik yang menjelaskan perubahan, dan proyek diganti namanya "CommonMark." Rilis bernomor pertama datang pada 25 Oktober 2014. Versi yang diterbitkan saat ini adalah CommonMark 0.31.2, dirilis 28 Januari 2024: "1.0" dijanjikan untuk 2019 dan tidak tiba karena sejumlah kecil kasus tepi patologis (terutama di sekitar parsing penekanan dan embedding HTML) tidak menghasilkan resolusi bulat. Dalam praktik 0.31.2 diperlakukan sebagai stabil-produksi. Spesifikasi CommonMark tidak biasa karena itu sendiri adalah dokumen CommonMark, dengan 600+ kasus uji yang dapat dieksekusi inline; parser mengklaim kesesuaian dengan lulus tes-tes itu.
GitHub Flavored Markdown: Lima Ekstensi di Atas
Spesifikasi GFM formal, diterbitkan pada 2017 dan terbaru bervariasi sebagai 0.29-gfm pada 6 April 2019, mendefinisikan lima ekstensi di atas CommonMark: tabel (blok yang dibatasi-pipe dengan baris pembatas menggunakan tanda hubung dan : untuk perataan per-kolom); item daftar tugas (entri daftar yang dimulai dengan [ ] untuk tidak dicentang atau [x] untuk dicentang, dirender sebagai checkbox HTML yang dinonaktifkan: GitHub juga memungkinkan pengguna yang masuk untuk mengubah ini dengan mengklik, yang merupakan lapisan UX di atas spesifikasi, bukan bagian dari spesifikasi sendiri); strikethrough (membungkus teks dalam ~~ menghasilkan <del>: CommonMark sendiri tidak menentukan ini); ekstensi autolink (URL telanjang dan alamat email dalam teks yang sedang berjalan secara otomatis ditautkan, di mana CommonMark hanya melakukannya untuk autolink kurung-sudut eksplisit); dan HTML mentah yang tidak diizinkan (pembatasan keamanan yang melucuti <script>, <iframe>, <style>, <title>, <plaintext>, <textarea>, <xmp>, <noembed>, <noframes>, dan beberapa tag berbahaya lainnya). Fitur keenam yang umumnya dikaitkan dengan GFM tetapi layak diperlakukan dengan hati-hati adalah blok kode fenced dengan pengidentifikasi bahasa: blok kode fenced adalah bagian dari CommonMark sendiri; petunjuk bahasa setelah fence pembuka juga CommonMark; penyorotan-sintaks yang kemudian diterapkan GitHub berdasarkan petunjuk itu adalah perilaku rendering GitHub, bukan spesifikasi. Renderer GitHub juga menjalankan post-processing tambahan: sanitasi HTML melalui gem html-pipeline di rumah-nya, ekspansi shortcode emoji (:smile:), autolinking @user dan #issue: tidak ada yang ada di GFM sendiri.
Parser Utama
marked.js dibuat oleh Christopher Jeffrey, dengan hak cipta asli tanggal 2011, dan telah dipelihara oleh organisasi GitHub markedjs sejak 2018. Itu adalah desain single-pass, lexer-then-parser yang memprioritaskan kecepatan mentah; dokumen secara eksplisit memposisikannya sebagai "compiler tingkat-rendah untuk parsing markdown tanpa caching atau blocking." Itu adalah parser yang saat ini digunakan previewer ini untuk render langsung. Marked kecil, cepat, dapat diperluas melalui hook token, dan salah satu proyek markdown paling banyak distarred di GitHub (~36k stars).
markdown-it diluncurkan pada 2014 oleh Vitaly Puzrin dan Alex Kocharin. Keduanya sebelumnya telah menyumbangkan hampir semua kode ke parser yang disebut Remarkable; ketika perselisihan kepemimpinan memblokir kemajuan mereka mengorganisir ulang penulisan yang sama di sekitar markdown-it. Proyek mengiklankan kesesuaian CommonMark 100% dengan toggle GFM opsional untuk tabel dan strikethrough, plus ekosistem plugin yang agresif (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor, markdown-it-task-lists, dan beberapa ratus lainnya). Itu adalah parser yang digunakan oleh preview Markdown built-in VS Code, UI web GitLab, dan daftar panjang generator situs statis termasuk Eleventy.
remark / unified.js bukan parser tunggal tetapi framework transformasi pohon. Kolektif unified, dimulai sekitar 2014, mendefinisikan spesifikasi pohon sintaks abstrak yang disebut mdast (Markdown Abstract Syntax Tree); remark mengurai Markdown ke mdast, plugin memanipulasi pohon, dan remark-rehype mengonversi mdast ke hast (AST HTML) untuk emisi. Modelnya lebih lambat dari marked tetapi jauh lebih dapat dikomposisi. Pengguna terkenal termasuk Prettier (yang memformat Markdown menggunakan remark), Gatsby, MDN, pipeline dokumentasi Node.js, dan linter bahasa-inklusif alex. Kolektif unified mencantumkan 312 proyek dan sekitar 6,3 miliar unduhan npm bulanan di semua paketnya.
MDX, pertama kali di-commit pada akhir 2017 oleh John Otander dan lainnya yang terhubung dengan perusahaan alat desain Compositor, diumumkan secara publik di ZEIT Day 2018 dan dirilis 1.0 pada 11 April 2019. MDX menggabungkan konten Markdown dengan komponen JSX, sehingga seorang penulis dapat menjatuhkan <Chart /> atau <Tweet id="123" /> langsung ke prosa. Itu menggerakkan dokumen Next.js, Docusaurus, dan sebagian besar situs dokumentasi berbasis-React. MDX memiliki parser sendiri yang berbeda dari CommonMark; v1 didasarkan pada remark, v2+ menggunakan tata bahasa MDX khusus untuk menangani ekspresi JSX dengan benar di dalam konteks paragraf.
Pandoc: Konverter Universal
Pandoc dirilis oleh John MacFarlane, saat itu profesor filsafat di University of California, Berkeley, pada 10 Agustus 2006. Itu ditulis dalam Haskell, dan desainnya berpusat pada parsing salah satu dari sekitar 30 format input (Markdown, reStructuredText, HTML, LaTeX, DocBook, Textile, markup MediaWiki dan DokuWiki, Org-mode, Microsoft Word .docx, OpenDocument, EPUB, JATS XML, Jupyter .ipynb, dan lainnya) menjadi model dokumen abstrak bersama, kemudian merender model itu menjadi sekitar 40 format output (HTML, PDF melalui LaTeX atau wkhtmltopdf, .docx, .odt, ePub2/3, format slide termasuk Beamer dan reveal.js, dan banyak lagi). Itu di mana-mana dalam penerbitan akademik dan teknis karena membawa kutipan melalui CSL JSON / BibTeX dan menyelesaikannya menjadi referensi yang diformat untuk salah satu dari gaya kutipan utama. Dialek Markdown yang diparsing Pandoc secara default ("Pandoc Markdown") sendiri adalah superset CommonMark dengan ekstensi untuk catatan kaki, daftar definisi, fenced div, matematika (gaya-LaTeX $...$ dan $$...$$), dan caption tabel. Pandoc berlisensi GPL v2-or-later dan adalah apa yang sebagian besar departemen akademik gunakan untuk mengkompilasi manuskrip Markdown menjadi dokumen Word siap-jurnal.
MultiMarkdown, Markdown Extra, dan SmartyPants
Dua dialek ekstensi sebelumnya mendahului CommonMark dan mempengaruhi GFM dan Pandoc. MultiMarkdown dibuat oleh Fletcher T. Penney dengan rilis awal pada Mei 2007 (pekerjaan proyek dimulai 2005-2006), termotivasi oleh penulisan akademik: Penney menginginkan Markdown yang mampu menghasilkan manuskrip yang dapat diterbitkan dengan catatan kaki, kutipan, matematika, daftar definisi, dan metadata dokumen gaya-YAML. MultiMarkdown memperkenalkan atau mempopulerkan tabel karakter-pipe, marker catatan kaki [^id], notasi matematika, blok metadata level-dokumen di bagian atas file, dan caption gambar dan tabel. Markdown Extra dibuat oleh Michel Fortin (penulis PHP Markdown) pada 2005-2006 dan menambahkan tabel pipe, blok kode fenced dengan ~~~ (kemudian juga ```), catatan kaki, daftar definisi, singkatan, dan sintaks atribut {#id .class} untuk heading. Kontribusinya yang paling khas adalah relaksasi aturan Markdown-di-dalam-HTML: atribut markdown="1" yang memungkinkan Anda menyarangkan Markdown di dalam blok HTML. Beberapa pilihan desain CommonMark dan GFM seputar fenced code dan tabel melacak kembali ke Markdown Extra. Secara terpisah, SmartyPants: pendamping tipografi 2002 milik Gruber sendiri: melakukan substitusi tipografi: kutipan ASCII lurus menjadi kutipan keriting, tanda hubung ganda dan triple menjadi en-dash dan em-dash, tiga titik menjadi elipsis sejati. Markdown menangani struktur; SmartyPants menangani polish; banyak parser membundel perilaku gaya-SmartyPants sebagai langkah post-processing (markdown-it-smartypants, remark-smartypants), dan Pandoc memilikinya built-in di balik flag --smart.
Jebakan Umum: Sepuluh Hal yang Menggigit Penulis Baru
Previewer langsung membuat sebagian besar kejutan parsing menjadi jelas segera, tetapi memahami mengapa mereka terjadi membantu penulis mendapatkan sumber yang tepat pertama kali.
- Konversi smart-quote yang merusak sampel kode. Filter gaya-SmartyPants dengan senang hati mengonversi tanda kutip di dalam apa yang terlihat seperti prosa: termasuk, kadang-kadang, di dalam span kode inline atau nilai atribut HTML: meninggalkan Anda dengan markup yang rusak. Sebagian besar parser modern mengecualikan span kode dari substitusi tipografi, tetapi platform blog dengan pipeline custom sering tidak.
- Deteksi marker daftar peka-spasi. Mencampur
-,*, dan+di dalam daftar yang sama, mengindentasi paragraf kelanjutan daftar kurang dari yang dibutuhkan marker, atau meletakkan baris kosong di antara item daftar dapat membalik daftar tight menjadi daftar loose (setiap item dibungkus dalam tag<p>): perbedaan yang tidak terlihat di sumber tetapi dramatis di output. - Autolink yang terlalu bersemangat. Autolinking gaya-GFM mengubah URL telanjang apa pun menjadi tautan, yang biasanya yang Anda inginkan, tetapi juga dapat merusak URL di dalam apa yang seharusnya menjadi span kode, atau URL yang berisi tanda kurung (terutama URL Wikipedia). Aturan untuk "di mana URL ini berakhir?" bervariasi antar parser.
- Petunjuk bahasa code-fence. Teks setelah triple-backtick pembuka:
```jsversus```javascriptversus```tsversus```typescript: adalah petunjuk, bukan spesifikasi. Penyorot sintaks yang berbeda mengenali alias yang berbeda; Highlight.js, Prism, Shiki, dan renderer GitHub masing-masing memiliki kamus bahasa mereka sendiri. - Tabel yang membutuhkan escaping. Karakter pipe di dalam sel tabel harus di-escape sebagai
\|, jika tidak mereka dibaca sebagai pemisah kolom. Menangkap siapa pun yang mencoba meletakkan contoh kode satu-baris di dalam sel tabel. - Hard line break. Di dalam paragraf, baris baru tunggal diperlakukan sebagai spasi dan baris digabungkan; Anda harus meletakkan dua spasi trailing di akhir baris, atau menggunakan backslash, tergantung pada parser. CommonMark mengizinkan keduanya. Beberapa parser yang lebih lama memerlukan
<br>eksplisit. - Markdown dan HTML campuran. Markdown dirancang untuk meneruskan HTML sembarang, sehingga menjatuhkan
<div class="callout">ke file Markdown berfungsi. Tetapi pada saat Anda meletakkan sintaks Markdown di dalam blok HTML, parser menyimpang: CommonMark memperlakukan sebagian besar blok HTML sebagai opaque; Markdown Extra memperkenalkanmarkdown="1"untuk opt-in ke parsing bersarang. - Entitas HTML dan escape karakter. Tanda ampersand
&dalam URL tidak memerlukan escape di dalam tautan Markdown, tetapi&yang sama di luar tautan akan diteruskan ke HTML dan mungkin perlu menjadi&untuk kesesuaian HTML5 yang ketat. Sebagian besar renderer menangani ini secara otomatis; beberapa tidak. - ID heading. GitHub secara otomatis menghasilkan ID fragmen URL dari teks heading menggunakan aturan slugify; banyak parser juga, tetapi algoritma slugify berbeda. Heading yang sama, anchor berbeda di seluruh platform: penyebab abadi tautan intra-dokumen yang rusak ketika konten berpindah antar sistem.
- Spasi trailing dan pengaturan editor. Editor yang melucuti spasi trailing saat menyimpan akan secara diam-diam menghapus sintaks line-break dua-spasi-trailing Markdown. Editor yang mengonversi tab ke spasi (atau sebaliknya) akan merusak blok kode yang bergantung pada indentasi.
Markdown dan Keamanan: XSS dan Sanitasi
Markdown berbahaya dalam satu cara spesifik: setiap parser mainstream meneruskan HTML mentah tidak berubah. Itu berdasarkan desain: itu yang membuat Markdown berguna untuk callout dan embed yang diberi kode-tangan: tetapi itu juga berarti previewer Markdown yang menyuntikkan output parser langsung ke DOM adalah, secara default, vektor XSS. Menempel <img src=x onerror="alert(1)"> ke editor Markdown dan merender output tanpa sanitasi akan mengeksekusi alert. Dua lapisan pertahanan adalah standar. Pertama, konfigurasi level-parser: marked.js, markdown-it, dan remark semua mengekspos opsi untuk menonaktifkan HTML mentah atau meng-escape pada output (markdown-it memiliki html: false secara default; remark/rehype memiliki rehype-sanitize). GFM juga menentukan ekstensi "raw HTML yang tidak diizinkan" yang melucuti daftar elemen berbahaya yang hardcoded. Kedua dan lebih kuat, sanitasi HTML setelah parsing: DOMPurify, ditulis oleh perusahaan keamanan Berlin Cure53 mulai pada Februari 2014, adalah sanitizer JavaScript de facto. Itu mengambil string HTML, mengurai ke DOM, berjalan melalui pohon hanya mengizinkan subset elemen dan atribut yang dapat dikonfigurasi yang aman, dan menserialkan hasilnya. DOMPurify menghapus <script>, memblokir handler event inline, melucuti URL javascript:, dan menangani seratus bypass XSS halus (penyalahgunaan SVG <use>, poliglot atribut MathML) yang akan dilewatkan oleh sanitizer regex naif. Pipeline yang direkomendasikan untuk previewer berbasis-browser apa pun yang menerima HTML mentah adalah: markdownString → parser → htmlString → DOMPurify.sanitize() → innerHTML. CommonMark juga secara eksplisit mensyaratkan parser untuk menolak URI javascript: di autolink; sebagian besar parser memperluas penolakan itu ke semua bentuk tautan.
Markdown vs reStructuredText vs AsciiDoc
Markdown adalah bahasa markup ringan dominan tetapi bukan satu-satunya. reStructuredText (reST) pertama kali dirilis pada Juni 2001 oleh David Goodger sebagai bagian dari Python Doc-SIG, berkembang dari format Zope sebelumnya yang disebut StructuredText. Itu menjadi format dokumentasi resmi Python pada 2002 dan merupakan bahasa input untuk Sphinx, generator dokumentasi di balik hampir semua dokumen proyek Python (dokumen bahasa Python resmi, NumPy, SciPy, Django, Flask, scikit-learn, pandas, dokumentasi kernel Linux sejak 2016, CMake, LLVM). Filosofi desain RST pada dasarnya berlawanan dengan Markdown: itu menerima lebih banyak noise visual di sumber dengan imbalan lebih banyak presisi semantik di output. RST memiliki mekanisme ekstensi built-in melalui "directives" (.. note::, .. code-block:: python) dan "roles" (:func:, :ref:) yang memungkinkan proyek mendefinisikan markup khusus-domain tanpa meninggalkan format. AsciiDoc dibuat pada 2002 oleh Stuart Rackham sebagai alat Python yang dengan sengaja menargetkan semantik DocBook XML: setiap dokumen AsciiDoc memetakan dengan bersih ke DocBook: menjadikannya markup pilihan untuk proyek yang membutuhkan buku berkualitas-publikasi, spesifikasi teknis, dan manual. AsciiDoc adalah apa yang dokumentasi proyek Git ditulis, apa yang O'Reilly Media gunakan untuk banyak bukunya, apa yang Red Hat dan Mozilla gunakan untuk beberapa set dokumentasi produk, dan apa yang GitHub dan GitLab dukung secara native sebagai alternatif README.adoc. Implementasi Python asli telah digantikan oleh Asciidoctor, implementasi Ruby yang dirilis pada 2013. Panduan praktis: pilih Markdown untuk pos blog, README, chat, catatan, dan sebagian besar dokumentasi; reStructuredText untuk dokumentasi Python yang diproses oleh Sphinx; AsciiDoc untuk buku atau spesifikasi long-form yang perlu dirender ke DocBook, PDF, dan EPUB secara bersamaan dengan kesetiaan semantik penuh.
Pertanyaan yang Sering Diajukan
Fitur Markdown apa saja yang didukung?
Previewer ini mendukung heading, bold, italic, tautan, gambar, daftar, blockquote, blok kode, tabel, garis horizontal, dan coret. Mencakup spesifikasi CommonMark ditambah ekstensi umum.
Bisakah saya mengekspor HTML yang dirender?
Anda dapat menyalin hasil render dari panel pratinjau. Untuk HTML mentah, klik kanan pada pratinjau dan gunakan fitur "Inspect" atau "View Source" dari browser Anda untuk menyalin markup yang dihasilkan.
Apakah teks saya disimpan?
Tidak. Semuanya berjalan di browser Anda dan tidak ada yang disimpan atau dikirim ke server. Tutup tab, teks Anda hilang. Salin Markdown Anda sebelum meninggalkan halaman jika ingin menyimpannya.
Apakah teks saya disimpan atau dikirim ke mana pun?
Tidak. Parser Markdown berjalan sepenuhnya di browser Anda melalui JavaScript. Tidak ada yang diunggah, tidak ada API yang dipanggil, tidak ada log yang ditulis. Tutup tab dan teks hilang. Jika Anda ingin menyimpan apa yang Anda tulis, salin sebelum meninggalkan halaman. Anda juga dapat menggunakan halaman offline setelah dimuat sekali: caching service-worker berarti parser tetap tersedia tanpa koneksi internet.
Apakah previewer mensanitasi HTML mentah?
Parser meneruskan HTML mentah, yang merupakan perilaku CommonMark standar: berguna untuk menyematkan blok <div> atau <details> sesekali. Karena input berasal dari sesi browser Anda sendiri dan output hanya dirender di tab Anda sendiri, ini aman untuk kasus penggunaan preview satu-orang yang dibangun untuknya. Jika Anda menerbitkan output di sistem multi-pengguna (CMS, forum, situs dokumentasi yang menerima sumbangan pengguna) Anda harus selalu menjalankan HTML yang dirender melalui sanitizer seperti DOMPurify sebelum menyuntikkannya ke halaman publik: Markdown plus HTML mentah adalah vektor XSS dalam sistem apa pun di mana penulis dan pembaca adalah orang yang berbeda.
Apakah ada batas pada ukuran file?
Tidak ada batas keras. Parser menangani puluhan ribu baris Markdown tanpa masalah pada laptop tipikal. Re-render langsung berjalan pada setiap penekanan tombol, sehingga dokumen yang sangat besar (buku penuh dalam satu file) akan mulai terasa lambat pada perangkat yang lebih lambat. Membagi ke dalam bab, atau menempelkan konten untuk merender sekali dan kemudian mengedit offline, adalah workaround. Halaman tidak akan membekukan browser Anda: marked.js adalah salah satu parser Markdown tercepat yang tersedia.
Alat Terkait
Gratis Kata & Karakter Counter Online
Hitung kata, karakter, kalimat, paragraf, dan perkirakan waktu baca secara instan. Gratis, tanpa pendaftaran, bekerja di browser Anda.
Gratis Lorem Ipsum Generator Online
Hasilkan teks placeholder lorem ipsum berdasarkan paragraf, kalimat, atau kata. Gratis, dapat disesuaikan, tidak perlu pendaftaran.
Pemformat & Validator JSON Gratis Online
Format, minify, dan validasi JSON secara instan. Tempel JSON Anda dan dapatkan keluaran yang diformat dengan pesan kesalahan.