What are big tech companies using for their documentation formats?

·

,

n my last post, I looked at Markdown, JSON, YAML, and XML. My take was that Markdown + YAML/JSON offers the best mix of being easy to read and easy for AI to understand.

But I wanted to sanity-check that.
Are big tech companies actually using these formats?
I did a quick review of what’s publicly visible on their main developer docs. It’s not a full audit—each company has many systems—but it gives a good sense of the patterns.

Here’s what I found:

CompanyExternal DocsInternal Docs (public info only)Main Format
MicrosoftMarkdown + YAMLMarkdownMarkdown + YAML
GoogleMarkdown-based static sitesg3doc Markdown + Google DocsMarkdown
AppleDocC MarkdownDocC MarkdownMarkdown + directives
AWSMarkdown or reStructuredTextMarkdown + reSTMarkdown
MetaMarkdown/MDX + DocusaurusMarkdown-based wikisMarkdown
IBMDITA XMLDITA XMLXML/DITA
AdobeDITA XMLDITA XMLXML/DITA
CiscoDITA XML + MarkdownDITA XMLMixed
OracleDITA XML + some MarkdownDITA XMLMixed
SAPMarkdownDITA XMLMixed

A few things to keep in mind:

  • This list reflects publicly observable documentations, contributor guides, and established industry practices—not internal implementation details.
  • Each company often supports multiple documentation tools depending on product line, age of system, regulatory requirements, and internal ownership.
  • The “main format” here reflects only the examples I could verify.

What seems to be happening?

From what I can see:

  • Many cloud-era developer sites tend to favor Markdown with YAML or JSON metadata. This works well for humans, and it also helps with AI indexing and RAG.
  • Structured XML systems like DITA remain widely used in industries where versioning, translation workflows, and governance are deeply embedded (e.g., enterprise hardware, long-standing enterprise software portfolios).
  • Even companies with long XML histories now publish some developer content in Markdown, especially for SDKs and portals.

None of this is good or bad. Each format exists for valid historical and operational reasons.

Disclaimers

Methodology
This comparison comes from public docs, contributor guides, and open-source materials. It’s not a full map of everything these companies use.

No judgment
Formats aren’t “modern” or “old.” They reflect the size of the company, the type of products, and how long their systems have been around.

Accuracy
If anything here seems outdated or incomplete, I’m happy to update it. Documentation systems change often.

Scope
This review looks only at developer-facing docs, since those are publicly accessible. Internal and proprietary systems are outside the scope.

Comments

Leave a Reply