Payload CMS in 2026: what it is, Payload 4 and comparison

In 2026, when someone is deciding what to build their website with and wants something more modern than the usual CMS, one of the names that comes up is Payload CMS. It's not a plugin or a template: it's a different way of understanding what a content management system is, designed from day one for people who build custom websites and applications. In Next.js vs WordPress we explain when a custom site is worth it; here we answer what comes next: what Payload is, how it works, which version to use today and how it differs from the rest of the options, from classic WordPress to other headless CMSs like Strapi or Sanity.

What Payload CMS is

Payload CMS is an open-source content management system, written in TypeScript, that works as a headless CMS and installs inside a Next.js application. It's a CMS, like WordPress, but designed for developers, and its underlying difference boils down to two words: code-first. In most CMSs, to create a new section —say, a product catalogue— you click through options in a panel. In Payload, that structure is written directly in the project's code, and from there the system builds everything else on its own.

What does it build "on its own"? Three things:

1. The admin panel, where editors write and upload content, with its visual look already in place.
2. The store where the data is kept (the database).
3. The connections that let your website —or a mobile app, or any other system— request that content and display it.

The word headless describes exactly that: Payload takes care of the content, but doesn't decide how it looks. You build the site's design separately, usually with Next.js —the technology behind many modern websites, this one included—. It's the opposite of WordPress's classic model, where the same system both stores the content and draws the page.

The game-changer arrived with Payload 3.0: it was the first CMS that installs inside the Next.js site itself, instead of running as a separate program. In practice, the panel, the data store and the public site live in a single project and ship together. Today the stable branch is still 3.x, while 4.0 is being tested in canary builds; we go into detail below.

A note that brings some peace of mind about its future: Payload is free and open source —anyone can use and modify it, under the MIT license— and, since June 2025, is part of Figma, the well-known design tool. It's still free and you can host it wherever you want, but now with a large company behind it.

How it works under the hood

The best way to grasp it is to see how short it is to create a section. This snippet of code defines a blog posts section, with its title, body, author and date:

export const Posts = {
  slug: 'posts',
  fields: [
    { name: 'title', type: 'text', required: true },              // title
    { name: 'content', type: 'richText' },                        // article body
    { name: 'author', type: 'relationship', relationTo: 'users' }, // author
    { name: 'publishedAt', type: 'date' },                        // date
  ],
}

You don't need to understand every line; just take away the idea: with a few lines, Payload already knows how to build the panel form, save the data and make it available to the site. That definition is the "source of truth", and everything else is generated from it. If tomorrow you add a field, the panel and the store update themselves.

The pieces worth knowing, in plain terms:

• The database, your choice. Payload doesn't force you to use a specific technology to store the data: it works with the most common ones (it's database-agnostic: MongoDB, PostgreSQL or SQLite). Translation: you can use the one you already have or the one that fits best, without changing CMS.
• Users and permissions included. It ships with sign-up and login and very fine-grained control over who can see or edit each thing, down to a single field within a record.
• Image and file management. It uploads images, crops and resizes them on its own to the sizes you define, and lets you organise them in folders, with no need for extra programs or services.
• Automatic tasks. It can handle jobs that take time or repeat —sending emails, processing things overnight— without slowing the site down, something uncommon in CMSs of this kind.
• Content ready for any screen. It serves content over REST and GraphQL APIs so a website, a mobile app or another system can consume it; and because it lives inside Next.js, the site can request it directly, without going over the network, and load faster.

Payload CMS versions: stable 3.90 and 4.0 in canary

As of 9 October 2026, the latest stable version of Payload is 3.90.2, released on 23 September 2026, and it's the one to use in production. Payload 4.0 already exists, but only as canary builds: the latest is 4.0.0-canary.39, from 8 October, and there's still no beta and no date for the stable release. Both are published on npm: 3.x under the latest tag, the one installed by default, and 4.0 under the canary tag.

What's new in Payload 3.x

The 3.x branch still gets releases almost every week. The highlights of 2026, according to the official release notes:

• Next.js 16 support (3.73, January).
• Stable MCP plugin (3.78, February). The MCP plugin leaves beta and lets compatible AI assistants, such as Claude Code, query and edit CMS content through API keys. If MCP sounds like gibberish, we explain it in how to connect Claude Code to your tools. In the same release, the document trash leaves beta too.
• Projects ready for AI agents (3.83, April). The create-payload-app installer accepts an --agent option (Claude, Codex or Cursor) and installs Payload's instructions for the coding assistant.
• Stable content import and export (3.85, May).
• Stricter permissions for background jobs (3.89, September). It brings a 4.0 change forward to 3.x and may break compatibility, so read its notes before upgrading.
• Critical security patch (3.90.0, 18 September). It fixes a batch of vulnerabilities, several of them critical, and the team asked everyone to upgrade as soon as possible. After installing it you need to regenerate your types and, with SQL databases, create and run a migration.

Payload 4.0 in canary: what it is and what changes

A canary build is published straight from the main development branch, with the latest merged work and without the guarantees of a stable release. Payload 4.0 canaries have been landing on npm since June 2026, and the project's own versioning policy is clear: canary and beta builds make no compatibility promises to each other, and the migration guide only covers the jump between stable versions.

This is what it brings, according to the official early look from June and the 3.0 to 4.0 migration guide:

• Redesigned admin panel. It's being rebuilt on a design system with semantic tokens, without Sass and with better Tailwind compatibility, and comes with new navigation, a refreshed home dashboard and many accessibility improvements. The goal, in the team's words, "is not to change how Payload works".
• Beyond Next.js. The core is separated from the framework through adapters. Next.js remains the main one and TanStack Start is the first alternative, already published in canary.
• Secure by default. The Local API —the one you call from your own server code— now enforces access control unless you say otherwise (overrideAccess defaults to false), and background jobs apply permissions out of the box too.
• New defaults. Collections keep version history and record who created or modified each document (createdBy and updatedBy) with no configuration, and queries populate one level of relationships instead of two, which makes responses lighter.
• Files and media. Image resizing with Sharp moves out of the core into its own package, image sizes are renamed variants, every file keeps its original and its history, and a shared foundation arrives for organising content into folders, tags and taxonomies.
• Built-in AI. The MCP plugin is reworked to run with minimal configuration, instructions for language models are managed from the panel, and the migration tool includes a mode assisted by AI agents.
• What's going away. The Slate editor disappears (Lexical remains the only rich text editor), along with the APIs flagged as deprecated, and the minimum requirements go up: Node.js 24.15, Next.js 16.4 and TypeScript 6.0.3.

To migrate, Payload provides a codemod, a tool that rewrites your code automatically (npx @payloadcms/codemod). It handles most of the changes and can be run several times on a partially migrated project without risk.

When is Payload 4 coming out, and should you use it now?

There's no official date for the stable release. In June 2026 the team wrote that it was "targeting a 4.0 beta within the next quarter"; as of 9 October we're still in canary and no beta has been published. Our recommendation:

