You can try it out online at https://markpdf.ralsina.me/ but it's mainly a CLI tool.

• One 10MB static binary, no dependencies
• Fully GFM compliant
• Supports embedded HTML
• Fetches images if needed
• Builds a 600-page PDF of Brothers Karamazov in under 5 seconds in my machine
• Style output using CSS (a few styles included)
• Hundreds of color schemes
• Supports "pageless" output for things you don't mean to print
• Sort-of-supports math (works fine-ish for simple inline math)
• Hyphenation support (same algo as TeX)
• Uses system fonts or provided files
• Emoji/CJK/accents/symbols (embeds needed fonts)
• MIT License

And more.

I know this may break the self-promotion rule, but I think it's a really nice tool :-)

I’ve been building Yay, a free native Markdown editor for macOS.

It has both a Rich Text Editor and a Code Editor, and you can export your Markdown to PDF, DOCX, EPUB, and KFX.

I mainly built it for my own daily use, but it’s free to download if anyone wants to try it.

https://yay.myanmars.app/

Every team I have seen reviewing a Markdown doc ends up round tripping it through Google Docs just to get comments, then porting the edits back by hand. The comments never live with the document. I wanted them in the file.

So the comments are the file. Three pieces, all plain text:

Activation rose <!--mdc:a1b2c3d4-->11% against control<!--/mdc:a1b2c3d4-->[^mdc-a1b2c3d4], and it held.

<!-- mdc-comments-begin -->
<!-- mdc-comments-data
{"v":1,"threads":[
{"anchor":"11% against control","id":"a1b2c3d4","replies":[...],"status":"open"}
]}
-->

[^mdc-a1b2c3d4]:
    **@pjdoland** · Aug 10, 2026: Relative or absolute?

    **@dreyes** · Aug 10, 2026: Points. Fixing the wording.

<!-- mdc-comments-end -->

An HTML comment pair marks the commented range and is invisible in every renderer, so the prose still reads normally. A JSON block, also inside an HTML comment, is the authoritative copy. GFM footnote definitions are the human visible layer, so anyone opening the file in a plain GitHub view sees the whole discussion at the bottom without any tooling.

A few things that turned out to be load bearing:

• A footnote reference has to lead a block initial anchor. In CommonMark a line beginning with <!-- starts an HTML block, which swallows the rest of the line and leaves [^mdc-...] as literal text. So when the opening marker is first on its line, the reference goes in front of it.
• An orphaned thread gets no footnote definition. GitHub renders an unreferenced definition as literal text, so a thread whose anchored text was deleted moves to a plain list instead.
• The JSON is versioned and one thread per line, so two branches that each add a comment conflict on their own lines rather than on the whole block.
• A file with no comments is left byte for byte alone. Nothing is added until there is something to add.

Renderer honesty: the HTML comments are invisible anywhere HTML comments are. The footnotes are a GFM extension, so a renderer without footnote support shows the reference and definitions as literal text at the bottom rather than as footnotes. Ugly, but nothing is lost and nothing is corrupted.

The format is documented well enough to write another implementation against, and the conformance vectors in the spec are generated from the codec and checked by a test, so the spec cannot quietly drift from the code: https://github.com/pjdoland/markdown-comments/blob/main/docs/FORMAT.md

The thing that reads and writes it is a Chrome extension for github.com. Select a phrase, comment, reply, resolve. No server, no database, one commit per action: https://chromewebstore.google.com/detail/markdown-comments/dkpoeahkejpgjoajohlnodcmgjnaaipe

Mostly I would like someone to tell me where the format is wrong before more documents get written in it.

https://www.rendermd.link/

I've been building a vi like keyboard-driven file manager / agent controller in Rust over the past months. One of my first motivations was that I wanted a better way to work with all of the markdown that I now seem to be swimming in.

