Markdown Content Hub 2026: One File, Five Platforms

Cross-posting usually starts sensibly and ends in a folder full of near-duplicates. There is the LinkedIn version with a sharper opening, the X Articles version with a different heading, the Medium version with a repaired table, and a Substack draft that contains the only corrected link. A month later, nobody knows which one is authoritative.

The fix is boring, which is why it works: keep one canonical Markdown file. Treat it as the source of truth. Every published copy is a derivative that can be rebuilt. Bluesky's May 2026 move toward long-form content, alongside X Articles and LinkedIn publishing, makes this more useful, not less. More destinations create more opportunities for drafts to drift.

This guide adds the missing step between writing and conversion: normalization. If you already use the three-platform long-form workflow, think of this as the source-control layer underneath it.

One source file beats five platform drafts

A canonical file contains the complete article: title, body, links, image references, code, tables, citations, and the latest corrections. You edit that file first. You do not fix a fact directly in LinkedIn and promise yourself you will copy the change back later. That promise has a short half-life.

Markdown fits the job because it is plain text, diffable, and independent of a publishing vendor. RFC 7763 registered text/markdown as a media type in 2016 and describes Markdown as a family of plain-text syntaxes that can be converted to formal markup such as HTML. That family-of-syntaxes detail matters: your source should stay conservative enough to survive different renderers.

The architecture is simple:

canonical.md
  -> normalize links, headings, tables, images, and code
  -> convert to rich text in the browser
  -> paste into LinkedIn, X Articles, Bluesky, Medium, or Substack
  -> make only small platform-specific edits

The published copies are outputs. The Markdown file is the asset.

What belongs in canonical.md

Use a predictable filename and a small metadata block. It does not need a content-management system. A local folder or private Git repository is enough.

---
title: "The quiet cost of five separate drafts"
slug: quiet-cost-five-drafts
summary: "One source file keeps corrections and links in sync."
canonical_url: "https://example.com/quiet-cost-five-drafts"
platforms: [linkedin, x-articles, bluesky, medium, substack]
last_updated: 2026-07-23
---

# The quiet cost of five separate drafts

Write the complete article here.

Keep the full article body in this file. Put destination-specific hooks in frontmatter or in tiny companion files such as linkedin-intro.txt. A LinkedIn hook can differ from a Bluesky hook without forking the evidence, examples, and conclusion.

If the draft came from an AI writing assistant, the canonical commit should be the human-reviewed checkpoint, not the raw generation. Our AI-to-rich-text workflow covers the conversion step; this hub pattern adds a place to record what a person actually approved.

The 12-point normalization checklist

Run this pass before you copy anything into a platform editor. The goal is not to make every destination identical. It is to remove accidental differences before you choose the intentional ones.

1. Use one H1. Reserve it for the article title. Start body sections at H2.
2. Keep headings shallow. H2 and H3 survive more reliably than a six-level outline.
3. Make image URLs absolute. Replace local paths such as ../img/chart.png before syndication.
4. Write useful alt text. Do not use the filename as the description.
5. Strip tracking parameters from editorial links. Keep campaign parameters only when you deliberately need attribution.
6. Check every link. A canonical file with a dead source merely reproduces the error five times.
7. Label fenced code blocks. Keep the language tag in source even if a destination flattens it.
8. Choose a table fallback. Prepare a list version for editors that do not preserve tables cleanly.
9. Limit list nesting. One level is the safest common denominator.
10. Remove hard line wraps inside paragraphs. Keep deliberate paragraph breaks and list breaks.
11. Normalize invisible text. Remove byte-order marks, stray non-breaking spaces, and accidental trailing whitespace.
12. Read the plain-text version. If the article becomes nonsense without styling, the prose needs repair.

Smart quotes are fine in prose. Straight quotes are safer inside code and metadata. Em dashes are also fine when they are real punctuation; the point is consistency, not flattening a writer's voice into ASCII.

What the five derivatives should change

A derivative is not a rewrite. It is the canonical body plus the minimum adaptation the destination requires. The exact paste behavior can change as editors ship updates, so preview before publishing rather than treating any compatibility table as permanent law.

For destination-specific details, use the dedicated guides for LinkedIn, X Articles, Bluesky, Medium, and Substack. The hub keeps the source clean; the spoke guides handle the last mile.

Example 1: turn a table into a portable list

Suppose the canonical technical note contains this comparison:

# What changed after the cache fix

| Metric | Before | After |
| --- | ---: | ---: |
| Origin requests per hour | 12,000 | 400 |
| p95 response time | 480 ms | 38 ms |

