As engineers, we usually don’t think about document conversion until it becomes friction in an otherwise clean workflow.
In my case, the problem came from a very boring place: moving Markdown content between systems that don’t agree on formats.
The workflow problem
I write almost everything in Markdown.
Internal docs
API notes
Temporary specs
One-off data explanations for non-engineering teams
The issue starts when Markdown leaves the engineering world.
Sometimes the destination expects HTML, sometimes DOCX, sometimes a CMS that silently strips unsupported tags. I don’t want to install another dependency, add a new CLI, or wire up a conversion pipeline just for something I’ll do once or twice that week.
This usually happens in situations like:
Copying Markdown output from scripts into a CMS
Sharing formatted content with operations or marketing
Converting generated Markdown reports into something readable by non-devs
At that point, the workflow breaks.
Why I avoid “solutions” here
There are a lot of proper ways to solve this:
Pandoc
Custom scripts
Editor plugins
Build-step converters
All of those are valid, but they assume the problem is persistent.
Most of the time, it’s not.
This is a temporary workflow gap, and I don’t want to pay long-term complexity for a short-term problem.
So my rule is simple:
If it’s not part of the core system, it shouldn’t become part of the stack.
What I actually needed
The requirement was minimal:
Paste Markdown
Get clean output in another format
No account
No setup
No persistence
I don’t care about branding, features, or performance benchmarks here. I just want to unblock myself and move on.
The “in-between” approach
For these cases, I sometimes use small, disposable web tools — not as products, but as workflow bridges.
Recently, when dealing with Markdown-to-HTML and Markdown-to-text cleanup, I used this page once or twice:
That’s it. No integration, no evaluation.
I didn’t bookmark it, didn’t sign up, didn’t adopt it into anything. It just filled the gap between:
“I have Markdown” → “I need something another system understands”
Why this fits an engineer workflow
What made this usable for me wasn’t features — it was the absence of friction.
No decision-making
No configuration
No learning curve
It behaves like a scratch buffer rather than a tool you commit to.
That matters, because once you start evaluating a tool, you’re already spending more time than the task deserves.
Where this kind of thing belongs
I wouldn’t recommend this approach for:
Production pipelines
Repeatable automation
Anything versioned or audited
But for:
One-off data processing
Temporary document conversion
Cleaning generated content
Helping non-technical teammates consume output
This kind of “use once and forget” solution is often the most efficient choice.
Final thought
Most workflow problems don’t need a permanent solution.
They need a safe exit ramp.
When I notice myself hesitating to add yet another dependency just to get past a small format mismatch, that’s usually a signal that the correct answer is something lightweight and temporary — not another thing to maintain.
Top comments (0)