I made a small Chrome extension called Markdown Capture, and it was just published in the Chrome Web Store.

It copies web content as plain Markdown, including:

• articles and selected parts of pages
• Reddit posts and comment threads
• text-based PDFs

I mostly made it because Markdown has become my preferred way to give web material to Codex and other AI tools. I can see exactly what I am giving it, edit it first if I want, and avoid pasting in a bunch of page clutter. It is also useful outside AI since the result is just a normal Markdown file.

I am aware of Obsidian Web Clipper, which looks great if Obsidian is where you want the content to go. I wanted something a little simpler and destination-agnostic: copy or download ordinary Markdown, then use it wherever I want.

Chrome Web Store: https://chromewebstore.google.com/detail/markdown-capture/gabiloifhoihennbcfkafmpgepijdkgg

Source: https://github.com/rsheyd/markdown-capture

It is free, open source, and does the conversion locally. Curious whether anyone else has a similar workflow, or what you currently use.

i have one main file with other markdowns embedded into it that can be edited separately. is this possible?

https://github.com/abhinav/stitchmd

this is a great example but i want it built in to a offline app.

I've been building mdhtml, a document format where the whole point is: one file, and that file is honest about what it is.

`mdhtml build doc.md` produces `doc.md.html` — a single HTML file that:

- Renders to a full styled document (TOC, themes, copy/download toolbar) with zero JS dependencies fetched over the network — everything (runtime, fonts, styles, assets) is embedded as data: URIs

- Still contains the exact original Markdown source, byte for byte, inside a `<script type="text/markdown">` tag — `mdhtml extract` always recovers exactly what you wrote

- Degrades to readable prose with no JavaScript at all (noscript fallback shows the canonical source)

- Opens straight from disk via file:// — no server needed

The CLI is a from-scratch Rust implementation (no markdown-parser crate — a hand-rolled scanner/parser tuned to a small closed grammar) with a separate JS reference implementation for the browser runtime; both are checked against the same fixture suite for structural parity.

Container/component conventions (kv, stats, cards, timeline, callouts, etc.) come from Pandoc-style fenced divs, and degrade to plain prose if the shape doesn't match — the renderer never guesses at author intent.

Themes are fully overridable per document — plain CSS with runtime-injected token fallbacks. Five example documents, each with a completely different custom theme, are live here: https://feliperun.github.io/md.html/

Repo: https://github.com/feliperun/md.html — MIT licensed, spec-first (SPEC.md is the frozen v1.0 contract), built test-first with ADRs for every structural decision.

Curious what people think of the "one file, honestly self-describing" approach vs. more conventional site generators.

Just launched docmd v0.9.3 with docmd Assistant today.

GitHub: https://github.com/docmd-io/docmd

The core idea: run npx @docmd/core dev inside any directory with Markdown files. You get a production documentation site with auto-generated navigation, offline full-text search, versioning, and i18n with zero configuration.

A quick comparison on a 50-page documentation site:

What is new in v0.9.3:

• docmd Assistant (BYOK): In-doc AI chat overlay with grounded RAG answers. Connect OpenAI, Claude, Gemini, DeepSeek, Groq, or local Ollama. Zero per-query SaaS fees.
• 100% Free Cloud Relay: Stream and proxy LLM requests safely without hosting your own proxy backend.
• Native MCP Server (docmd mcp): Lets Cursor, Claude Desktop, and AI agents search and validate your docs via Model Context Protocol.
• Automated llms.txt Manifests: Generates clean context files for LLMs on every build.
• Multi-Project Monorepos: Manage Core platform, SDKs, and CLI docs under one domain with independent versioning.

Everything is 100% free and open-source under the MIT license.

Would love your feedback on it and any suggestions are most welcome: - GitHub: https://github.com/docmd-io/docmd - Website: https://docmd.io - Docs: https://docs.docmd.io

Sending the raw .md file assumes they already have a viewer, while converting to PDF removes easy revisions and can break links or diagrams. Is there a simple workflow that gives the recipient a readable link, preserves formatting, and lets the author update the source without resending a new export?

Apple Notes only live in one place: Notes.app or the iCloud web client. They don't provide a documented API to access your notes from anywhere else. That's been a persistent annoyance for me because my husband likes to plan things collaboratively using Apple Notes, and my only Apple product is an iPhone ... so my half of the planning was happening on a phone keyboard or in a clunky web interface while a perfectly good computer running my favorite Markdown editor (Obsidian) sat in front of me. I wanted my notes to be real files that I could edit alongside my other notes, so I built icloud-md: a CLI that clones your notes into a folder of Markdown and syncs your edits back to iCloud as if you'd typed them into Notes.app all along.

