Markdown is one of those formats developers end up using almost everywhere.
README files. Documentation. Architecture notes. API docs. Project specifications. AI-generated content. Blog drafts. Changelogs. Notes written during debugging sessions.
The format itself is simple.
The workflow around it isn't always.
Sometimes you just want to open a Markdown editor, write something, see the rendered result, and export it.
Instead, many tools push you toward an account, a cloud workspace, or a larger platform before you can even start writing.
That was the problem I was trying to solve when I built Markups.
Open it. Write Markdown. See the result. Keep control of your document.
Live: markups.dev
Source: github.com/Nir-Bhay/markups
Markups is an open-source, browser-based Markdown editor designed to make Markdown work feel simple again.
You can open markups.dev and start writing without down a desktop application or creating an account. The editor provides a split Markdown and live-preview workflow, along with features that become useful when a document stops being "just text" — diagrams, equations, code blocks, navigation, linting, templates, and export options.
The current project combines a developer-oriented editor experience with a local-first approach to document handling.
┌──────────────────────┐
│ Markdown │
│ file / document │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ Markups │
│ Edit + Preview │
└───────┬─────┬────────┘
│ │
┌──────────┘ └──────────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Preview │ │ Tools │
│ Render │ │ Mermaid │
└──────┬──────┘ │ KaTeX │
│ │ Code blocks │
│ └──────┬──────┘
▼ │
┌──────────────────────────────────┘
│
▼
┌────────┬────────┬─────────┐
│ .md │ HTML │ PDF │
└────────┴────────┴─────────┘
The goal isn't to replace every development tool you already use.
It's to make the Markdown layer between those tools easier to work with.
The more Markdown I worked with, the more obvious the friction became.
A .md file is portable by design. You can open it in an editor, commit it to Git, send it to someone, put it in a repository, or publish it somewhere else.
So I kept asking myself:
Why should editing that file require a full cloud workflow?
I wanted a tool where the first step is simply:
Open the editor
↓
Start writing
↓
Preview the document
↓
Export / save
No onboarding flow.
No mandatory workspace setup.
No need to turn a simple Markdown file into a hosted account just to edit it.
That became one of the design principles behind Markups.
One of the most important decisions in Markups is also one of the easiest to explain:
You don't need to create an account just to edit Markdown.
Open markups.dev, and the editor is there.
That changes the interaction from:
Open editor
↓
Create account
↓
Verify / sign in
↓
Create workspace
↓
Create document
↓
Start writing
into:
Open markups.dev
↓
Start writing
For a lot of small documentation tasks, that's exactly what I want from a tool.
Under the hood, Markups uses Microsoft's Monaco Editor, the same editor technology used by VS Code. That gives the editing surface a much more familiar developer feel than a basic browser text box.
The editor supports things like:
If you already spend your day in an IDE, the editor doesn't feel completely foreign when you move over to Markdown.
Writing Markdown and reading rendered Markdown are two different activities.
You need both.
Markups provides a live preview so you can edit the source and immediately see how the document is going to look.
┌─────────────────────────┬─────────────────────────┐
│ Markdown Source │ Rendered Preview │
│ │ │
│ # API Documentation │ API Documentation │
│ │ ================= │
│ ## Authentication │ Authentication │
│ │ │
│ - Bearer token │ • Bearer token │
│ - Expiration │ • Expiration │
│ │ │
└─────────────────────────┴─────────────────────────┘
The current editor supports split view as well as a single-pane workflow, synchronized scrolling, and a document mode for a more rendered-document-oriented editing experience.
A Markdown editor becomes much more useful when it can handle the things developers actually put into their documents.
Markups supports common GitHub-flavored Markdown patterns such as:
It also extends the document with:
KaTeX for math
$$
E = mc^2
$$
Mermaid for diagrams
flowchart TD
A[Developer] --> B[Markdown]
B --> C[Markups]
C --> D[Live Preview]
C --> E[Export]
D --> F[Review]
Syntax-highlighted code blocks
async function getUsers() {
const response = await fetch("/api/users");
return response.json();
}
This matters because modern technical documents are rarely just paragraphs.
They contain code, architecture diagrams, tables, equations, checklists, examples, and structured notes.
One thing I like about Markdown-based diagrams is that the diagram can live with the documentation.
For example:
flowchart LR
Client --> API
API --> Auth
Auth --> Service
Service --> Database
Instead of maintaining a paragraph explaining the architecture and then keeping a completely separate image somewhere else, the diagram can be part of the document's source.
Change the architecture?
Change the Markdown.
That is a very natural workflow for developers.
There are documents where plain Markdown isn't enough.
Research notes, educational content, engineering documentation, data explanations, and technical articles can all need equations.
With KaTeX support, you can write mathematical expressions directly in the document:
$$
\frac{d}{dx}x^n = nx^{n-1}
$$
The point isn't to turn Markups into a mathematics product.
It's simply to avoid having technical content break when the document needs one more layer of structure.
Another practical part of the workflow is export.
From the same document, Markups can produce:
┌─────────────┐
│ Markups │
└──────┬──────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Markdown HTML PDF
│ │ │
▼ ▼ ▼
.md file Web-ready Shareable
document document
The current project supports down Markdown, exporting to HTML, and exporting to PDF. Existing Markdown files can also be imported so you can continue working on a document you already have.
That makes the workflow useful when Markdown is the source of truth, but the final output needs to be something else.
Markups isn't limited to editing and previewing.
The current project also includes features aimed at longer or more repetitive documents:
| Feature | Why it is useful |
|---|---|
| Multi-tab documents | Work on more than one document without constantly replacing the current file |
| Templates | Start common document types faster |
| Text snippets | Reuse Markdown boilerplate |
| Focus mode | Remove distractions while writing |
| Typewriter mode | Keep the active writing position visually centered |
| Word / character count | Useful for articles and documentation with size constraints |
| Reading time | Quick estimate for longer documents |
| Table of contents | Navigate large documents quickly |
| Markdown linter | Catch formatting and style issues while writing |
These are small things individually.
Together, they make Markdown feel more like a real writing environment instead of a box where you paste syntax.
This is where I think the project gets more interesting.
You don't have to use Markups for everything.
It works well as a layer around workflows you already have.
You can draft or clean up a README in Markups, review the rendered result, then save the Markdown file back into your repository.
Repository
│
└── README.md
│
▼
Markups
│
┌────┴────┐
▼ ▼
Edit Preview
│ │
└────┬────┘
▼
Save .md
│
▼
Git commit
API docs, installation guides, contributor docs, deployment notes, internal specifications, and architecture documents are all natural Markdown use cases.
Mermaid makes it easy to keep architecture diagrams close to the documentation itself.
This is becoming a particularly interesting workflow.
AI coding assistants can generate:
But generated Markdown often still needs human review.
Markups can be used as that review layer:
AI assistant
↓
Generated Markdown
↓
Markups
↓
Review + edit + preview
↓
Final Markdown
↓
Git / Docs / Publish
The idea is simple: let AI produce a first draft, then use a human-friendly editor to make it actually yours.
Markdown is also a natural format for writing developer articles.
With live preview, a table of contents, word count, reading-time information, and export options, Markups can work as a focused writing environment before content is published elsewhere.
Because the application is built as a Progressive Web App and uses browser caching, the project is designed to continue working after the initial application load. The repository includes a PWA manifest and service worker for this behavior.
That means a weak connection does not have to be the thing that stops you from writing.
A big part of Markups is not a flashy feature.
It is the architecture choice behind the workflow.
The project is designed around browser-based, local-first document handling rather than making a hosted account the center of the product.
A simplified view looks like this:
flowchart TD
U[Developer] --> B[Browser]
B --> E[Markups Editor]
E --> R[Markdown Renderer]
E --> S[(Browser Storage)]
E --> P[Live Preview]
R --> P
E --> M[Mermaid]
E --> K[KaTeX]
E --> H[Syntax Highlighting]
E --> X[Export]
X --> MD[.md]
X --> HTML[HTML]
X --> PDF[PDF]
The important part is the direction of the workflow:
you start with the document, not with an account.
I wanted Markups to be useful for documents that people may not want to put into a hosted workspace simply to edit them.
The current project is built around client-side document handling and does not require an account for the core editing workflow. The project also uses browser storage for local persistence and export/save operations happen from the browser.
That gives the workflow a different feel from cloud-first editors:
Your document
│
▼
Browser
│
▼
Markups
│
├── Edit
├── Preview
├── Persist locally
└── Export
There is no mandatory hosted workspace sitting between you and the first edit.
For developers, that can be useful when working on unfinished ideas, private documentation, internal notes, or project material that simply doesn't need to live in another service.
The goal is not "your files are magically private because the app says so." The goal is to keep the architecture simple enough that the user remains close to the document.
Markups is implemented as a Progressive Web App.
The project includes a web app manifest and service worker so the application can cache the resources required to run after the initial load.
In practical terms, the intended workflow is:
First visit
↓
Application loads
↓
Browser caches app resources
↓
You can install/bookmark it
↓
Connection disappears
↓
The app can continue working from its cached resources
This is particularly useful for the kind of editor that does not need a server round-trip just to render Markdown.
One important distinction: offline application availability is not the same thing as cloud synchronization.
Markups is not trying to become a cloud document collaboration platform. The project is deliberately much more focused than that.
There are plenty of excellent Markdown editors already.
Tools such as StackEdit and HackMD are useful for different workflows, especially when cloud synchronization and collaboration are part of the requirement.
Markups takes a different position.
| Workflow need | Markups approach |
|---|---|
| Start editing immediately | No mandatory account for the core editor workflow |
| Markdown source | First-class editing surface |
| Live rendered output | Yes |
| Mermaid diagrams | Built in |
| Math | KaTeX support |
| Code blocks | Syntax highlighting |
| Local/browser workflow | Core design direction |
| Offline-oriented use | PWA + browser caching |
| Export | Markdown, HTML, PDF |
| Open source | Yes |
| Cloud collaboration | Not the primary goal |
The comparison isn't about declaring one product universally better than another.
It is about choosing the right workflow.
If you need a collaborative cloud workspace, use a tool designed for that.
If you want a focused Markdown editor that you can open and start using, Markups is built around that experience.
Imagine you're building an API and want to document it.
You might start with:
## GET /users
Returns a list of users.
## Authentication
Use a bearer token.
http
Authorization: Bearer
## Architecture
mermaid
flowchart LR
Client --> API
API --> Auth
Auth --> UsersService
UsersService --> Database
plaintext
Then you can immediately see:
And when you're done, you can keep the .md source or export the document to HTML/PDF.
That's the workflow I care about most.
Not "write Markdown because Markdown is cool."
Write Markdown because it is useful — and make the editor around it useful too.
You don't need a complicated setup.
Go to:
Open the editor and begin with Markdown on the source side.
Use the live preview to check the rendered document while you write.
Already have a .md file? Import it and continue from there.
Try:
Save the Markdown source or export the document as HTML/PDF.
| Shortcut | Action |
|---|---|
Ctrl + S |
Save Markdown |
Ctrl + P |
Export / print to PDF |
Ctrl + O |
Import Markdown |
Another important part of Markups is that it is open source and released under the MIT license.
That matters to me because a developer tool should be inspectable.
You can read the code.
You can understand how the application works.
You can contribute.
You can fork it.
You can adapt it for your own workflow.
Repository:
👉 https://github.com/Nir-Bhay/markups
Markups is a focused Markdown workspace.
It is not trying to replace:
Instead, it sits in a much smaller space:
Write
↓
Preview
↓
Improve
↓
Export / Save
That simplicity is intentional.
There are still plenty of areas where a Markdown editor can get better.
Some ideas I'm exploring include:
These are ideas, not promises about the current release.
One of the nice things about keeping the project open source is that the roadmap doesn't have to come entirely from one person.
The interesting part of Markups isn't really Markdown syntax.
Markdown already works.
The interesting part is the workflow around it.
Does writing a README need an account?
Does editing a .md file need a cloud workspace?
Does documentation always need to live inside another platform?
I don't think it has to.
Sometimes a tool should simply:
Open
↓
Write
↓
Preview
↓
Export
↓
Done.
That's the idea behind Markups.
A free, open-source Markdown editor that you can open in your browser and start using without a mandatory account.
If that matches the way you work, give it a try.
Live App: https://markups.dev/
GitHub: https://github.com/Nir-Bhay/markups
And because the project is open source, feedback, issues, and contributions are always welcome.
Built for people who just want to work with Markdown.