• Sites in production: stay on 3.x and, at the very least, on 3.90.0 for the security patches. The branch keeps getting fixes: September's security advisory shipped at the same time for 3.90.0 and for 4.0.0-canary.34.
• Projects starting now: start on 3.x and write the code with 4.0 already in mind —for example, setting overrideAccess and depth explicitly in your queries— so the migration becomes a formality.
• If you still use the Slate editor: migrate to Lexical first. The official guide says not to upgrade to 4.0 until you have.
• To evaluate 4.0: on a separate branch or a staging environment, with every @payloadcms/* package on the same canary version, and never on the production server.

Payload CMS vs WordPress: quick comparison

If you only have a minute, this table sums up the differences with the most widespread CMS. In bold, the stronger option for each criterion:

The rest of the article breaks down the rows that weigh most in a real decision.

Two opposite philosophies

WordPress was born as a system for publishing without knowing how to code, and that's still where its strength lies. It's a monolith: the same PHP server stores the content in a MySQL database and generates the public page on every visit, relying on a theme and whatever plugins you have installed. Anyone can write an article, upload a photo or change a text from a visual panel without touching a line of code.

Payload flips the starting point. It assumes there's a developer building the site and gives them superpowers: define the content model in code and get in return a complete backend and an admin panel without writing them by hand. Content is separated from presentation, and the frontend —usually Next.js— decides how and when to show it, with the option of serving it ready-made from a CDN.

The consequence is direct: WordPress optimises the experience of whoever edits content; Payload optimises that of whoever builds the site. Almost every other difference stems from that original decision.

Content editing

Here WordPress keeps its historical edge. With AI built into the core since version 7.0 and what 7.1 added in August 2026 —design that adapts to each screen size without writing CSS, a revamped image editor and notes for commenting on content as a team—, the editorial experience is comfortable from minute one and requires nothing technical at all. For a client who publishes daily and wants full autonomy, it's hard to beat.

Payload isn't far behind, with one important nuance: its panel is also visual and pleasant to use, once a developer has configured it. The text editor, custom fields and reusable content blocks offer a modern, highly polished experience. The difference isn't in the editor's day-to-day, but in the starting point: in WordPress you install and start editing; in Payload someone prepares the content structure first.

Two recent pieces also bring that experience closer to a top-tier visual CMS. The text editor uses Lexical —Meta's editing technology—, which lets you embed interactive elements inside the text itself. And Live Preview lets the editor see the exact final design as they type, with no surprises between what they edit and what gets published.

The screenshot sums up the difference well: the editor doesn't fill in fields blindly, but works on the final page, moving and editing blocks directly where they'll be seen.

Performance and security

On performance, Payload starts with Next.js's advantage: it can prepare pages ahead of time and serve them from the CDN, without running code or querying the database on every visit. Excellent Core Web Vitals come almost by default —we go into it in our practical Core Web Vitals guide—. WordPress can be fast, but it demands ongoing work: caching, image optimisation, plugin discipline and good hosting.

The same happens with security. A site built with Payload and Next.js can publish its public part as ready-made pages, with no exposed login panel or externally accessible database. WordPress, being the most popular CMS in the world, concentrates most of the automated attacks against content managers, and its weak point is usually the third-party plugin ecosystem. It's not that WordPress is insecure, but that it demands recurring vigilance that someone has to do and budget for.

It's worth being fair both ways. In Payload's favour: it ships with access control, secure sessions and attempt limiting out of the box, no plugins. Against it: being code-first, you're the one who defines the rules of who can see what, and if you don't declare them you can leave a sensitive field exposed. And it isn't infallible: as of 9 October 2026, the project has published 49 security advisories this year, eight of them critical, most of them in September and October, affecting both the core and official plugins; all of them are fixed from version 3.90.0 onwards. The advantage over the monolith isn't the absence of flaws, but a smaller attack surface and patches that come from the team itself, with no third parties involved. Someone still has to apply them, though.

Ecosystem and maturity

And this is where WordPress hits back. Two decades of history translate into a colossal ecosystem: tens of thousands of plugins and themes, a huge community, tutorials for any question and professionals in every city. If you need a store, a booking system or an online campus, there's almost certainly a plugin that solves it today.

Payload is young by comparison, though it's growing fast: its GitHub repository has over 45,000 stars, in June the team said it had gone from roughly 100,000 to over 400,000 weekly downloads since September, and in the first week of October 2026 npm recorded 978,799 downloads. Figma's backing gives it stability, but there's no "plugin for everything": what in WordPress is install-and-configure, in Payload is often develop. For a technical team that's an advantage (full control, no third-party surprises); for someone looking to set up something standard without development, it's a cost.

Governance and sovereignty

There's a factor that didn't use to appear in these comparisons and now does: who controls the platform. WordPress's governance is highly centralised around Automattic and its co-founder, and the 2024 crisis with WP Engine —with access to the official plugin and update repository blocked— showed that a corporate dispute can affect millions of sites. With Payload, the entire configuration lives in your own project under the MIT license and you don't depend on a central repository to run or to update security: control over your site is total.

Payload versus other headless CMSs

WordPress is just one of the alternatives. If you've already decided you want a headless CMS, the relevant comparison is with the sector's other heavyweights: Strapi, Sanity and Contentful. Each solves the same problem differently.

• Strapi, now on version 5, is the most direct open-source rival, but it keeps the classic model of two separate programs —the CMS on one side and the site on the other—, with the added slowness of having them talk to each other over the network. Payload avoids that hop by living inside Next.js. Also, Strapi only works with SQL databases, whereas Payload supports MongoDB too.
• Sanity is excellent for highly structured content and real-time teamwork, and it also defines content in code. The big difference is the model: it's a cloud service, your data lives on its servers and the bill grows per user and per usage; there's a free plan, but the Growth plan costs $15 per user per month. You host Payload yourself, so control of the data is yours —non-negotiable in healthcare, banking or public administration—. Sanity is also queried mainly with its own language, GROQ; Payload uses industry standards, REST and GraphQL.
• Contentful is the option for large corporations: very powerful, but with a price and complexity that make it disproportionate for most projects.
• Lighter options like Keystatic store content as plain text files inside the project: perfect for documentation or simple blogs, but they fall short as soon as you need users, permissions or lots of interrelated data, where Payload plays in another league.

In short: against the paid services (Sanity, Contentful), Payload wins on control and cost; against Strapi, on Next.js integration; and against the simpler options, on power for real applications.

Payload and Figma: what has changed since the acquisition

On 17 June 2025, its creator and CEO, James Mikrut, announced that Payload was joining Figma, with the same team leading the project. For anyone evaluating it, two things matter. First: the core remains open source under the MIT license, and Figma has committed to maintaining and investing in it. Second: deploying new projects on Payload Cloud is paused; existing ones keep running as normal and the team is preparing a replacement they'll be able to migrate to. In practice, Payload deploys anywhere a Next.js app runs, from Vercel or Cloudflare to your own server; we compare the options in where to deploy Next.js.

The logic of the deal explains where the product is heading. Payload defines content in code, with a structure that closely resembles a design system, and Mikrut put it this way in the announcement: "We will integrate with design systems in ways no other CMS can." The bet is that the components and styles created in Figma translate into content structure in Payload, cutting the eternal back-and-forth between whoever designs and whoever codes. There's no concrete integration released yet: in June 2026 the team spoke of deeper integrations between the two products and framed the 4.0 admin redesign as part of that convergence.

When to choose Payload

• Technical team that wants full control and end-to-end TypeScript: Payload. The code-based content model is a joy to develop and maintain.
• Non-technical client who publishes daily and wants autonomy: WordPress. Editing with no prior development is still its great asset.
• Custom site or app on Next.js that also needs a content panel: Payload. Living inside the same project, it avoids the glue between CMS and site.
• Project that leans on very specific ready-made functionality (memberships, courses, complex bookings): WordPress, unless you want to build those systems from scratch.
• Digital product, portal with fine-grained roles and permissions, or the backbone of an app: Payload. Its detailed access control is among the best on the market.
• Sectors with sensitive data (health, finance, government): Payload, for being able to remove the exposed panel and the public database, and for keeping the data on your own server.

And what about headless WordPress (using WordPress only as a content store and Next.js as the site)? It's a legitimate alternative, but there you still drag along two systems and two deployments; Payload unifies everything into a single project on Next.js. If you already live in the JavaScript ecosystem, that unification is its biggest argument.

Conclusion: is Payload CMS for you?

There's no universal winning technology, there are projects and profiles. Payload CMS shines when the person in charge is the one building: full control, end-to-end TypeScript, out-of-the-box performance and security, and a complete backend that lives inside your own Next.js app, with the data always under your control. Against WordPress it wins when the team is technical and performance matters; against the paid cloud CMSs (Sanity, Contentful), on control and cost; against Strapi, on Next.js integration. And if you go for it, today that means starting on the stable 3.x and leaving 4.0 until it's out of canary.

Our way of deciding it is simple: we look at who will have their hands on the site day to day and how much the content weighs against custom functionality. In our web development service we start from that question before recommending anything, and in our projects you can see different approaches running in production.