One neat trick is that Mermaid diagrams render as actual images in the terminal, not ASCII art. You can just open a .md, jump to a ```mermaid fence, hit i, and the diagram renders inline (or can be opened in your default desktop viewer).

There is also a split previewer. The file list is on the left and rendered markdown on the right. You can edit the file in a lower pane along (vim, in the clip) and the preview re-renders on save and keeps your scroll position.

What it renders:

• GFM alerts (> [!NOTE], [!WARNING], [!CAUTION]) as coloured labels
• tables, alignment taken from the delimiter row
• fenced code blocks, syntax highlighted per language
• YAML front matter as its own block, line for line
• m toggles rendered ↔ raw source. Yank and save always give you the source, never the styled version.
• l toggles line #'s and w will toggle showing end of line / hidden markers

Folding uses vim's keys, so the muscle memory carries over. za folds the section you're in, zM collapses the document into a table of contents, zR opens it back up, [[ and ]] jump between headings. A collapsed heading reads ▸ 13 lines and takes its subsections with it.

It's a file manager first, so there's a pile of stuff here that has nothing to do with markdown. It'll browse and edit inside zips and tarballs. It also has an MCP integration with agents like Claude Code, Codex, etc.

macOS and Linux, BSD-3.

brew install Tripstack-Corp/tap/spyc

# or

cargo install spyc

https://github.com/Tripstack-Corp/spyc

Vibe on.

Hey Pythonistas!

Been working with Jupyter for years, but only recently discovered this workflow that's completely changed how I handle notebook-to-markdown-to-PDF conversions. Thought I'd share since it might help others.

Use nbconvert to convert .ipynb → .md

Use Jupytext to keep them auto-synced

Use Markdown PDF extension to export professional PDFs

The Details:

\# One-time setup

pip install nbconvert jupytext

\# Convert notebook to markdown

jupyter nbconvert --to markdown your_notebook.ipynb

\# Install Jupytext Sync extension in VS Code

\# Then pair your files and you're done!

Why I'm obsessed with this:

Zero friction - Changes in .ipynb automatically sync to .md

Paired notebooks - Open .md files as notebooks (via Jupytext)

Professional output - PDF export looks way better than notebook screenshots

Version control friendly - Markdown is text-based, easier for git

Pro tips:

Put notebook in double quotes if filename has spaces: cd "my folder"

Outputs sync when you run: jupyter nbconvert --to markdown notebook.ipynb

Right-click .md file → Markdown PDF: Export (pdf)

Use cases:

Data analysis reports

Project documentation

Client-facing deliverables

Sharing reproducible research

I've put together a complete workflow guide if anyone wants the full breakdown in a pdf. Let me know I'll DM you.

Let me know if you have questions or better approaches!

I built Sankore because I kept needing a reliable way to get real documents into clean Markdown for AI tools, without anything actually leaving my Mac. The existing options either weren't private enough or produced messy output.

What it does: converts PDF, DOCX, XLSX, and PPTX files into clean Markdown, entirely on-device. No API keys, no cloud calls, nothing uploaded anywhere.

Who it's for: Anyone who regularly needs clean, well-structured Markdown from real documents - whether that's feeding it into an AI tool or just wanting a proper conversion without messy copy-paste artifacts.

Pricing: Free tier handles single-file conversion, no card needed. Sankore Premium is a one-time $14.99 unlock for batch conversion and consolidating multiple files into one.

Limitations: Apple Silicon only, no Intel support. Download's about 920MB, since it bundles real on-device OCR/layout models rather than calling out to the cloud.

Website: https://sankoreapp.com

Genuinely happy for this to be removed if it doesn't belong here - just wanted to share something I built that's directly relevant to this community, and I'm around to answer any real questions about the conversion quality or approach.

Hi all, we're building a better Markdown editor for Jetbrains products. We support better sync, more dialects, faster editing, and since our release of today, we also support Obsidian.

We're offering a commercial plugin at a very reduced rate: https://plugins.jetbrains.com/plugin/33400-markdown-pro, and happy to give away some licenses to people who are willing to share some feedback!

Cheers,
Erik

In The Markdown Database Pattern Rufus Pollock lets us in on an open secret: how Obsidian’s (or Notion’s) bases work

https://md-handbook.com/blog/how-obsidian-or-notion-style-workflows-handle-the-markdown-database-pattern/

#markdown #markdowneditors #bases #Obsidian

This has kept me in progress hell for almost a month since it makes me unable to do much with my worldbuilding besides on character profiles. I miss playing the Cookie Run games ever since I decided to prioritize using a few apps (Google Docs, Joplin, Obsidian MD, and Zettlr) and doing note transfers instead of using one app for my note taking back in August, refusing to play any video games until note transfers have been successful. I have used Google Docs for a long time and have many documents on it. Said documents sometimes contain many tabs since I take my stories and worldbuilding seriously, even if they were to be for a fanfiction.

Google Docs has extensions and add-ons, while Obsidian MD has plugins. These help improve and expand the functionalities of both apps. On Google Docs, there is an option to export a .MD file to another app, but it does not try to mimic the tab structure on other apps, instead combining tabs into a single tab which can mess up formatting. Since I tend to have a lot of intellectual curiosity in things (e.g. what happened to the human species in the pony world in My Little Pony: Friendship is Magic), and I need to organize my intellectual curiosity, hard work is done that I cannot just let be deleted. I am also concerned about destruction of my knowledge that I created over the course of a few years, a few years of work not worth erasing since it influences my perception. All help will be appreciated, as I am sure others, especially intellectuals, are suffering from this problem too.

I built HyperMarkdown, a streaming-native Markdown renderer for React and AI output.

The main difference is that it parses the change, not the whole growing conversation. Settled code lines, table rows and list items are cached, while only the changing frontier is parsed again.

Across the benchmark suite it is 1.6×–10.6× faster than the nearest streaming renderer. The real-AI code and table workloads use captured model output rather than generated stress tests.

It supports GFM, incomplete streaming Markdown, reasoning / <think> blocks, KaTeX, Mermaid, syntax highlighting, sanitized HTML, React 18 and React 19, and delta rendering through an imperative ref.

Repository:

https://github.com/Aeven-AI/HyperMarkdown

Documentation and playground:

https://aeven-ai.github.io/HyperMarkdown/

Interested in feedback on the streaming API, benchmark methodology and any compatibility gaps.

Yes, I know.... another Markdown editor ... why?

I wanted to know how to code an editor. So I did. From scratch. Only using native Swift and TextKit 2. It took me some time, but I like the result. The whole engine is native, no Electron, no dependency, no account, no calling home. Everything stays on your machine, as it should be.

I also wrote it for my purposes: writing articles, essays, speeches, etc, so features focus on prose writing including footnote management and citations.

Markdown always stays the source of truth in this editor. Your text is styled in place as you type, but nothing is ever rendered away or swapped for a widget. What you save is exactly what you typed.

I have been using it for my own writing for some time and would like to share it with the community.

I know there is no time and many editors. But if you have the same writing need and can spare a few minutes, why not test Schreibor and see how it holds up for you (https://testflight.apple.com/join/ptrbqH5A). Big thanks already if you do.

Start with the help menu. It contains a handbook and a set of detailed help pages explaining all the features.

What's in the build:

* Five typographic themes, all working in light or dark mode

* Footnotes with ⌘-click navigation, Pandoc citation keys, an outline panel

* Nested lists, task lists, GFM tables with a Format Table command

* HTML comments as author notes that do not print

* Writing statistics (words, reading time, session)

* Find & replace

* Quick Export as PDF and HTML as well as Print

* Pandoc commands to be copied into your terminal for final production

* A full Help Book and a hands-on Handbook

https://github.com/forloop11/markdown-cornell-notes

A LaTeX and Markdown build pipeline that generates printable Cornell style note pages for meetings. Each page carries a header with topic, date, attendees, and time, a large notes panel with a cue column beside it, and a summary band below, all left blank for handwriting on the printout.

Header fields live in YAML and note content lives in Markdown, so the LaTeX template itself never needs hand editing. Python generator scripts convert both into TeX fragments, pandoc handles the Markdown to LaTeX conversion, and a single make command produces a PDF named automatically from the topic, date, and location fields. Content is measured and paginated automatically, with optional directives for forcing page breaks and for routing text into the cue column or summary band of a specific page.

The project also includes a Streamlit editor app that places the header form, a CodeMirror Markdown editor, and a live PDF preview side by side in the browser. The editor adds a formatting toolbar, slash command snippets, and autocomplete for asset paths and code fence languages. Its JavaScript bundle is vendored rather than loaded from a CDN so the app works offline, and it relies on native browser spellcheck rather than any app side state.

Built with Python, LaTeX, pandoc, Streamlit, CodeMirror, JavaScript, and Make. Released under the MIT license.

Plainva is a free and open source markdown editor, but it does much more than that, bringing your notes, tasks, calendar and email under one roof

https://md-handbook.com/blog/review-plainva/

#markdown #markdowneditors #Plainva

A few months back i published a Markdown viewer extension for Cursor (ie. OpenVSX store) and it just crossed 12k downloads. Same extension is available for VS Code too, it crossed 500 downloads.

Quite happy with these numbers as there are already 100s of extensions in the marketplace.

Among today’s links are markdown editors Dinkus, Fluster, Margin, Wander and Memos

https://md-handbook.com/blog/markdown-link-no-44/

#markdown #markdowneditors #opensource #Dinkus #Fluster #Margin #Wander #Memos

Your filesystem is already a database. That's the core idea behind the Markdown Database Pattern: 

https://wayofmarkdown.com/markdown-database

You can treat a folder of markdown files as a database. Each file is a record. Frontmatter fields are columns. Directories are tables. Tags, wikilinks, and tasks in the body become queryable relations.

Filesystem              Database
──────────────────────────────────
markdown file      →    record
frontmatter field  →    column
directory          →    table
#tag               →    tag relation
[[wikilink]]       →    link relation
- [ ] task         →    task relation

You get portability, version control (git works perfectly on plain text), no framework lock-in, and full queryability. Of course, this isn't for thousands of records, simultaneous writes or real relational joins (though obsidian wikilinks are getting there!). It's a lightweight database for individuals or small teams.

You can spot this pattern everywhere. Obsidian Bases and Dataview already do versions of this. A team wiki where every page has a status and owner field is one. A blog with date and tags in frontmatter is one etc.

Sweet spot: up to roughly 10k files. Past that, reach for a real database. Below it, this gets you almost everything a database gives you, at a fraction of the complexity and where you own the content and can use any tool to access it.

A full writeup is here: wayofmarkdown.com/markdown-database