The largest gain came from **stale-while-revalidate**.

Keep that table in canonical.md. It is clearer than prose and works well on your own site. For a destination where the table pastes badly, create this derivative instead:

# What changed after the cache fix

- Origin requests per hour: **12,000 -> 400**
- p95 response time: **480 ms -> 38 ms**

The largest gain came from **stale-while-revalidate**.

The facts are identical. Only the presentation changes. If the numbers are corrected later, update the table first, regenerate the list, and republish the affected copies.

Example 2: separate an image asset from the prose

Image syntax is portable as source but not as a clipboard asset. This canonical excerpt records both the intended position and the accessible description:

## Reach is not resonance

> A large audience can ignore you just as efficiently as a small one.

![A megaphone facing an empty row of seats](https://example.com/img/empty-stage.png)

Track replies per thousand impressions, not impressions alone.

For rich-text destinations, convert the prose, upload or paste the image separately, and place it where the image reference appears. Do not leave a local file path in a published copy. Do not remove the image reference from the source either; it documents the composition of the original article.

This is the difference between normalization and lowest-common-denominator writing. Normalization preserves intent. Lowest-common-denominator writing deletes anything one editor might mishandle.

Put the conversion step after normalization

Once the source passes the checklist, open md2rich, paste the Markdown, and copy the rendered rich text. The conversion runs in the browser. Then paste into one destination, preview it, and make only the planned derivative edits.

That order matters. Converting first and cleaning later creates five cleanup jobs. Normalizing first creates one. If you want a deeper comparison of the privacy and network tradeoffs, see client-side versus cloud Markdown converters.

The canonical file is also the sensitive object. It may contain an embargoed launch, an unpublished customer name, or notes that you plan to delete before posting. Sending it to a conversion server creates another copy outside your control. A browser-only converter removes that particular transfer from the workflow.

Corrections, rollback, and content drift

When a correction arrives, edit canonical.md, commit the change, and record which destinations were updated. A tiny publishing ledger is enough:

2026-07-23  canonical.md  corrected 12,000 -> 12,400
2026-07-23  linkedin      updated
2026-07-23  x-articles    updated
2026-07-23  bluesky       updated
2026-07-24  medium        updated
2026-07-24  substack      updated

This is especially useful when platforms surface post-correction notices or when an old syndicated copy keeps circulating. The X correction workflow covers that case. Git history tells you what changed; the ledger tells you where the corrected version has landed.

Never merge edits back from a platform copy without checking them. Native editors often introduce smart spacing, invisible characters, redirected image URLs, and tracking parameters. If a platform edit improves the article, rewrite that improvement cleanly in Markdown, then treat it as a new canonical revision.

A five-minute publishing run

1. Pull or open the latest canonical.md.
2. Run the 12-point normalization pass.
3. Commit the reviewed source or save a dated local copy.
4. Convert it with md2rich and copy rich text.
5. Paste into the first platform and inspect headings, links, lists, code, and images.
6. Apply the destination's small derivative edits.
7. Repeat for the remaining destinations and mark each one in the ledger.

If that takes far longer than five minutes for a normal article, the source probably relies on a feature that does not travel well, usually a complex table, embedded media, or deep list nesting. Fix the derivative rule instead of making the canonical prose worse.

FAQ

What is a canonical Markdown file?

It is the one version-controlled Markdown file that holds the complete source of a post. Platform copies are derivatives. Facts, links, and corrections are changed in the canonical file first, then exported again.

Why not keep a separate draft for every platform?

Separate drafts drift. A corrected number, renamed product, or repaired link must be changed five times, and one copy will eventually be missed. One source file keeps the substantive text synchronized while still allowing a short platform-specific introduction.

Should platform-specific introductions go in the canonical file?

Keep the article body canonical and store short platform introductions in frontmatter or small companion files. LinkedIn may need a professional hook while Bluesky may need a compact setup, but those wrappers should not fork the article itself.

How should a canonical file handle tables?

Keep the table in the source if it carries useful structure. Before publishing to a destination that pastes tables poorly, make a derivative that turns each row into a short bullet. Do not delete the table from the canonical file just to satisfy the weakest editor.

What happens if my Markdown converter disappears?

Your source remains a plain text Markdown file in your own folder or repository. You can use another converter or render the file yourself. The workflow avoids vendor lock-in because the canonical asset is not stored in a proprietary editor.

Can AI-generated drafts use this workflow?

Yes, but canonical should mean reviewed, not merely generated. Normalize the draft, check every claim and link, remove prompt residue, and commit the human-approved version before producing platform derivatives.