--- title: "React CMS: How to Choose the Right Setup" source: https://refact.co/insights/digital-product/react-cms-2 author: "Masoud Golchin" date: "2026-08-24" --- # React CMS: How to Choose the Right Setup A “React CMS” is an architectural choice, not a product category. Most teams make this choice in the wrong order. They look for the tool with the most GitHub stars or choose the tool a developer is familiar with, and only then, determine if editors can publish without a ticket, if the site is search engine crawlable, and who owns the schema if a new content type breaks a page. It should be obvious, but publishing will get slower as a result. The goal of this article is to clarify what a React CMS looks like in 2026 and the 4 main concepts behind this term and what factors help you choose the version of the React CMS you can tolerate having for 2 years versus what you would rather rebuild in 18 months. If you are evaluating if your team actually needs one, review our article on when [Headless CMS’s fit React teams](https://refact.co/insights/digital-product/headless-cms-react). ## What “React CMS” Actually Means The term gets used in 3 different ways, and it’s mostly bad decisions where the term gets used in multiple ways and those meanings get conflated. The first explanation of the term is a headless CMS whose web content is consumed by a React or Next.js frontend. The CMS manages and structures content and exposes it through a REST or GraphQL API. React takes care of view rendering. This is the most prevalent model. Contentful, Sanity, Strapi and Cosmic are all here, and this model is well described in a blog post by Cosmic titled [React CMS](https://www.cosmicjs.com/react-cms). The second meaning is a CMS whose admin panel is built in React. These include Payload, KeystoneJS, and TinaCMS. Of these, Payload has over 44,000 GitHub stars, and has recently decided to position itself as a full-stack Next.js framework. This indicates where the ecosystem is headed — the CMS admin, API, and frontend built as one single codebase. The third meaning is a visual builder that produces React, like Plasmic, Builder.io, or Webstudio. These products occupy the design-code seam, and allow content teams to build pages without code. In doing so, they create a proprietary layer between your design system and your codebase, which is a real cost. If someone on your team says “we want a React CMS,” find out which of the three they actually mean. The trade-offs vary for each. ![Headless CMS architecture diagram showing API layer between content store and React frontend](https://cdn.refact.co/uploads/2026/08/image_placeholder_1-98.avif) A headless CMS delivers content via API, empowering developers to build custom frontends with modern frameworks like Next.js and Gatsby. · Source: rangle.io ## The Four Setups Behind the Label ### Headless CMS with a database Contentful, Sanity, Strapi, KeystoneJS, and Payload all store content in a managed or self-hosted database, and provide an API for access to that content. This is the correct approach to take when you have actual editorial volume, different content types with relationships, a team that needs previews, roles, and localization, and multiple content types. It also provides the most flexibility of options. The API is as good as the content model, and the content model is as good as the designer. Our traditional call with these platforms centers around managed versus self-hosted options, which is why we published our [breakdown of Sanity vs Contentful](https://refact.co/insights/digital-product/sanity-vs-contentful) and our analysis of Strapi vs Sanity. Choose the platform based on who will own the upgrades as opposed to the provider with the more impressive demo. ### Git-based CMS Decap (formerly Netlify CMS) and TinaCMS both store content in either Markdown or JSON in your GitHub repository. there is no database and every publish is a commit. Decap’s star count is around 19,000 and TinaCMS is 13,700. Both of them work well with static site generators. This is definitely an option for small teams, but is not ideal for any scenario that requires real time collaboration or advanced permissions. ### Full-stack React frameworks The shift of Payload to a Next.js framework is perhaps the most prominent example of a broader pattern. Instead of having your CMS backend and your marketing website backends as separate code bases, you have one unified code base. The pros are reduced moving parts and eliminating CORS problems. The cons are that your marketing site and your CMS become a deployed service, which alters how you have to consider things such as rollbacks, downtime and migrations. This is definitely something you’d want to think about if you are already committed to Next.js. If you aren’t, read our [Next.js operator’s guide](https://refact.co/insights/digital-product/next-js-website) before making that your default assumption. ### Visual builders Builder.io, Plasmic, and Webstudio enable content and marketing teams to construct pages with UI components that are shipped as React. They address a legitimate problem. Developing each landing page requires engineering, which quickly becomes a bottleneck. Using a builder removes that dependency. The cost includes maintaining a design system across a tool and across your codebase, which will diverge over time. Webstudio’s open-source positioning is a testament to the lock-in issue being a legitimate concern. ## Where React CMS Setups Actually Break The pain is not about deciding on a platform. It is about the seam between the CMS and React. The same issues come up almost every time. The most common issue is rendering HTML that is authored in the CMS inside a React App. HTML is returned as a string by rich text fields. React components are the preferred format. The solution, React’s dangerouslySetInnerHTML, creates XSS attack surfaces and breaks both internal links and the React Router. The most viewed question on Stack Overflow regarding parsing HTML to React components has a score of 52 and 7 answers, a truly common problem. A serious decision regarding this issue has to be made on Day 1, before Week 6. The second issue is SEO. A pure client-side rendered React SPA is not the best choice for large public content sites. Google renders JavaScript, but servers render HTML on a lower crawl budget and faster timeline. This is why almost every other bankruptcy in the ecosystem has standardized on Next.js as a rendering framework. If a business relies on Google for customers, a framework that supports server-side rendering or static site generation is a must. The third is about protecting statically generated content with auth. Statically generated sites make pages super fast, but pages are also public by default (because they are generated on the browser). Teams that want page content restricted to members of the team infrastructure use an auth layer within a static site generator, completely defeating the purpose of static site generation. Consider where auth should be applied to your pages before settling on a rendering strategy. The fourth is training. Even with a high-end CMS, a good content publishing system can fail the daily use case if the editors don’t understand publishing. [ELECTE’s analysis of CMS training](https://www.electe.net/post/formazione-cms-linvestimento-nascosto-che-determina-il-successo) establishes a benchmark for this: without adequate training, teams end up using 20 to 30 percent of the features they paid for. A publisher needing engineering support to handle publishing will lead to nothing but regret in your system selection. ## How to Choose Without Regret The choice comes down to three questions in this order. Do editors have the capability to publish completely independently? This is the workflow test. If the answer is no in a demo, it will be no in a production environment. A system that satisfies developers and slows down the content publishing team eventually loses trust, leading to missed deadlines and marketing teams creating their own content in Google Docs. **Who owns the frontend?** A headless setup puts this responsibility on your team. Someone has to take care of rendering, previewing, and deployments as well as router work for CMS-injected links. If you don’t take ownership, a monolithic CMS is usually a better choice, and the honest trade-off in this scenario is explained in [Headless CMS versus Traditional CMS](https://refact.co/insights/digital-product/headless-cms-vs-traditional-cms). **What does the two-year picture look like?** You can’t tell which CMS editors will be using in 2027 by looking at star counts such as 44,000 stars for Payload, 19,000 for Decap, and 13,700 for TinaCMS. These numbers show which projects developers are keeping an eye on. You have to ask what happens when a new content type is added, when a schema is changed, when a plugin stops being maintained, and what happens as a result. ![React CMS admin dashboard showing content editing interface](https://cdn.refact.co/uploads/2026/08/image_placeholder_2-101-scaled.avif) An intuitive content modeling interface, clearly displaying various field types, is essential for a smooth editor experience that content teams will embrace. · Source: payloadcms.com ## What This Looks Like by Business Type Most publishing teams end up using a headless CMS with Next.js, since they need structured content as well as editor previews and search performance without asking developers to modify the layout. The most difficult part of [the Teton Gravity Research rebuild](https://refact.co/work/teton-gravity-research) was not choosing the CMS. The difficult part was migrating 10,000 articles from their ExpressionEngine legacy system, while preserving the editorial workflow that had been in place for over 30 years. The React front end was the easy part. Ecommerce teams typically want a hybrid solution. Transactions can stay in a dedicated commerce system. You can use a React CMS for buying guides and product stories, as well as pages for campaigns, with little difficulty. This works because the two systems can solve different problems, and forcing either to do both tends to make both systems worse. For a lot of product and membership teams, a CMS that lives close to a paywall or member area is extremely helpful. When The Hustle requested that we deploy [their premium newsletter platform](https://refact.co/work/trends) in two weeks, the problem wasn’t the React frontend. The problem was their inability to connect their CMS and payment system, because there had never been a use case to build that integration before. Every new step would create a new gap that would have to be accounted for. In this case, the CMS decision was less important than the integration model. Early stage products need to remain light. Capital C Tina or Capital C Decap is the right option when the site is mostly content and the team is small. The problem isn’t the lack of a CMS, it’s the imaginary content modeling for an imaginary team. ## The Direction of Travel The React CMS space is fragmenting and consolidating at the same time. Next.js is winning the rendering layer, while the server is doing more with React 19.3. Meanwhile, the CMS layer is dispersing to headless APIs, git tools, builders, and frameworks like Payload that support Next.js. The current model of a single React SPA admin dashboard is becoming obsolete with more server-side rendered interfaces and more thin clients. As an operator, the main idea is that the ecosystem hype around React CMS should not influence your decision. Rather, the decision should be focused around how your editors work, how much frontend your team is prepared to manage, and how you plan to render your content to meet your search needs. Where those three points of focus intersect is the ideal choice, and if they point to different tools, then it is not a compromise. It is identifying which constraint becomes a decisive point for the business. If you are trying to decide which of the four options to go with before you make a decision, our [headless CMS development services](https://refact.co/services/headless-cms) are built to help make the early decisions in this area, and it is easier to make those changes now rather than after the migration. ## FAQ ### Is a React CMS the same as a headless CMS? Not exactly. A headless CMS is any content system that exposes an API and leaves the frontend to you. A React CMS usually means one of three things: a headless CMS consumed by a React or Next.js frontend, a CMS whose admin panel is built in React (like Payload or KeystoneJS), or a visual builder that outputs React (like Builder.io or Plasmic). The setups have different trade-offs, so it matters which one you mean. ### Do I need Next.js to use a React CMS? Technically no, but practically yes for most public sites. A pure client-rendered React SPA is a weak fit for content that needs to rank in search. Next.js gives you server-side rendering and static generation, which is why the ecosystem has consolidated on it as the default rendering layer for headless CMS work. ### How do I render HTML from a CMS inside React components? Use an HTML-to-React parser rather than dangerouslySetInnerHTML wherever possible. The parser converts CMS-authored HTML into real React elements, which keeps router links working, avoids XSS surface area, and lets you replace specific tags with your own components. This is the single most common integration problem in headless React work. ### Is Payload CMS worth using in 2026? It is worth serious consideration if you are already committed to Next.js. Payload has repositioned as a full-stack Next.js framework, so the CMS admin, API, and frontend share one codebase. That reduces moving parts but couples deployment and rollback. If your stack is not Next.js, a more decoupled headless setup like Sanity or Strapi is usually a better fit. ### When does a git-based CMS like TinaCMS or Decap make sense? For small teams, documentation sites, portfolios, and marketing sites where content changes weekly rather than hourly. Git-based CMSs store content as Markdown or JSON files in your repo, which is simple, versioned, and cheap. They break down when you need real-time collaboration, granular permissions, or an editorial workflow with more than a few people in it.