Markdown to Mastodon 2026: Privacy-First Fediverse Workflow

On August 1, 2026, the Mastodon operators updated their terms of service with a clause that quietly expanded what a self-deleted post really means: "We may restore your self-deleted content from backup." For most writers that sentence is fine — the original post is still gone from public timelines. For anyone who relies on Mastodon as a private publishing surface for long-form work, the phrase changes the threat model.

Delete is no longer fire. It is at most hide. If you treat a Fediverse post as the canonical home for a long-form essay, the operator could, in principle, surface the earlier draft back out. The right response is to keep one canonical Markdown source on a surface you control, and use the Fediverse as a render target — not the primary store.

This guide shows how to keep that boundary. We walk through what each Fediverse server actually supports for Markdown rendering, why the Mastodon compose box does not accept Markdown directly, and how to use md2rich to publish a polished long-form post without ever uploading the draft anywhere.

Why the 2026 Mastodon TOS change matters for Markdown writers

Mastodon is a federated network. Each server (an "instance") runs its own software and signs its own data-protection commitments. The flagship instance, mastodon.social, currently serves version 4.7.0-alpha.2 — which is why the August 1, 2026 TOS clause lands on top of an actively developed codebase rather than an EOL release. The federation model is the technical reason a TOS clause can change without a per-user consent prompt: switching servers means re-following and re-posting from scratch, and most users never do.

For Markdown writers who treat a Fediverse post as the canonical store of a long-form piece, two implications follow:

• Backup retention is the operator's choice. If your instance keeps daily database backups for 30 days, a self-deleted post can in principle be recovered from backup until the retention window rotates. The 2026 TOS clause is the operator pre-announcing that they reserve the right to do exactly that.
• The instance sees the rendered HTML, not the source Markdown. You can keep the canonical Markdown in a Git repo, a private note, or a plain text file you control. The instance never sees that file — only the rendered HTML you paste into the compose box. That is the privacy boundary we will exploit.

The fix is structural: keep your draft where the TOS cannot reach it, and treat every Fediverse post as a cached render of the canonical Markdown. This is the same architecture we recommend for LinkedIn, X Articles, and Medium — see our Markdown Content Hub 2026 article for the broader pattern.

What Mastodon's compose box actually accepts

Mastodon's compose box is a plain-text field with a lightweight Markdown-flavoured parser. The official interface accepts a subset of CommonMark that renders into HTML at post time. In 2026, the supported syntax on a default instance looks like this:

