Headless CMS and Visual Editing have a long-standing love-hate relationship. Our approach to is aimed at making it dead easy for developers to implement Visual Editing in DatoCMS, to let content editors get the WYSIWYG effect seamlessly. Combined with draft mode and real-time updates, making changes is a breeze. No more hunting through record forms to find the right field.
Invisible metadata in API responses is a much cleaner path than iframe sandboxing. Most headless CMS visual editors add a rendering layer that fights the frontend framework instead of working with it. The ContentLink component approach keeps the editing surface native to whatever stack you're already on, which means editors don't hit that weird lag between clicking and seeing the right field. Smart move shipping it on every plan including Free.
It seems to me that soon all CMS platforms will be enhanced with AI tools that significantly automate development. And in your visual editor concept, AI fits perfectly. Are you planning to implement such features?
If a team is already using an established headless CMS with some form of live preview, what’s the most common trigger that makes them switch specifically for this and what migrations/lock-in concerns come up most?
Hi Product Hunt, maker here 👋
We started building DatoCMS about 10 years ago, when headless CMS was just becoming the "next" architecture for the modern web. The core idea's become very well established: structured content, API-first delivery, and full freedom on the frontend. One of the weak spots has always been the same though: visual editing. We always felt that the editors were missing out on what a Headless CMS could do for them because of how technical it has been by nature.
For a long time, headless meant great DX, but editors had to mentally map content and pages to models and blocks. Over the years, many platforms introduced their own versions of visual editing, often relying on iframes, CMS-rendered previews, or tightly coupled page builders.
Today we’re launching Visual Editing for DatoCMS, which is our take on solving that problem without breaking the headless model. Our primary goal with this feature is to make it dead easy for developers to implement Visual Editing in DatoCMS, so editors can work on their websites as frictionlessly as possible!
Our approach is based on:
Real frontend previews running your actual app, not a CMS abstraction
Content-aware deep links that connect any record or field to its exact usage in the UI
A framework-agnostic setup that works with modern stacks (we have SDKs for Next.js, Nuxt, SvelteKit, and Astro) and supports drafts, preview environments, and production safely
The goal isn’t to turn DatoCMS into a visual page builder. It’s to add visual context where it’s missing, while keeping developers in full control of rendering, data fetching, and architecture.
This feature is the result of years of feedback from our users and customers, and we’re excited to hear what you think! I'll be around and happy to dive into implementation details or trade-offs in the comments.
Invisible metadata in API responses is a much cleaner path than iframe sandboxing. Most headless CMS visual editors add a rendering layer that fights the frontend framework instead of working with it. The ContentLink component approach keeps the editing surface native to whatever stack you're already on, which means editors don't hit that weird lag between clicking and seeing the right field. Smart move shipping it on every plan including Free.