RFC7763: Markdown Standardization Returns to IETF

On June 27, 2026, the IETF datatracker entry for RFC7763 — The text/markdown Media Type saw renewed mailing-list activity, putting Markdown standardization back on the formal Internet standards agenda after a decade of quiet dormancy. RFC7763 is the document that registers Markdown as a recognized Internet media type in the same category as text/html, text/plain, and text/csv. This article explains what the IETF revival means, why it matters in 2026, and what changes — and does not change — for writers, editors, and client-side tools like md2rich.

What RFC7763 Actually Says

RFC7763 was authored by G. Leonard, M. Weber, and A. Flournoy and published in March 2016. Its full title is The text/markdown Media Type, and it occupies an unusual position in the IETF document tree: it is informational, not standards-track, and it deliberately does not pick a single canonical Markdown grammar. The document defines:

• The media type identifier: text/markdown
• The expected file extension: .md (and .markdown, .mkd)
• The required charset parameter, which defaults to US-ASCII and may be UTF-8
• A pointer to the CommonMark specification as the recommended normative reference
• Acknowledgment that "Markdown" has multiple flavors (CommonMark, GFM, MultiMarkdown) and that a future revision may narrow the scope

What RFC7763 does not do is define the syntax itself. It is a label, not a grammar. The grammar lives in the CommonMark spec and its extensions (GFM tables, task lists, strikethrough, autolinks). That separation — media type registration here, syntax specification there — is exactly the gap the 2026 revival is trying to close.

Why the IETF Revival Is Happening Now

The datatracker entry for RFC7763 had been essentially frozen since 2016. Three forces converged in mid-2026 to reopen it:

1. AI training pipelines need a stable identifier

Frontier-model training corpora now contain billions of Markdown documents sourced from GitHub repositories, technical blogs, Reddit exports, StackOverflow archives, and Notion workspaces. The datasets are usually stored as raw .md files, but the labels are inconsistent — some pipelines emit text/markdown, others emit text/plain, others emit application/octet-stream because no media-type registry had a definitive entry. Standardizing the label makes provenance and licensing chains auditable.

2. Legal and compliance teams want a normative reference

When a contract says "the documentation is provided in Markdown," there has historically been no canonical answer to what that means. CommonMark? GitHub-Flavored Markdown? The flavor the author happened to use? A normative IETF reference gives legal teams a spec they can cite by URL, the same way they cite RFC 4180 for CSV.

3. CMS vendors are tired of supporting 8+ flavors

Every CMS that accepts Markdown — Notion, Ghost, Substack, WordPress with Jetpack, Drupal with Markdown filter, Shopify with rich-text extensions — ships its own dialect layer because the original Markdown spec (Gruber, 2004) is ambiguous. The cumulative maintenance cost of these parallel forks is now in the millions of engineering hours per year across the industry.

CommonMark vs RFC7763: How They Fit Together

CommonMark is the Markdown specification project started by John Gruber and Jeff Atwood in 2014. It is a community-maintained, versioned spec with a reference implementation in C and test suites in dozens of languages. RFC7763 cites CommonMark as the recommended grammar but stops short of making that citation mandatory. The 2026 IETF thread is discussing whether to:

• Promote CommonMark to a Standards-Track RFC, citing it as the normative text/markdown grammar
• Define a minimal "core Markdown" subset that all parsers must accept, with extension points for GFM tables, task lists, and autolinks
• Leave RFC7763 informational but require a structured field in the Content-Type header that names the dialect (e.g. text/markdown; variant=gfm)

None of these are decided yet. The mailing-list thread is in the early shepherd review stage, which historically takes 6-18 months before any IETF document is updated or replaced. What matters for 2026 is the direction of travel: the IETF is committing to a narrower, more enforceable text/markdown definition, and CommonMark is the front-runner for the reference grammar.

What Changes for Markdown Writers in 2026

For anyone who drafts in Obsidian, iA Writer, Typora, VS Code, or plain text, the answer is: nothing changes this year. The IETF discussion is moving slowly, and no editor needs to ship a flag-day update. But three downstream effects will start showing up in 2026 and 2027:

What It Means for Client-Side Converters Like md2rich

