Direct Answer: How Visual Editing Works in a Headless CMS
Pure headless CMS platforms decouple content management from front-end presentation, which gives developers freedom but often leaves marketers editing through raw forms and fields rather than in context. Visual editing solves this by adding an in-context, WYSIWYG-style editing layer on top of headless APIs, so authors can see and edit content on the actual rendered page while developers keep the architectural benefits of headless delivery.
dotCMS calls this model Visual Headless: API-first content delivery combined with an in-context editing interface. This guide covers how the editing experience evolved to get here, and what dotCMS specifically provides.
At a Glance
Traditional CMS platforms (like WordPress) offer WYSIWYG editing but tightly couple content to one presentation layer, limiting omnichannel delivery and developer flexibility.
Pure headless CMS platforms solve the delivery and developer-flexibility problem but commonly leave content teams editing in disconnected forms with no in-context preview.
Visual Headless CMS platforms add in-context visual editing on top of headless APIs, aiming to give both developers and marketers what they need.
dotCMS's Universal Visual Editor supports drag-and-drop page building, a block content editor, and single-page application (SPA) templating without requiring marketers to write JavaScript.
Traditional Content Editors: The WYSIWYG CMS
Traditional CMS platforms like WordPress often come with a WYSIWYG editor (What You See Is What You Get) - the simplest form of visual editing. With a WYSIWYG CMS, content authors know that the content they see in their editor will look the same once published, and can quickly create articles and add images, videos, and other assets without worrying about the underlying code.
The limitation: a traditional CMS is typically built to manage content for one channel model (a website, and sometimes a mobile app). It isn't built to deliver content to digital kiosks, smartwatches, or other emerging channels. And while marketers benefit from the easy editing interface, developers have limited room to improve the front-end experience - they can't easily bring in newer JavaScript frameworks and are often constrained by a templated design.
Content Management With a Pure Headless CMS
Since traditional CMS platforms weren't built for omnichannel content delivery or a strong developer experience, many organizations moved to a headless CMS instead.
A traditional CMS tightly integrates the front-end presentation layer with the back-end content management layer - good for content editing, but limited for multi-channel publishing or developer flexibility. A headless CMS decouples the front-end layer from the back-end data repository: the back end still manages and stores content, but developers can connect to any front-end interface using whichever frameworks and tools suit them.
The trade-off: pure headless architecture solves the delivery and developer problem but frequently reintroduces an editor problem. Content teams often work in structured fields with no way to preview how a change will actually look until a developer builds a preview environment for them.
Content Editing With a Visual Headless CMS
If a pure headless CMS isn't the answer for marketers, and a traditional CMS restricts developers, the model that resolves both is Visual Headless: a headless CMS with visual editing and no-code page layouts built in.
Developers keep the freedom to build front-end experiences across websites, mobile apps, smartwatches, car interfaces, and other channels using whichever frameworks they prefer. Marketers get an in-context editing interface, letting them execute independently of engineering teams.
Omnichannel Publishing
A Visual Headless CMS uses APIs to connect the front end to the back end, the same as a pure headless CMS, so businesses aren't restricted to publishing only to a website - they can reach customers across whichever channels the front-end team builds for.
Marketer-Friendly Content Management
Rather than relying on developers for front-end layout and page composition, marketers can drag and drop content into place and preview how it looks before publishing - the WYSIWYG-style experience of a traditional CMS, without giving up the headless delivery model underneath.
Developer Freedom
Developers keep the freedom to build front-end experiences on any channel using frameworks like React or Vue, without needing to assist marketers with routine content tasks, freeing them to focus on other work.
Faster Time to Market
With developers and marketers freed from mutual bottlenecks, teams can launch campaigns faster, test ideas more quickly, and incorporate customer feedback sooner.
dotCMS's Visual Editing Experience
dotCMS's Visual Headless model gives businesses the API-first flexibility of a headless CMS plus the visual content management capabilities of a traditional CMS. Its no-code tooling provides inline editing, layout design, and drag-and-drop editing for marketers, backed by a drag-and-drop content palette and a block content editor.
Enhanced Page Building
dotCMS's content palette lets marketers drop structured content types onto a page with drag-and-drop, so content authors can compose pages through layout editing rather than code.
Block Content Editor
The block content editor divides content into blocks, letting marketers drop images, videos, and other assets between existing blocks - including embedding content within content, such as an e-commerce product embedded in a blog post for a more personalized experience.
dotCMS's visual editor also supports single-page applications (SPAs), which many brands use for fast, personalized experiences. dotCMS lets teams build SPA templates without writing JavaScript, giving marketers more control over SPA look and feel.
This is what dotCMS partner Ethode relied on when the LeBron James Family Foundation needed a new web experience built, tested, and delivered in three weeks - a real deadline documented in dotCMS's published case study, not an illustrative figure. Ethode used dotCMS's no-code, framework-agnostic approach to launch the SPA on that timeline while also consolidating the Foundation's other properties onto a single platform.
Frequently Asked Questions
What Is the Difference Between a WYSIWYG Editor and Visual Headless Editing?
A WYSIWYG editor, in the traditional CMS sense, edits content that's tightly bound to one presentation layer. Visual Headless editing does the same in-context editing, but on top of an API-first architecture that can deliver the same content to multiple channels - websites, apps, kiosks, and more - without being locked to a single rendering model.
Does Visual Editing Slow Down Headless Delivery?
Not inherently. The visual editing layer sits on top of the same APIs a pure headless setup would use; it adds an authoring convenience without changing how content is delivered to the front end, as long as the platform is built for that separation from the start.
Can Marketers Build Single-Page Applications Without Developer Help?
With dotCMS, marketers can build SPA templates and layouts through the visual editor without writing JavaScript, though the initial framework setup and any custom front-end logic still typically involve developers. The division of labor is: developers set up the architecture and components once, and marketers then compose and edit within that structure.