Modern documentation platforms

Choosing a modern documentation platform

Over the last ten years, I’ve pivoted my career a few times. I started as a developer, then as a technical writer, then as a documentation engineer, then as a developer educator, and then, most recently, as a documentation engineering manager.

I started consulting for Copytree, a technical writing agency, and we get questions all the time from clients and other prospects about which documentation platform they should use. I couldn’t find a comprehensive comparison out there, so I wrote this article combining both my first-hand experience, what the platforms say about themselves, and what other people are saying online.

I’m sure I’ll make some mistakes, and I welcome corrections and disagreements, so please email me at andrew@copytree.io if I’ve missed anything!

Read this article, with summary, on Nordic APIs!

I'm excited to share that Nordic APIs is hosting a condensed version of this article on their blog!

Check out the article! https://nordicapis.com/review-of-4-modern-documentation-platforms/

Exploring the platforms

To better understand the differences, I’m focusing on four areas of interest:

1. API support: What types of API documentation can you create?

2. Feature support: How do the platforms differ in feature and enterprise support?

3. Artificial intelligence: What features leverage AI, if any?

4. Analytics: How can you measure documentation success?

As you read through the sections, I encourage you to think about what’s important to you and your documentation authors, maintainers, and readers. What’s important is something that only you know; it’s different for every person, for every product, for every company.

Here are some example questions to get you started:

• What features do you need? Do you want features to be powered by AI?

• What do your customers need? Guarantees for uptime? Layers of security?

• Who’s writing the documentation? Are they technical? Do they need to be?

API support

All four platforms support OpenAPI Specification (OAS) and are capable of generating static site websites, with a WYSIWYG editor experience. Each platform can also test out API calls in the generated documentation.

Fern offers the widest range of support and is the only platform that offers support for OpenRPC. Though Mintlify offers less options, it does offer a free tier of support for OpenAPI definitions and AsyncAPI schemas. 

Along those same lines, ReadMe has free entry with OpenAPI and PostMan Collections. 

Finally, Redocly is built on top of Redoc open source, so it’s notable to mention that Redoc premium is what you would want for AsyncAPI, GraphQL, or SOAP support. Additionally, SOAP support is only available on Redocly.

Feature support

For this section, let’s start with an overview of some core features across the platforms. Because of how important the first two features are to authoring and understanding, we’re going to investigate them in more detail.

Editor (GUI)

Fern, Mintlify, and ReadMe all offer “What you see is what you get” (WYSIWYG) editors, Git workflows, and Git synchronization; though, for ReadMe, git features are only available via its Refactored product. Redocly’s editor is a code editor and synchronizes with GitHub, GitLab, Azure DevOps, and its own custom Git product.

If you’re interested in a true, no-git experience, I recommend ReadMe. For a hybrid experience, with a WYSIWYG editor that syncs to git repositories, I recommend Mintlify; for an all-in, docs-as-code writing experience, I recommend Fern or Redocly.

Try-It API

All of these platform experiences are relatively equitable. Each platform lets readers try out requests, though some offer this ability through mock functionality (Mintlify, Redocly) while others offer this ability through real-time authentication (Fern, ReadMe).

Some notable features while trying these products include Fern and ReadMe both auto-populating examples, Mintlify supporting overrides to auto-generation via MDX, and Redocly saving the history of requests via its mock server.   

My recommendation is to look at the accompanying features, like the ability for readers to switch environments or the ability for maintainers to have custom ordering of generated documentation, in order to make the best decision for your readers.

Enterprise highlights

Here’s a few highlights from each platform’s enterprise tier documentation.

In terms of pricing, Fern, Mintlify, and Redocly have custom (i.e., negotiable) pricing for enterprise—whereas ReadMe sets its enterprise-level pricing as a defined cost.

Some notable callouts include Fern’s automated testing in CI for production APIs and custom code maintenance, Mintlify’s content backups and “uptime SLA of 99.99%”, ReadMe’s offering of a customer success manager and content writing and design team, and, for Redocly, choice of data storage locations and access to its Sales support team.

Artificial intelligence

In this section, I’m reviewing my exploration of AI features across each platform and the different underlying models that each platform chooses to use for these features. There’s no escaping the AI question in 2025. Every platform needs to have some feature or offering that leverages AI to help documentation authors, maintainers, and readers.

To better understand this section, let’s start by reviewing some concepts. Feel free to skip over anything you already understand.

• LLMs.txt: A file, similar in philosophy to robots.txt ⇔ sitemap.xml, that details where a model can find additional context to improve the answers of an AI assistant. LLMs-full.txt is a further abstraction of this idea, providing context for the entire site. All of the platforms we’re discussing today generate this file, usually at the root.