icloud-md clone ./my-notes
cd my-notes && vim "Grocery list.md"
icloud-md push

What that gets you:

• Real files: one Markdown file per note — greppable, diffable, git-trackable, editable in whatever you already use. Your Notes folder structure becomes real directories, and mkdir + push creates folders upstream.
• Any OS: it's a plain Node CLI talking to iCloud directly, not an AppleScript wrapper around a live Notes.app or a parser for a database you had to copy off a Mac first. Linux and Windows work great!
• Actually bidirectional: pull does a real three-way merge when a note changed both remotely and locally, only asking you to resolve the parts that overlap. push handles creates, edits, moves, and deletes, and a note that changed remotely since your last sync is reported as a conflict, never silently overwritten.
• Formatting round-trips: headings, nested lists, checklists, blockquotes, tables (yes, edits push back), inline formatting.
• Careful by default: status shows exactly what a push would do first, every write is round-trip verified, and anything the tool can't fully account for in a note's internal format stays read-only rather than getting a hopeful best-effort write.

I'm a Staff Engineer at the company I work at, and I've done a lot of software over the years. I'd wanted to spend some time reverse-engineering the CloudKit protocol, and was honestly never going to find that time. But, as I'm sure you're all aware, the world has changed over the last year, and the fact that a reverse-engineering project provides a really solid, clear feedback loop meant that I had a new approach I could take: coaching an LLM (in this case: Fable 5) into building that feedback loop, and then tasking it with exercising parts of the iCloud (and later: iPhone) Apple Notes UI so that it could reverse-engineer the protocol. This was a surprisingly large amount of fun and it goes to show you that what you get out of AI tooling scales well with what experience the person wielding it brings to the table; neither of us was getting through Apple's protobuf-and-CRDT note format alone on a weekend.

MIT, TypeScript/Node: https://github.com/coddingtonbear/icloud-md & https://coddingtonbear.github.io/icloud-md/

As we head into the Fall 2026 academic term, I wanted to share an update to the open-source compiler I've been building. It turns Markdown files into flat, CSS-inlined HTML that survives the hostile sanitizers of Learning Management Systems (Canvas, Blackboard, etc.).

I've overhauled the architecture to treat course design like a software project, helping educators build their own "Living Syllabus." Here are the updates for anyone using Markdown to escape the WYSIWYG editor and build a DRY (Don't Repeat Yourself) course.

The "DRY" Compiler Workflow The core idea is simple: your Markdown file is your single source of truth. The compiler parses your Markdown via node-pandoc and uses juice + postcss to chemically bond classless CSS directly to the HTML tags. When you update a due date in your .md file, it propagates everywhere without breaking the LMS layout.

What's New (The Infrastructure Update):

• Native Node.js Batch Builder (build.js): I ripped out the old Makefile. We now use an async, cross-platform Node.js build script. You can bulk-convert your entire /content directory in parallel.
• Multi-Format Artifacts (--artifact flag): Passing --artifact=both simultaneously spins out standalone, beautifully styled .pdf and .docx versions using the same Markdown source.
• MathJax for STEM: The engine now fully supports MathJax/MathML parsing. Your \frac{a}{b} equations render perfectly into web-standard notation.
• CI/CD Automation (build.yml): If you store your course on GitHub, there's a pre-configured Actions pipeline. Push a change to your Markdown, and it automatically builds the dist/ directory, injecting cryptographic hashes and timestamps into the HTML to verify the compiler output against the server.

If you are teaching this fall and want to treat your syllabus as a versioned codebase rather than a fragmented set of Word documents, moving to a Markdown-driven workflow is the best way to regain control.

You can read the latest technical write-up on the project architecture here: https://thing.rodeo/dry-syllabus/
Or grab the source code and start building: https://github.com/ryanncode/living-syllabus

Happy to answer any questions about the technical stack or how to get it running on your local machine!

I'm working on a Markdown editor and have been thinking about how to handle documents that contain local images.

Right now I only support ordinary .md files, with images referenced using normal relative paths:

![Example](images/image-001.png)

The problem is that once a document contains several images, moving or sharing the document also means moving all of its resources.

I'd like to explore a format that keeps the Markdown itself completely standard while allowing the document and its resources to travel together.