md2rich's job today is to take Markdown source text and emit a text/html clipboard payload that destination editors — Medium, LinkedIn, X Articles, Substack, Notion — recognize as formatted rich text and render correctly. A standardized text/markdown media type helps this workflow in three concrete ways:

First, source fetching. When a CMS like Ghost or Hashnode serves a draft behind an authentication wall, it can expose the raw text as text/markdown with a Content-Type header that any client tool can fetch without re-parsing the HTML wrapper. md2rich can then convert it locally without sending the draft to a server-side parser.

Second, parser hardening. md2rich currently defends against 4-5 distinct table-syntax dialects because GitHub, GitLab, Bitbucket, Obsidian, and Notion each render them slightly differently. A normative CommonMark reference at the IETF level lets the project commit to "if it parses as CommonMark plus the documented GFM extensions, it is supported — otherwise it is the source editor's bug to fix." That removes a long tail of edge-case regressions.

Third, clipboard interoperability. Today, when md2rich copies rich text, the clipboard advertises text/html. Medium, LinkedIn, and X Articles all accept that payload. Substack's email composer and some CMS rich-text editors fall back to text/plain, losing all formatting. A registered text/markdown clipboard type would round-trip cleanly into any destination that opts into paste-as-markdown — a feature Substack, Beehiiv, and Ghost have all discussed shipping.

The Markdown Sample: A Glance at the Grammar

To ground the standardization discussion, here is a small Markdown sample that illustrates the kind of construct a stable spec needs to nail down. Paste this into md2rich to see how a conforming parser renders it:

## RFC7763 sample

Markdown is a **lightweight** markup language. The text/markdown media
type was registered in 2016 and is being revived in 2026.

### Standardization forces

1. AI training corpora need stable identifiers.
2. Legal teams want a normative spec.
3. CMS vendors are tired of supporting 8+ flavors.

| Flavor        | Year | Source          |
|---------------|------|-----------------|
| Markdown      | 2004 | Gruber          |
| CommonMark    | 2014 | Gruber, Atwood  |
| GFM           | 2017 | GitHub          |
| RFC7763 (rev) | 2026 | IETF revival    |

Read the spec at <https://datatracker.ietf.org/doc/html/rfc7763>.

The output is deterministic: a CommonMark-conforming parser produces the same HTML from this source every time. That determinism is exactly what RFC7763 wants to make normative.

What Editors Should Do Today

If you ship a Markdown editor, a CMS, or a converter, three concrete steps get you ready for the IETF outcome without waiting for the standards-track decision:

1. Serve your raw drafts with Content-Type: text/markdown; charset=utf-8. Even if the canonical IETF reference is still under discussion, this header is already legal under RFC7763 and lets clients fetch drafts directly.
2. Validate against the CommonMark spec, not a homemade dialect. Use commonmark.js, markdown-it with strict mode, or the commonmark reference implementation. Document any GFM extensions you accept.
3. Ship a text/markdown clipboard payload alongside the text/html payload. Most modern browsers support multi-format clipboard writes via the async Clipboard API. Destinations that understand paste-as-markdown will pick the Markdown; others will fall back to text/html cleanly.

Writers who use md2rich today already get most of this for free. The tool emits text/html by default, which every modern editor accepts, and the conversion is fully client-side so no server ever sees the draft. As the IETF thread progresses, expect md2rich to add a text/markdown clipboard option for destinations that prefer the round-trip.

The Privacy Angle: Why Client-Side Stays Important

RFC7763 is a media-type registration, not a transport protocol. It does not say anything about where Markdown content is processed, sent, or stored. That is a separate decision — and it is the one that matters most for writers handling unpublished drafts, internal documentation, or anything under NDA.

md2rich's stance does not change with the IETF revival: conversion happens entirely in the browser as a single static HTML page with no backend. The Markdown source text, the converted HTML, and the clipboard payload never leave the device. There is no signup, no analytics on draft content, no third-party request beyond the static page itself.

This is the same posture that made client-side conversion useful for confidential LinkedIn posts, internal X Articles, and private Substack drafts in 2024-2025. A standardized text/markdown media type does not change that calculus — it simply makes the convert-then-paste step more interoperable, which means more destinations accept Markdown natively without ever needing a server-side parser to see the draft.