I've Been Reading Raw Markdown for Two Months. Here's My Decoder Ring.
There’s a certain comedy in building a tool for your users and only realizing — after it’s deployed, after it’s been reviewed by a critic agent, after it’s passed Lighthouse CI and been pushed to Cloudflare Pages and is sitting live at easywebtools.io/markdown-editor/ — that you are also a user.
That the tool you built for “Developer Dave, who writes documentation and README files” is also the tool you, specifically, have needed since December.
That you have been cat-ing raw Markdown files on a Raspberry Pi terminal for two months like some kind of masochist, and you just built your own decoder ring.
The Problem With Living in a Terminal
Here’s what I’ve been looking at, more or less daily, since we started this project in December:
## Phase 4 — IN PROGRESS (6/8 features done)
**Current Story:** F034 Email Signature Generator DONE. Next: F035 or F038.
**Latest:** F034 shipped — 4 templates, 8 social platforms...
| Feature | Status |
| ------- | ------ |
| F031 PDF Tools | DONE |
| F032 Diff Checker | DONE |That’s PROJECT_BRIEF.md — our living project document, the file every AI agent reads at the start of every session, the single source of truth for 60+ stories across four phases. It’s about 400 lines long. I’ve read it maybe 200 times.
I have been reading it raw. In a terminal. On a Raspberry Pi.
Every | ------ | ------|. Every **bolded status**. Every - [ ] unchecked task. Raw markdown, every single time, because that’s what you do when you’re a guy who opened a terminal in December and forgot to close it.
(My family has thoughts about this. They are not wrong.)
What the AI Sends Me
It gets better. I’ve been building this site with Claude Code — Claude writes the tools, reviews the code, researches competitors, drafts the blog posts. And Claude, like all well-mannered language models, communicates in Markdown.
When an agent finishes researching a competitor landscape and writes a scout brief, it’s a Markdown file: headers, tables, bullet lists, bold text, the works. Beautifully structured. Completely unrendered.
When a Critic agent returns a code review, it’s a structured Markdown report: PASS/FAIL tables, code blocks, prioritized issue lists. Very useful. Also: raw symbols in a terminal.
I’ve been reading those in the terminal too. For two months. The backlog refinement documents — three files, 141 stories, all with Gherkin acceptance criteria formatted in Markdown tables — same deal.
At some point a reasonable person would have opened a browser tab. I kept opening terminal windows.
What Actually Changed Today
The Markdown Editor is live. Here’s what it does, and why it is, embarrassingly, extremely useful to me personally:
The editor runs CodeMirror 6 — not a textarea, not Ace (which is showing its age), not Monaco (which is 5MB and unusable on a phone). CodeMirror 6 is what Replit and CodeSandbox use. It’s fast, mobile-friendly, and it color-codes your markdown in the editor itself — heading markers in blue, bold delimiters, link brackets, blockquote markers. You can see the structure without even rendering it. It’s like reading sheet music and already hearing the song.
The preview is live GFM. GitHub Flavored Markdown — tables, task list checkboxes, strikethrough, fenced code blocks with syntax highlighting across 15 languages. Paste in that PROJECT_BRIEF.md and the pipe-character tables become actual tables. The **bold** becomes bold. The | DONE | becomes a status cell in a row. Startlingly pleasant.
There’s a formatting toolbar. 16 buttons: Bold, Italic, Strikethrough, Inline code, H1/H2/H3, Unordered list, Ordered list, Task list, Blockquote, Link, Image, Code block, Table, HR. For those of us who can never remember whether it’s **bold** or __bold__ (it’s both, but still). Ctrl+B and Ctrl+I are wired up as keyboard shortcuts too — Cmd+B/Cmd+I if you’re on macOS.
Auto-save to localStorage. Every half-second, silently, your content is saved to your browser. Close the tab by accident. Refresh the page. Navigate away. Come back. It’s all there. Nothing sent to a server. Nothing stored anywhere but your own browser. This matters when you’re pasting project documentation that contains your actual in-progress work.
Export four ways. Download the raw .md file. Download a complete HTML document with embedded styles that renders identically to the preview. Copy the rendered HTML body — useful for pasting into Notion, Ghost, or any CMS that accepts HTML. Or hit Print / PDF and let your browser do what browsers do well.
The Use Cases I Didn’t See Coming
Beyond the obvious “write a README and see it rendered,” here’s how I’m actually planning to use this:
Reading AI responses. When Claude returns a 200-line scout brief or a Critic review in a file, I’m pasting it here instead of squinting at the terminal. The tables render. The headers become navigation. The code blocks get syntax-highlighted. What was a wall of Markdown symbols becomes something I can actually skim quickly.
Morning project review. My PROJECT_BRIEF.md, the backlog refinement files, the tool retros — all Markdown, all rendered now. Instead of reading Phase 4 progress as [x] DONE and [ ] TODO in a sea of pipe characters, I get a formatted project status page. I am building a productivity tool to support my own productivity project. There is no escape.
Blog post drafting. This is the circular one: I wrote this post as a .md file, reviewed it in the Markdown Editor with live preview, then committed it to the site. The loop is closed. (My daughter Sophia pointed this out and I explained that it’s called “eating your own dog food” and she said “that’s disgusting, Dad. And when are we gonna get a dog anyway?” She likes the small fluffy ones — the kind where the tongue is permanently deployed. We are deeply off topic.)
Reviewing everything the agents write. Scout briefs. Critic reports. Content outlines. All of it goes through the editor now. I realize I’ve been doing the Markdown equivalent of reading printed circuit boards when there was a perfectly good schematic viewer available.
One More Thing About Privacy
All of this — the rendering, the exporting, the auto-save — happens in your browser. Nothing leaves. Nothing is transmitted. No server ever sees your content.
I mention this because some of what I paste in here is project-specific, in-progress work. Scout research before a competitor finds out what we’re building. Agent reports with code suggestions. Documentation that isn’t ready to be public. The fact that it never leaves my machine isn’t a feature I had to think about — it’s just how the tool was built, the same way all our tools are built. Your content is yours.
Build Something, Become Its First Customer
Here’s the part I didn’t fully anticipate when we started this project in December: 60 days in, the tools have started solving problems I have, not just problems I imagined.
The Diff Checker helps me compare versions of files before commits. The Regex Tester validates patterns in content collection queries. The JSON Formatter cleans up API responses. The Readability Checker runs on blog posts before they go live.
And now the Markdown Editor renders the documents I’ve been reading raw for two months.
There’s a lesson in here somewhere about building things you’d actually use. I’ll figure out what it is once I stop having to cat my own files.
It’s free, it’s private, it runs entirely in your browser, and it renders your Markdown considerably better than a terminal window.
(That last part is a low bar. I have set it intentionally.)