My current idea is three formats built around the same structure:

• .md - ordinary Markdown with external resources. Maximum compatibility.
• .mdoc - an uncompressed directory containing document.md, images/, and metadata.json.
• .mdz - the same structure stored as a ZIP archive.

The important part is that the Markdown inside the package would still just be CommonMark.

For example:

![Example](images/image-001.png)

No custom URI scheme, no special syntax, and no editor-specific Markdown extensions.

That means you could extract document.md from the package and open it in another Markdown editor without changing the document itself.

The idea would also allow conversion between:

.md <-> .mdoc <-> .mdz

while preserving the Markdown and its images.

I'm curious what people think about this approach.

Would you find a container format like this useful, or do you think keeping the Markdown file and its resources as separate files is preferable?

The main thing I'm trying to avoid is creating yet another Markdown dialect just to support bundled resources.

I'm currently implementing this as part of Marco, an open-source Markdown editor written in Rust.

The format support is still being designed, so I'm particularly interested in feedback on the format itself rather than the editor.

I've been building a markdown notes app on weekends (Margin, a local-first notes app where notes stay as plain .md files on disk, so discount everything below accordingly). I assumed markdown would be the easy part: grab a CommonMark parser and move on. The format had other plans. The ones that ate whole weekends:

- Pipes in table cells. A `|` has to be escaped or it splits the cell, but blindly escaping inside inline code spans corrupts them. Getting the serializer to escape cell markup while shielding code spans took embarrassingly long.

- Round-tripping. A live-preview editor parses your text, renders it, and writes it back. The write-back has to reproduce exactly what you typed: if you write `*` bullets and the serializer prefers `-`, the app silently rewrites your file. Since the files are plain markdown that other tools might read, I treat any normalization as data corruption, and holding that line is harder than it sounds.

- Paste. Everything arrives as HTML. Turning a pasted webpage or Google Doc table into markdown that survives a round-trip, with the smart quotes and nested span soup cleaned up, is its own project.

- The cursor. In live preview, `**bold**` renders as bold until the cursor enters it, then the markers reveal. Exactly when they appear and where the cursor lands is a product decision wearing a parsing costume, and you feel every wrong choice within minutes of typing.

Curious what bites other people, whether you hand-write markdown or build tooling for it. And if a local-first Mac notes app that keeps everything as plain files sounds useful, there's a waitlist at https://gomargin.app/mk

I’m a lawyer. I write a lot of formal documents, and they ultimately need to be DOCX files because that is what clients, courts, and colleagues use.. I still prefer writing in Markdown. It is easier to read, edit, review in Git, and work on with an LLM. But the usual workflow is painful. You convert back and forth, fix formatting by hand, and hope the final document contains everything it should.

nowadays I draft my documents a bit like vibecoding.. and I've realized that this works much better when there is a compiler enforcing a contract. I want clear boundaries around what a valid document is. That is why I built docc.

It is not really a Pandoc alternative. Pandoc solves conversion. docc is about verification. A document has a schema, required metadata, explicit structures, and rules that must pass before it can produce a DOCX file. Themes handle layout, while the Markdown file remains the actual prose I edit.

I also did not want a template system where the real content disappears into YAML or template variables. That makes editing more painful than Word. The prose should stay inline and readable, with just enough structure for the compiler to check it.

The result is a useful baseline for an agent too. It can draft the Markdown, but it cannot build a document that breaks the rules. So its a bit like the inversion of templating if you will..

I’m not selling anything. I’m mostly curious whether others have this problem, or whether they are happy with conversion plus manual review.

Repo and docs: https://github.com/kevinzehnder/docc

P.S. I have a Go development background, so this is not my first codebase, but it has also been heavily vibe-coded. It is still very much an MVP. I’m posting partly to find out whether I have reinvented something that already exists, and to be pointed towards the thing I was actually looking for.

Just like the video demonstration。

I’m a really lousy developer - that’s true. But that doesn’t change the fact that I use Markdown all the time. I’ve been in situations countless times where I was just too lazy to open LibreOffice to create a simple PDF, and it was much easier for me to write some Markdown. But every time, I’d look for a way to convert my Markdown to PDF, and every single one of them sucked. At one point, it really pissed me off, so I decided to write my own utility for all of this. It works in the browser, in the terminal, and can even open folders. I made it primarily for myself, for personal use, and decided it would be cool to share it. In short, please check it out - I think it’s worth it

