The quiet case for owning your drafts in plain text
If you publish across five platforms a week, your real content stack isn’t your scheduler — it’s your drafts. Scripts, hooks, carousel captions, newsletter intros, YouTube descriptions: most of it starts life as text, gets pasted into a tool, and then evaporates into a proprietary editor you can’t grep, diff, or version. That’s why a small, unglamorous launch caught my attention this week. Moji, built by Alex Ishida, is a free, open-source desktop Markdown reader and editor for Windows, macOS, and Linux. It is not a social media tool. But the workflow it encodes — double-click a .md file, read it, close it — is exactly the workflow most creators are missing when they treat their content library as a pile of Google Docs and Notion pages. Below is what it actually does, where it fits against the incumbents, and where I think it falls short for anyone running a real publishing operation.
The problem Moji is actually solving (and why it’s a creator problem)
Ishida’s framing is blunt: “opening a Markdown file often felt more complicated than it should.” Most of the time he doesn’t want to launch a full IDE just to read a .md file. He wanted Markdown to behave more like a PDF: double-click → read → close. That’s the entire thesis, and it’s the reason the comment section reads like a support group. One commenter, Andrea Zanon, puts it plainly: “I usually open a .md file in VS Code even when I literally just want to read it.” David Moniz says he’s been relying on his IDE or Obsidian to read .md files and both “seemed painful, but they worked.”
If you’ve never run a content operation out of Markdown, that sounds like a developer complaint. It isn’t. Here’s the operator’s version. When I script a week of short-form video, I write hooks and beats as plain text because plain text survives platform churn. I can paste the same script into CapCut captions, a Buffer draft, a YouTube description, and a newsletter block without fighting rich-text formatting that quietly inserts smart quotes and non-breaking spaces. Markdown is the only format that stays clean through all of it. The catch is that reading it back has always required either a code editor (heavy, ugly for prose) or a preview pane bolted onto something else. There has not been a “just read the file” option on the desktop.
That gap matters more now than it did two years ago, because the number of formats a single piece of content has to become keeps multiplying. A 40-minute interview becomes a YouTube long-form, three Shorts, a TikTok, a LinkedIn text post, a Threads thread, a Pinterest idea pin, and an X thread. If your source-of-truth text lives in a proprietary editor, every repurposing step is a re-export. If it lives in Markdown, repurposing is copy-paste. Moji is a small tool, but it’s a vote for the second model.
What it actually ships with
The feature list, per the maker: live editor plus preview with synchronized scrolling, Mermaid diagram rendering, LaTeX math, tabs and outline navigation, search and replace, HTML/PDF/PNG export, support for large Markdown files, and 15+ interface languages. It’s built on Electron, React, TypeScript, CodeMirror 6, and Mermaid, and the whole project is MIT licensed. When Tom Veber asked whether it renders Mermaid blocks or plain Markdown only, Ishida confirmed it renders Mermaid, supports other rich Markdown content, can export individual diagrams as images, and can convert documents to other formats.
The export trio is the part creators should underline. HTML, PDF, and PNG exports from a single source file is a lightweight content pipeline hiding inside a reader. More on that below.
How it stacks up against the tools you’re already paying for
The honest comparison set isn’t other Markdown readers. It’s the tools you already open when you need to write something: Notion, Obsidian, Google Docs, Bear, iA Writer, and — for the developer-adjacent among you — VS Code. Each of those is a different bet.
- Notion is a database with a text editor attached. Great for content calendars, bad at being a file you double-click. Your drafts live in someone else’s cloud, and exporting them cleanly is a recurring complaint.
- Google Docs is collaborative and universal, but it is the worst possible place to store text you intend to paste into five different platforms. Formatting leakage is constant.
- Obsidian is the closest philosophical cousin — local Markdown files, a vault on your disk — but it’s a knowledge-management app first. It wants to be open all day. If you just want to read one file, you’re launching a workspace.
- iA Writer and Bear are lovely writing environments but opinionated about where your files live, and neither is free and open source.
- VS Code is the default fallback, and it’s exactly the friction Ishida is complaining about. Commenter Metin notes that alternatives exist — he uses QLMarkdown for macOS Quick Look previews — but that’s a preview, not a reader with an editor attached.
Where Moji differs is scope discipline. It isn’t trying to be your second brain or your project tracker. It’s trying to be the thing that opens when you double-click. For a creator with a folder of scripts, that’s a smaller promise than Notion makes — and a more honest one.
Why TikTok and Shorts creators should care more than LinkedIn ones
This is counterintuitive, so let me make the case. LinkedIn and X posts are short enough that you can write them directly in the compose box. The cost of not having a local Markdown workflow is near zero. Short-form video is the opposite. A 45-second TikTok needs a hook, three to five beats, an on-screen text plan, a caption, a hashtag set, and often a pinned comment — all of which benefit from being drafted, revised, and versioned before you ever open the app. That’s a document, not a post. And because you’re likely producing 15–30 of these a month, the compounding value of a clean, greppable script library is real. If you’ve ever tried to remember which hook you used three weeks ago, you already understand why search-and-replace across local files beats scrolling a Notion database.
Three workflow ideas worth stealing, even if you never install Moji
The tool is free, so the switching cost is low. But the more valuable thing here is the pattern. Here’s what I’d lift regardless of which app you use.
1. Treat your scripts as a local, versioned library
Store every script as a .md file in a folder structure that mirrors your publishing cadence — /2025-06/, /shorts/, /carousels/ — and sync that folder to Dropbox or Google Drive if you want cloud backup. Now you have full-text search over every hook you’ve ever written, and you can diff two versions of a script the way engineers diff code. In my experience, the single biggest quality jump in a content operation comes from being able to see your last 50 hooks in one scroll. You cannot do that in a scheduler’s draft list.
2. Use exports as a lightweight design handoff
Moji’s PNG and PDF export means a Markdown file can become a shareable artifact without opening Canva. For carousel drafts, a screenshot-ready PNG of a formatted page is often enough to get client or teammate sign-off before you spend 40 minutes in a design tool. That’s not a replacement for Canva — it’s a way to fail fast before you commit design time. The same logic applies to PDF: a formatted script PDF is a perfectly good deliverable for a client review, and it costs you nothing but a keyboard shortcut.
3. Keep diagrams in the same file as the copy
Mermaid support sounds like a developer feature until you’re mapping a content funnel or a repurposing tree. Being able to write “this YouTube video spawns these three Shorts and this newsletter section” as text that renders as a diagram — in the same file as the script — is a genuinely useful planning primitive. Most creators do this on a whiteboard and lose it. Here it’s versionable text.
Where the math breaks
Two caveats before you get excited. First, Electron apps are not free at runtime — they’re memory-hungry compared to native readers, and if your machine is already running a browser with 40 tabs, Figma, and a video editor, adding another Chromium instance has a cost. Second, “supports large Markdown files” is a claim I’d want to test myself with a genuinely large file before trusting it as my default reader. The maker says it does; I haven’t verified the ceiling.
Where I think it falls short
Let me be direct about the limits, because a free open-source tool still has to earn its place in a paid workflow.
No collaboration story. There’s no mention of shared editing, comments, or real-time co-authoring. If you work with a video editor, a designer, or a VA, this is a solo tool. That’s fine for a script library; it’s disqualifying as a team doc.
No publishing integrations. Nothing here connects to Metricool, Buffer, Later, Hootsuite, or any platform API. It won’t schedule, it won’t cross-post, and it won’t pull analytics. If you were hoping this was a content ops hub, it isn’t — and Ishida never claimed it would be.
No mobile app. Desktop only, per the maker’s description. Since a huge share of creator drafting happens on a phone between shoots, that’s a real gap. You can sync the folder and read it in another app on mobile, but the Moji experience stops at the laptop.
Electron footprint and long-term maintenance. Open-source desktop apps live and die by maintainer bandwidth. The project is MIT licensed, which means if Ishida walks away, someone else can fork it — a genuine trust advantage over closed tools — but it also means nobody is on the hook to ship your feature request. Not disclosed: any roadmap, funding, or team size beyond the maker.
Who it’s not for. If your entire content workflow lives inside Notion or Airtable and you never touch raw text files, Moji solves a problem you don’t have. If you’re on an iPad-first workflow, skip it. If you need approvals and comments baked in, skip it. This is a tool for people who already think in plain text and are tired of launching an IDE to read it.
The open question I keep coming back to
The interesting tension in the comment thread is that several people said some version of “why did nobody make Markdown feel this simple before?” — and Metin correctly pointed out that they did. QLMarkdown exists. Obsidian exists. Typora exists and has for years. So the real question isn’t whether Moji is novel. It’s whether “free, open source, cross-platform, and reads like a PDF” is a better bundle than any of those. My take: for the specific job of opening a file you already have, yes — the scope discipline is the feature. For the job of running your whole content brain, no, and it isn’t trying to be.
What I’d watch / test next
Concrete steps for this week, in order of effort.
- Install it and run one real file through it. Grab the build from the GitHub repo, open your longest existing script, and see whether the read-first experience actually beats your current default. Ten minutes, zero cost.
- Test the large-file claim yourself. Open something genuinely big — a 5,000-word script or a transcript dump — and watch memory usage. If it holds up, it becomes your default reader; if it stutters, you’ve learned the ceiling cheaply.
- Try the PNG and PDF export on a carousel draft. If the output is clean enough for client review, you’ve just removed a Canva round-trip from your process.
- Migrate one content pillar to a local
.mdfolder. Pick your highest-volume format — Shorts or TikToks — and move the next two weeks of scripts into versioned plain-text files. Keep your scheduler for distribution; use the folder for authorship. - Watch the repo, not the launch. Open-source tools are judged over quarters, not launch days. Star it, check the commit history in 90 days, and decide then whether it’s infrastructure or a novelty.
The broader lesson is the one I keep relearning: the tools that survive in a creator stack are the ones that do one thing without asking for your whole workflow. Moji asks for almost nothing. That’s why I’d bet it sticks around longer than most of the AI-everything launches it shared a homepage with.