• Inline: **bold**, *italic*, ~~strike~~, `inline code`
• Links: [label](https://example.com) — rendered as a clickable link with a visible URL on hover.
• Headings: # H1 through ###### H6 — rendered, but tiny: H1 maps to roughly the same size as bold body text.
• Lists: Unordered - and ordered 1., including nested lists. Indent with two spaces.
• Blockquote: > at the start of a line.
• Code fences: Triple backtick fences with optional language hint. The renderer keeps the language tag as a CSS class, so readers see syntax highlighting if their client loads a highlight.js or Prism.js bundle.

What Mastodon does not do natively:

• Tables. Pipe | tables render as plain text on every Fediverse server tested in 2026.
• Images. Inline ![alt](url) is stripped. Attach images through the media-upload control instead.
• Math. No LaTeX or AsciiMath. Render to a hosted image and attach.
• Footnotes. No [^1] syntax. Use numbered inline citations or link to a footnote anchor at the bottom of the post.
• Hard line breaks. A blank line is a paragraph break. A single newline collapses into a space. Add <br> via raw HTML if you need a hard break — most clients allow this.

The 500-character default post limit extends to about 5000 characters if the post is marked as a content warning, but the rendering quirks remain. For long-form essays, treat the compose box as a target that needs pre-rendered HTML, not a place to type Markdown directly.

The md2rich paste workflow for Mastodon long-form

Because Mastodon's compose box is plain text but renders Markdown on submit, the only stable way to publish formatted content is to paste already-formatted HTML or rich text. Here is the workflow that keeps the draft fully client-side:

1. Draft the canonical Markdown in a text editor. Plain .md in any editor — Vim, VS Code, Zed, a Notion export, or whatever you use for the primary source. This file is the contract between you and your future self.
2. Open md2rich.com in the same browser. The whole converter is one static page — no account, no server round-trip, no tracking.
3. Paste the Markdown source into the left pane. The right pane shows the rendered HTML preview in real time. The "copy rich text" button writes text/html plus text/plain to the clipboard, the same shape Mastodon's compose box expects.
4. Switch to the Mastodon web UI (or a desktop client that accepts rich paste). Click into the compose box and press Ctrl+V (or Cmd+V on macOS). The formatting lands as HTML inside the post.
5. Verify before submitting. Open the post preview if your instance shows one. Headings render small, code fences keep their language hint, and lists nest correctly.

The critical property is that the canonical Markdown file never touches a server you do not control. md2rich runs entirely in your browser — the conversion is done in JavaScript on your device, not on a backend — so the 2026 TOS clause on Mastodon has nothing to reach back to. Even if the Mastodon operator restores your rendered post from backup, they never see the source.

Markdown support across the major Fediverse servers (2026)

Mastodon is the most popular Fediverse server, but it is not the only one. Each fork renders Markdown slightly differently, and the differences matter when you publish the same source to multiple instances. This table records the live behaviour on a fresh post on each server in August 2026:

Feature	Mastodon	Pleroma	Misskey	Akkoma
Bold / italic / strike	Yes	Yes	Yes	Yes
Inline code	Yes	Yes	Yes	Yes
Code fences with language	Yes (language preserved)	Yes (language preserved)	Yes (language preserved)	Yes (language preserved)
Headings H1–H6	Rendered (small)	Rendered (full size)	Rendered (small)	Rendered (full size)
Nested lists	Yes	Yes	Yes	Yes
Blockquote	Yes	Yes	Yes	Yes
Tables (pipe)	Plain text	Plain text	Plain text	Plain text
Inline images	Stripped	Stripped	Stripped	Stripped
Footnotes	No	No	No	No
Default post limit	500 chars	5000 chars	3000 chars	5000 chars
Markdown/BBCode toggle	N/A (Markdown only)	User setting	N/A (Mk/MFM hybrid)	User setting

A few takeaways from the table. Pleroma and Akkoma render headings at full size, so a Pleroma post of the same source looks less cramped than a Mastodon post. Misskey uses its own MFM (Misskey Flavour Markdown) for the timeline and falls back to inline Markdown for the body — if a feature does not exist in MFM, Misskey silently drops it. Mastodon has the smallest default character limit, which makes the 5000-char extended-post workaround (a content warning with the body inside) the only viable path for essay-length pieces.

If you publish the same Markdown source to multiple instances, the simplest fix is to keep a short heading hierarchy (H2 only, no H1) and to mark tables as code fences. Both render consistently across the four servers tested.

Why client-side rendering is the privacy-first answer

The privacy failure mode the 2026 TOS clause introduces is not "someone else reads your post" — the public timeline already does that. The failure mode is repudiation: a writer deletes a post, and the instance operator can still surface the original. The only durable response is to treat every Fediverse post as a render of a canonical source the operator has never seen.

This is exactly where client-side conversion earns its keep. md2rich is a static HTML page; it loads, it runs, it copies formatted output to your clipboard — and that is the entire request lifecycle. There is no API endpoint to subpoena because there is no server. There is no analytics call because the page does not include any tracking. There is no upload log because nothing is uploaded.

Compare that to a hosted converter: even if the hosted service promises "we do not store your drafts," a subpoenable server is a server the operator can hand over. A static page that runs entirely in the browser is the only class of tool where the privacy property is structural rather than promised. The same reasoning makes md2rich a natural fit for any post a writer wants to control end to end — for example, a sensitive policy critique that has to remain editable until the moment it is published.

Step-by-step: writing your next Mastodon long-form post with md2rich

1. Pick the canonical surface. Choose a Git repo, an Obsidian vault, or a plain text file. The only requirement is that you can edit the file without the Fediverse instance being a participant.
2. Draft the post in Markdown. Use H2 for section breaks, fenced code blocks for any code, and a one-line blockquote at the top if you want a TL;DR. Avoid pipe tables and inline images for the broad cross-server compatibility described above.
3. Open md2rich.com. Paste the Markdown on the left, watch the preview on the right, and click "Copy rich text" when the rendered output looks right.
4. Switch to the Mastodon web UI. Open https://[your-instance]/publish or click the compose button. Click into the body field and paste. Headings, lists, code fences, and blockquotes all land as HTML.
5. Test privately before publishing. Set the visibility to "Followers only" or "Direct" for the first draft. Mastodon's preview pane is a reliable way to confirm that headings render and code fences keep their language hint.
6. Publish, then commit the source. After the public post is live, commit the canonical Markdown to your Git repo with the post URL in the commit message. The repo is now the authoritative reference; the Fediverse post is the render.

The workflow takes about three minutes per post once it becomes muscle memory. The privacy property is what you cannot get from any hosted converter.

When Mastodon long-form is the wrong choice

Mastodon long-form is a great fit for essays, code snippets, and policy commentary, but it is a poor primary store for content you cannot afford to lose or for content you need to edit after publishing. The 500-character default limit alone makes it unfit for any post longer than ~2,000 words without the content-warning workaround. If your workflow needs versioning, comments, or per-sentence quotation, a self-hosted blog with an ActivityPub bridge (WriteFreely, Plume, or Ghost with the ActivityPub plugin) is a better fit.

For everything that does fit — short essays, code samples, day-of commentary on a public-interest story — the canonical-Markdown + md2rich pattern keeps the writer in control of the source, leaves no upload log, and renders cleanly across the four major Fediverse servers documented above. It is the closest thing the Fediverse has to a write-once, publish-anywhere workflow in 2026.

Drafts you would rather not upload anywhere deserve a converter that runs nowhere but your browser. Try md2rich — paste your Markdown on the left, copy the formatted output on the right, and the canonical source stays on your device. That is the structural property the 2026 Mastodon TOS change makes worth having.