But the Payload team recently shared an early look at what they are working on for the next major version. This was not a stable release announcement. It was more of a product update and community preview showing the direction Payload 4.0 is likely heading.
That distinction matters.
This page is a living tracker for Payload 4.0. I will update it as the beta, release candidates, migration guide, breaking changes, and stable release notes become public.
For now, based on the public Payload update, Payload 4.0 looks like a major maturity release. The focus is not just one feature. It is a wider improvement across the admin UI, design system, content hierarchy, digital asset management, AI workflows, and framework support.
The biggest areas previewed so far are:
A redesigned Payload admin UI
Better styling tokens and theming
Improved Tailwind compatibility
Native hierarchies, folders, and tags
Better digital asset management features
Improved MCP setup and AI agent workflows
Payload Skills for coding agents
Experimental TanStack Start support
A broader framework adapter pattern
Possible breaking changes around styling, folders, and plugin configuration
Let’s go through what is known so far.
Current Payload 4.0 status
Payload 4.0 is currently not stable.
The Payload team described the 4.0 work as still being in progress. In the video, they referred to the current branch as pre-alpha and specifically warned people not to build production projects on the main branch.
That means Payload 4.0 should be treated as something to watch, test, and prepare for, not something to adopt in production today.
The useful way to think about it is this:
Payload 3 is the current production version.
Payload 4 is the next major version being actively developed.
Payload 4 beta is expected before stable.
Payload 4 stable will need official release notes and a migration guide before most production teams should seriously consider upgrading.
If you are building a real client project today, Payload 3 is still the safer choice. If you are maintaining a Payload project or planning a larger migration in the next few months, Payload 4 is worth watching closely.
Why Payload 4.0 matters
Payload 3 was a huge architectural release.
Payload moved much closer to Next.js, became more deeply integrated with the App Router world, and changed how developers think about Payload as a full-stack CMS and application framework.
Payload 4.0 seems different.
From what the team previewed, this release is less about a single architectural leap and more about making Payload feel more complete, more polished, and more scalable for real teams.
That matters because Payload is no longer only used by developers experimenting with a headless CMS. It is increasingly used for:
Marketing websites
Enterprise content platforms
Ecommerce backends
SaaS admin tools
Digital asset management
Multi-tenant applications
Internal tools
AI-assisted content workflows
Client-managed websites
For those use cases, the admin experience matters as much as the developer experience.
Developers may choose Payload because it is TypeScript-first and code-first. But clients, editors, and content teams judge the product through the admin panel. If the admin UI feels clearer, more modern, and easier to customize, Payload becomes easier to sell and easier to adopt.
That seems to be the real story of Payload 4.0.
1. Payload admin UI redesign
The most visible change coming in Payload 4.0 is the admin UI redesign.
The Payload team showed early design work for a cleaner, more capable admin interface. The goal is not to completely change how Payload works. The goal is to keep the same core mental model, but make the admin panel feel more consistent, polished, and easier to use.
The preview included work on:
List views
Edit views
Field styling
Focus states
Rich text editing
Drawers
Modals
Upload views
User menu
Sidebar
Table cells
Bulk action toolbar
Accessibility states
This is important because the current Payload admin UI is powerful, but it can feel very developer-first. That is not always a problem. But when Payload is used for client projects, marketing teams, or enterprise content workflows, small UI details matter a lot.
A cleaner admin UI can make Payload easier to explain, easier to hand over, and easier for non-technical users to trust.
2. Better hierarchy and density in the admin panel
One theme in the preview was hierarchy.
Not content hierarchy yet, but visual hierarchy.
The Payload team talked about improving how the admin UI communicates structure, state, and action. This includes cleaner table cells, more readable list views, better status indicators, and more consistent layouts across views.
For example, the preview showed status pills in list views, a floating toolbar for bulk actions, and cleaner field presentation in edit views.
That sounds minor, but it is not.
In a CMS, editors spend a lot of time scanning lists. They need to know what is published, what is draft, what belongs where, and what needs action. If the UI makes those states easier to parse, the CMS feels faster even before any technical performance changes happen.
For developers building custom Payload projects, this could also reduce the amount of custom admin work needed. If the default admin panel becomes more polished out of the box, there is less pressure to redesign everything for every client.
3. Semantic design tokens and theming
Payload 4.0 also appears to include a deeper styling and design system cleanup.
The team talked about moving toward stronger semantic tokens and getting rid of Sass. The goal seems to be a more consistent design foundation across the admin panel.
This matters for two reasons.
First, it should make the Payload admin UI easier to maintain. Instead of relying on many one-off styles or raw color ramps, semantic tokens give the UI clearer meaning. A token like a brand background, surface color, border color, or text color is easier to reason about than a random shade from a color scale.
Second, it should make Payload easier to customize.
Many agencies and product teams want the Payload admin panel to feel branded. That does not always mean a full white-label redesign. Sometimes it simply means using the client’s primary color, matching the product’s visual language, or making custom components feel native.
Payload 4.0 appears to be moving in that direction.
The team also mentioned primary color theming, which has apparently been a frequent community request. If this lands cleanly, it could make simple admin theming much easier than before.
4. Better Tailwind compatibility
Another interesting detail from the preview was Tailwind compatibility.
Payload 4.0 is expected to make Tailwind easier to use with the admin panel by using a Tailwind-style reset approach and reducing conflicts.
This is a practical improvement.
Many modern Payload projects already use Tailwind on the frontend. Developers building custom admin components often want to reuse similar styling patterns. But if the admin panel has its own styling assumptions, resets, or conflicts, custom components can become annoying to maintain.
If Payload 4.0 makes Tailwind easier to use inside admin customizations, that could improve the developer experience for:
Custom fields
Custom views
Admin widgets
Dashboard components
Plugin UIs
Internal tools built inside Payload
This is especially relevant for teams that use shadcn/ui, Tailwind, and React component systems across their application.
5. Improved drawers and modals
One of the most practical UI improvements shown was the redesign of drawers and modals.
The current drawer experience in Payload can become visually heavy, especially when drawers stack or take up too much space. In the preview, the team showed a fixed-width drawer pattern where the content underneath remains visible and the drawer stack shifts in a more predictable way.
This is a small detail with a big workflow impact.
Payload projects often rely on relationship fields, nested editing, media selection, and linked documents. That means editors frequently open drawers while they are already working inside another document.
If drawers become easier to follow, editors can keep more context while editing related content.
The team also showed better modal patterns, including more focused interactions for things like image cropping and focal point editing. This suggests Payload 4.0 is not just making the admin panel prettier. It is improving interaction patterns that editors use every day.
6. Rich text and Lexical improvements
The Payload team also showed UI work around Lexical, Payload’s rich text editor.
The preview included cleaner menus, improved selection styling, and a more polished rich text editing surface. The stated ambition was to make the editor feel like one of the best editing surfaces on the internet.
That is a high bar, but it is the right area to focus on.
For many CMS users, the rich text editor is the CMS. They may never care about hooks, access control, GraphQL, database adapters, or deployment architecture. They care about whether they can write, format, link, insert blocks, and edit content without friction.
If Payload 4.0 improves Lexical’s usability and visual consistency, that could make a real difference for editorial teams.
This is especially important for content-heavy websites where editors frequently work with:
Blog posts
Landing pages
Documentation
Product content
Case studies
Legal pages
Help center content
A better rich text editing experience makes Payload more convincing as a long-term CMS choice.
7. Upload views and media previews
Payload 4.0 also appears to include major work around upload-enabled collections.
The team showed an improved upload view where media is not reduced to a tiny thumbnail. Instead, the idea is to give uploaded assets a more useful preview and more room in the admin UI.
The preview mentioned:
Larger image previews
Better upload detail views
Image sizes
PDF previews
Video player controls
Possibly better handling for other media types
This matters because many teams already use Payload as a media library or lightweight digital asset management system.
If you are managing images, PDFs, videos, product assets, brand files, or localized documents, the quality of the media UI becomes very important. A tiny thumbnail is not enough when the CMS is also the asset source of truth.
Better media previews make Payload more useful for real content teams.
8. Digital asset management improvements
Digital asset management, or DAM, was one of the bigger themes in the update.
Payload already has features that make it useful as a DAM, but the team seems to be planning a more serious push in this direction for Payload 4.0.
The preview mentioned several possible or planned DAM improvements:
Better file previews
PDF previews
Video previews
MP3 or audio handling
Localized files
File versioning
Better documentation around asset features
On-demand image resizing
Expiring share links
Usage references
These would make Payload stronger for companies that manage many assets across many channels.
The most interesting ones are localized files, file versioning, and usage references.
Localized files would allow teams to upload different files for different languages. That is useful for marketing teams, legal documents, product sheets, manuals, and international websites.
File versioning would make it safer to replace assets without losing the old file. This is useful when documents, images, or videos change over time.
Usage references would help teams understand where an asset is used before deleting or replacing it. That is extremely important in real content operations. Nobody wants to delete an image and accidentally break ten landing pages.
If these DAM improvements land well, Payload could become more attractive not only as a CMS, but as a central content and asset platform.
9. Native hierarchies, folders, and tags
One of the most important Payload 4.0 features previewed is native hierarchy support.
Payload already has folders in beta, and many developers have used the nested docs plugin for hierarchical content. But Payload 4.0 seems to be taking the idea further by making hierarchies a more serious primitive in Payload core.
The team talked about hierarchies as something useful beyond nested pages.
That is the key point.
Hierarchies can support:
Page trees
Folder structures
Taxonomies
Tags
Asset organization
Product categories
Documentation sections
Campaign groupings
Multi-level content structures
The preview showed folders and tags as first-class patterns built on top of this hierarchy concept.
Folders appear to work as a way to place a document in one location. Tags appear to work as a way to associate a document with multiple hierarchical concepts.
That distinction is useful.
A folder answers: where does this document live?
A tag answers: what is this document related to?
For example, a product image might live inside a folder for a specific campaign, but also be tagged with season, product line, region, and asset type.
That kind of organization matters a lot when projects grow.
10. Why hierarchies matter for real Payload projects
Native hierarchies could become one of the most important practical features in Payload 4.0.
Flat collections are fine at the beginning of a project. But once a project grows, editors often struggle to find content.
They may have hundreds or thousands of documents across:
Pages
Blog posts
Case studies
Products
Media files
PDFs
Campaigns
Authors
Categories
Translations
Search helps, but search is not always enough. Sometimes editors do not know the exact title of the document. They remember the section, category, campaign, product line, or folder where it belongs.
A tree-based UI can make that much easier.
This also makes Payload more competitive with traditional CMS systems where editors expect some kind of content tree, media folder, or taxonomy browser.
Developers may prefer clean database models. Editors often prefer navigable structures.
Payload 4.0 seems to be trying to support both.
11. Possible replacement path for nested docs
The Payload team also talked about the nested docs plugin.
The important point is that hierarchies may eventually replace the need for the nested docs plugin in many cases.
That does not mean every existing nested docs project will magically migrate without work. We do not yet have the official migration guide or final API.
But it does suggest that Payload 4.0 is moving this kind of functionality closer to core.
This is worth watching if your project currently uses nested docs for:
Nested pages
Slug paths
Parent-child content
Documentation structures
Website navigation
Before upgrading to Payload 4.0, nested docs users should pay close attention to official migration notes.
12. Sidebar tabs and custom sidebar components
Another interesting part of the preview was the new sidebar tab pattern.
The team showed folders and tags as sidebar tabs, but also mentioned that developers could add their own custom sidebar elements.
That could be very useful for plugin developers and advanced Payload projects.
Possible use cases include:
Favorites
Recent documents
Workflow queues
Review tasks
Campaign dashboards
Asset libraries
Custom navigation trees
Multi-tenant navigation
Product catalog navigation
Plugin-specific panels
This is exactly the kind of admin extensibility that can make Payload powerful.
If the sidebar becomes a more flexible extension point, Payload plugins can feel more deeply integrated into the admin UI instead of being hidden behind collection lists or custom routes.
13. MCP improvements
Payload already has an MCP plugin, but the setup today requires manual configuration.
In the current model, developers need to create an API key, configure MCP client access, and decide which collections and globals the MCP server can interact with.
In the Payload 4.0 preview, the team talked about making MCP much easier to use, especially during local development.
The goal seems to be:
Easier installation
Better defaults
Opt-out instead of opt-in during development
Less manual API key setup locally
Better schema handling
Better support for complex documents
Smaller dependencies
Better production readiness
This is important because MCP can let AI agents interact with Payload projects more directly.
Instead of an AI coding tool only reading code, MCP can potentially help it understand and work with actual Payload content structures, collections, globals, fields, and documents.
For developers using AI tools, this could become a serious advantage.
14. Why MCP matters for Payload
Payload is already a good fit for AI-assisted development because the configuration is declarative and TypeScript-first.
Collections, fields, globals, access control, hooks, and admin behavior are all described in code. That gives AI tools a structured system to reason about.
But AI tools still make mistakes.
They can invent APIs, miss required fields, misunderstand relationship structures, or generate code that looks plausible but does not match Payload conventions.
Better MCP support could reduce those mistakes by giving agents better access to the actual shape and capabilities of a Payload project.
This could help with tasks like:
Creating documents
Updating content
Inspecting collections
Understanding custom schemas
Working with globals
Testing content workflows
Generating seed data
Assisting with migrations
Debugging schema issues
The big question is how safe and reliable this becomes in real projects. But directionally, it makes sense.
Payload’s code-first architecture and MCP are a natural fit.
15. Payload Skills for AI agents
The team also discussed Payload Skills.
Payload Skills are instructions and references that coding agents can load to better understand how to work with Payload projects.
This is different from MCP.
MCP gives an agent tools and access to interact with a Payload project.
Skills give an agent guidance on how to write better Payload code.
The Payload team mentioned that they are collecting failure cases where AI agents get Payload wrong. For example, an agent might miss a required config property, invent a fake API, or fail to use an existing Payload feature correctly.
By collecting these failure cases and running evals, the team can improve the skills over time.
This matters because AI-assisted development is becoming part of normal developer workflow. If Payload provides strong first-party guidance for agents, developers may get better results when building collections, hooks, access control, plugins, and admin customizations.
In practical terms, better Payload Skills could mean fewer hallucinated APIs and more correct generated code.
16. TanStack Start support
One of the biggest technical previews was Payload running with TanStack Start.
Payload 3 is strongly associated with Next.js. That was one of the major shifts in Payload 3. But the team made it clear that the long-term plan is not necessarily to support only Next.js forever.
The TanStack demo showed Payload’s admin panel running outside of Next.js, using TanStack Start, TanStack Router, and Vite.
This is still experimental.
The demo had visible styling issues, and the team was clear that there is still work to do. But the direction is important.
It suggests that Payload 4.0 may introduce a framework adapter pattern that makes Payload less tightly coupled to one framework.
17. Why framework adapters matter
Framework adapters could become a major long-term shift for Payload.
Payload needs certain capabilities from a framework. It is not just a static site. It needs dynamic rendering, API endpoints, server logic, authentication, and admin UI rendering.
Next.js provides those capabilities, which is why Payload 3 moved deeply into the Next.js ecosystem.
But not every developer wants to use Next.js for every project.
Some teams prefer:
TanStack Start
Vite-based architectures
Different routing models
Different deployment targets
More control over server behavior
Less coupling to the Next.js ecosystem
If Payload can support multiple frameworks through adapters, it becomes more flexible.
That does not mean every framework will be supported. Payload still needs the framework to provide the right primitives. But TanStack support would be a meaningful first step.
For developers who like Payload but do not want every project to be a Next.js project, this is one of the most interesting things to watch.
18. Payload 4.0 and Next.js
Payload 4.0 does not appear to be moving away from Next.js.
That is important.
The point of the TanStack demo is not that Next.js support is going away. The point is that Payload may become more framework-flexible.
Next.js will likely remain the safest and most mature choice for Payload projects for some time, especially for production work.
But the existence of a framework adapter pattern could make the ecosystem healthier. It gives Payload more room to grow and gives developers more architectural options.
For now, I would still treat Next.js as the default production path for Payload. TanStack support is exciting, but it should be considered experimental until Payload officially documents and supports it.
19. Possible breaking changes in Payload 4.0
Payload 4.0 is a major version, so breaking changes are likely.
However, not all breaking changes are confirmed yet. Until the official migration guide exists, it is better to talk about possible migration areas rather than definite breaking changes.
Based on the preview, the areas to watch are:
Admin UI styling
Sass-based customizations
Custom admin CSS
Custom fields and admin components
Tailwind integration
Folder configuration
Nested docs usage
Hierarchy configuration
If your project heavily customizes the Payload admin panel, Payload 4.0 may require more careful testing.
If your project uses Payload mostly out of the box, the migration may be simpler, but it is too early to know.
20. Should you start a new project with Payload 4.0?
Not yet.
Payload 4.0 is not stable. The team previewed active work, but they also made it clear that things are still changing.
For production projects, Payload 3 is still the safer option.
You should consider Payload 4.0 today only if you are:
Testing in a throwaway project
Exploring the main branch
Giving feedback on RFCs
Building internal knowledge for a future migration
Evaluating future architecture decisions
Preparing content for a future upgrade
You should not build a production client project on Payload 4.0 until there is an official stable release or, at minimum, a beta that you are comfortable testing against.
21. Should existing Payload projects prepare for 4.0?
Yes, but carefully.
If you maintain a Payload project, this is a good time to audit where your project depends on parts of Payload that are likely to change.
The main areas I would review are:
Custom admin styles
Custom admin components
Custom fields
Rich text customizations
Upload collections
Media workflows
Nested docs
Folder usage
Plugin usage
MCP setup
Next.js-specific assumptions
You do not need to migrate anything yet. But knowing where your project is most coupled to Payload internals will make the eventual migration easier.
For client projects, I would also start tracking whether Payload 4.0 might solve problems you currently work around manually.
For example:
Do you use custom media previews?
Do editors complain about finding content?
Do you need better asset organization?
Do you want branded admin theming?
Do you need better AI-assisted content workflows?
Do you use nested docs in a way that could become native hierarchies?
Those are the areas where Payload 4.0 could be especially useful.
22. Payload 4.0 vs Payload 3
Payload 3 was mainly an architectural milestone.
Payload 4.0 looks more like a product maturity milestone.
A simple way to compare them:
Payload 3 made Payload more deeply integrated with the modern Next.js full-stack model.
Payload 4 seems focused on making Payload more polished, extensible, editor-friendly, AI-friendly, and potentially framework-flexible.
That does not mean Payload 4 is smaller. It may actually be very significant. But the significance is different.
Payload 3 changed the foundation.
Payload 4 may improve the experience of actually using that foundation at scale.
23. What developers should watch next
Before making any decisions around Payload 4.0, watch for these updates:
Official Payload 4.0 beta announcement
Official migration guide
Confirmed breaking changes
Stable release notes
Admin UI customization docs
Hierarchy and folder docs
DAM improvement docs
MCP plugin docs for 4.0
TanStack adapter docs
Plugin compatibility notes
The most important thing will be the migration guide.
Until that exists, any article about breaking changes has to stay cautious.
24. My early take
Payload 4.0 looks promising because it focuses on the right problems.
Payload already has strong developer fundamentals: TypeScript, code-first configuration, access control, hooks, local API, REST, GraphQL, auth, uploads, and framework integration.
The weaker side has often been the final polish of the admin experience, especially for non-technical users and large content teams.
Payload 4.0 seems to address that.
The admin UI redesign, hierarchy support, DAM improvements, and theming work all move Payload closer to being a serious CMS for larger teams, not just a flexible developer tool.
The AI work is also interesting. Payload’s declarative structure makes it a strong candidate for AI-assisted development, and first-party work around MCP and Skills could make that advantage more obvious.
TanStack support is more experimental, but strategically important. Even if most production teams continue using Payload with Next.js, framework adapters could make Payload feel less locked into one ecosystem.
25. Final thoughts
Payload 4.0 is not out yet, but it is worth paying attention to.
Based on the public preview, this release is likely to focus on admin UI quality, better customization, native content organization, stronger asset management, improved AI workflows, and early support for framework flexibility beyond Next.js.
For production projects, stay on Payload 3 for now.
For future projects, start watching Payload 4 closely.
And if you already build with Payload, now is a good time to follow the RFCs, test the early work in a separate project, and prepare for the migration areas that are most likely to affect your codebase.
This page will be updated as Payload 4.0 moves from preview to beta and eventually to stable release.