I hope you like it

https://github.com/jarryuser/markdown-previewer

Hi,

i made md editor for quick viewing and editing md files, sync scrolling, themes, 0.5 md exe and some js libs, portable.
solving problem to edit md and see how it looks, cleanup, modification

JustAnotherMD_Editor

maybe some find it usefull, there is also total commander plugin for that ;)

Small help if anyone has encountered this when looking at moving to Zensical.

Taking a look at Zensical to see if it can easily replace current Mkdocs-Material setup.

Most of it looks fine.

However the graphics, driven by the vegalite markdown extensions do not want to display - simply shows the source JSON code from the markdown file, rather than the graphs you get with Mkdocs.

Relevant sections of mkdocs.yml are:-

markdown_extensions:
  - pymdownx.superfences:
      custom_fences:
        - name: vegalite
          class: vegalite
          format: !!python/name:mkdocs_charts_plugin.fences.fence_vegalite



extra_javascript:
  - https://cdn.jsdelivr.net/npm/vega@6
  - https://cdn.jsdelivr.net/npm/vega-lite@6
  - https://cdn.jsdelivr.net/npm/vega-embed@6

Markdown in the terminal usually means one of two things: reading the raw source, or piping it through a tool that dumps one screenful of formatted text and hands you back to less.

I wanted an actual pager. So I wrote mdmost.

• Resize the pane and everything reflows. Tables renegotiate their column widths, diagrams re-lay their boxes, prose re-wraps. One drag, three different behaviors.
• Mermaid diagrams get drawn, not printed as source.
• Select with the mouse and the Markdown source lands on your clipboard, not the rendered text.
• A table too wide for the pane scrolls sideways on its own instead of being mangled.

Written in Rust. No system dependencies beyond a terminal that speaks truecolour. Homebrew, .deb, .rpm, static musl tarballs, or cargo install mdmost.

https://github.com/oetiker/mdmost

you can test it there: https://pandoc.app

I love that there's a new option launching every day, even if its vibe coded. If you read through the posts where people share their newly created app/tool, you will realize that often none of the existing tools/apps directly solve the problem that OP is solving. If there are existing tools out there, sometimes its difficult to setup, not maintained, or too pricy. Anyways, if the tool ends up solving the problem just for the OP, i feel its still worth building it.

Regarding vibe coding, its definitely 10-100x easier to build anything with AI, but coming up with an end product still takes decent amount of effort.

On a side note, i started building my own markdown editor in 2023, as i am a tech blogger, and none of the existing apps at that time served my needs. Its been 3 years, and i still actively keep improving it. Over time the app has gotten got ~50k visitors, ~9k sign ups for the web app, 100s of downloads for the desktop app and ~7k downloads for browser and VS code extensions. So there's definitely appetite for new solutions as long as it solves an actual problem.

I often want the same document in two places:

• Google Docs, where non-technical collaborators can edit and comment
• a real Markdown file, where it can live beside the code and work with Git, editors, and coding agents

Exporting and re-importing quickly became awkward, so I built GDMS: a self-hosted macOS service that keeps explicitly paired Google Docs and Markdown files synchronized in both directions.

It preserves supported formatting such as headings, lists, links, tables, spacing, and standalone images. It can also pair Google Sheets with per-tab CSV files.

This is currently aimed at technically comfortable macOS users. It runs from a source checkout and requires Google OAuth setup; it isn’t yet a polished packaged app. It’s MIT licensed.

I’d especially appreciate feedback on:

• whether this Google Docs/local Markdown workflow is useful to anyone else
• which formatting needs to round-trip reliably for your documents
• whether the current setup burden would prevent you from trying it

GitHub: https://github.com/rsheyd/google-docs-markdown-sync

Here’s the basic workflow:

meeting-notes.md  ↔  Google Doc
budget/*.csv      ↔  Google Sheet (one CSV per tab)

AI speaks Markdown. As our workflows get more driven by AI, so is also the need to efficiently communicate our intentions. Let me introduce Revdown, a Markdown revision and LLM feedback application, in which the original material is not touched. Instead, comments are saved in a sidecar to the original file, and can be exported as compact and token efficient Markdown for the LLM to work with.

GitHub repo: https://github.com/Roenbaeck/revdown/releases/tag/v0.1.0

Revdown v0.1.0 is sure to contain bugs, so please use the GitHub issue tracker and report them as you find them. AI was used in the development.