• MCP: An open protocol that standardizes how applications provide context to LLMs. Agents interact with live Model Context Protocol (MCP) servers, in an effort to improve AI agent tasks, such as helping readers understand documentation. All of the platforms we’re discussing today include documentation for generating one of these servers; some offer partnerships in building them together.

• Ask AI: The ability to interact with an AI assistant that answers free-form questions about documentation content. In the case of the platforms we’re discussing today, this refers to a drop-down context menu to interact with the assistant on documentation pages.

• AI Search: The ability to interact with an AI assistant that answers free-form questions about where to find documentation content. In the case of the platforms we’re discussing today, this refers to a selectable version of search powered by the assistant, instead of a more traditional search, typically powered by a built-in indexer or Algolia.

With these concepts reviewed, let’s review the distinction in AI features across these platforms.

This section was really interesting to explore during my research. Every platform offers AI search, yet each platform chooses a different underlying model as part of the implementation. Mintlify seems to offer the most variety in model support, at least as far as what is overtly mentioned in the documentation. I also greatly appreciated Redocly’s transparent documentation on how AI search data is handled.

My recommendation, if you are interested in using any of these AI features, is that you take a very careful read at usage limits on each platform’s pricing page, as there are different cost considerations and limits between the many free and paid plans. With ReadMe, as an example, Owlbot AI is treated as an add-on, instead of part of any distinct paid plan, and is a cost-effective way of experimenting with AI features without dedicating yourself to any of these company’s premium tiers.

One prediction that I have for the near future is that competition will drive many of these AI features (that are now almost universally at-cost) to instead become free and provided out of the box at some level, with a general customer expectation that AI integration is a baseline requirement of free pricing plans.

Analytics

The last section I’m covering in this article is on documentation analytics and other notable analytics integrations highlighted on each platform’s respective documentation website.

Documentation analytics give authors and maintainers a greater sense of what’s working, what’s not working, what readers are trying, what they’re not trying, and, often, where documentation needs to be created, updated, edited, or, sometimes, even completely removed. 

Aside from the information already detailed in the table, here is my opinion on some unique value propositions, according to what’s built-in, from each platform:

• Fern: The multi-selection “Was this page helpful” feedback system and integration with Slack and email stands out as a way to get real-time, granular feedback.

• Mintlify: The low-confidence searches metric and breadth of integrations stand out as a way to improve bad search outcomes and create a documentation strategy.

• ReadMe: The API endpoints dashboard stands out as a way to better understand how developers are using documented APIs.

• Redocly: The report icon on code examples and the system logging of the platform and user agent on feedback and reports stand out as a way to improve reliability.

To end this section, I wanted to give a few examples of projects that you might consider as you review analytics on your platform of choice. These are real-world examples inspired by projects that I completed while working professionally in documentation. My experience comes from reviewing Google Analytics, GitHub Insights, and understanding custom events logged in-code to better understand documentation and goal on improving product experience.

• Improve search and documentation quality: Using query data from site search, review top X queries over a range of time and focus on mapping top queries to targeted documentation pages and, over time, change the way that readers search for documentation across the website both by understanding entry points into documentation pages and where foundational understanding is lacking, according to inadequate, or just completely non-existent, introductory copy and documentation.

• Reduce errors and crashes: Using page traffic data, and a combination of other information, like search and crash data, where available, review individual pages and segments of documentation focused on helping readers debug and fix errors, and combine this analysis with a strategy of creating and improving anchor tag sections across documentation pages, like in Troubleshooting or FAQ, to drive down specific error messages and reduce overall product crashes by changing behavior through higher-quality documentation.

• Answer customer questions: Using page referral data, follow trails of documentation links across the web to active discussions on forums, like GitHub and Bluesky, where you can answer questions, capture feature feedback, and help onboard customers to a product or feature through posts, DMs, or just general promotion of new and revised onboarding documentation.

My recommendations

Here are my final recommendations. As always, choose what works best for you, your documentation authors, maintainers, and readers!

• Fern, when you are interested in a robust API documentation platform with extensive language support and strong enterprise partnering.

• Mintlify, when you are interested in full-platform artificial intelligence features, with easy-to-swap design templating.

• ReadMe, when you are interested in a feature-rich collaboration platform for a non-technical audience, with strong add-on value.

• Redocly, when you are interested in a developer-focused API platform, focused on developers as maintainers, with strong enterprise support.

Getting started (next steps)

To make reading this section a little more interesting, in addition to providing instructions on how to get started (via quickstart and starter projects), I’m sharing my own experience about what I liked about the process of getting started on each platform, including my favorite parts of each platform’s documentation website.

Additionally, to give you a perspective different from my own, I’ve included anonymized snippets of feedback from information professionals who have used these platforms, excerpted from conversations on the Write the Docs Slack.