Headless CMS visual editor: what marketers can edit without a developer, and what still needs one.

What is a visual editor in a headless CMS?

A headless CMS visual editor shows your live front end next to, or inside, the content editing screen. Editors see changes on the real design as they type, and clicking an element jumps to the field that holds it. Some editors also let marketers assemble pages by adding, removing, and reordering sections that developers built in advance.

Don't confuse it with Webflow's Designer or a drag-and-drop site builder, where an editor can move a column or change a font. On a headless site, the design is code: a developer builds the hero, the logo bar, and the pricing table as components, and the CMS stores the words and images they show. The visual editor makes those easy to change where they appear. The layout stays with the developer.

Most vendors wire it up the same way. The CMS opens your site in a frame, your site switches to draft content, and the two send messages back and forth so an edit shows up without a reload. Payload's docs describe it as rendering "your front-end application directly within the Admin Panel," where "your changes take effect in real-time."

Can marketers edit a headless site without developers?

Yes, for content and for assembling pages from approved sections. Once the visual editor is set up, a marketer can change copy, swap images, reorder sections, and publish or schedule pages alone. No, for anything that needs new code: a new type of section, a new page template, a change to the content model, or a new integration.

Prismic's docs draw the line clearly: writers get the slices and page types a developer has exposed, and nothing else. Every headless CMS works this way. So plan the section library around the pages marketers build most, such as campaign landing pages, comparison pages, and customer stories.

Which headless CMSs have a visual editor, and how do they compare?

Most of them do, with different depth. Some show a live preview and jump from an element to its field. Others add page building, letting editors add, reorder, and duplicate sections. All of them need a developer to connect the preview to your front end, and some tie the best features to higher plans.

The setup column decides more than the features column. If live preview sits on a plan you won't buy, or skips the field types your pages are built from, marketers end up editing blind on the pages where they need a preview most. Our headless CMS comparison covers the other criteria, such as localization and workflow, without a ranking.

What does a developer have to set up first?

A preview route that shows draft content, a way for the CMS to load your site in a frame, the click-to-edit wiring, and the section library editors will assemble pages from. Expect most of the effort in the components and content model, not the preview itself. On Astro, plan for server rendering on preview routes.

A typical setup checklist:

1. A preview route that fetches drafts instead of published content. Storyblok requests the draft version of each story, for example, and Strapi points the CMS at a preview handler that builds each URL.
2. Permission for the CMS to show your site in an iframe. Storyblok and Strapi both point to the frame-ancestors security header, and Contentful's help center says a "Refused to connect" error means the site's security setup is blocking the frame.
3. Server rendering where the CMS needs it. Sanity's Astro integration says "Visual Editing only works for server-side rendered pages," and TinaCMS's Astro setup requires a server adapter. Public pages can stay static.
4. Preview tokens kept on the server. They read draft content, and Storyblok's docs say to validate requests server-side and keep the token out of client bundles.
5. The click-to-edit wiring: overlays in Sanity, storyblokEditable attributes in Storyblok, field helpers in TinaCMS, the live preview SDK for Contentful's inspector mode, or content source maps in Strapi.
6. The section library itself, with each section built as a component with fields, tested on mobile, and given a one-line note on when to use it.
7. A noindex rule for preview and draft routes. Our post on headless CMS SEO covers previews, redirects, and sitemaps before launch.

How do you choose a headless CMS for visual editing?

Test it on your own pages. Build one real landing page, with your own sections, in your top two candidates, and ask the marketer who will use it to make five ordinary edits. Then work through five questions:

1. Does the preview show your real components with draft content, on desktop and mobile? Sanity's preview, for one, switches between the two viewports.
2. Can editors add, reorder, and duplicate sections, or only jump from an element to its field?
3. Does it handle your field types? Strapi's Live Preview skips fields in dynamic zones, and Contentful's live preview doesn't work with custom editors.
4. Which plan is it on? Strapi ties side-by-side Live Preview to Growth and Enterprise. On Astro, also confirm the visual editing path fits your rendering setup.
5. How does it handle drafts, scheduled publishing, and releases? Sanity's preview can switch between draft, content release, and published views of a page.

What still needs a developer after launch?

New sections, design changes, changes to the content model, and integrations. A visual editor takes the developer out of routine publishing, not out of the site. Keep a small, regular block of developer time for new sections, and ask marketers to request them with an example page.

Marketers stay independent longer when the section library runs ahead of the campaign calendar. Build for the next six months, not only for launch; comparison tables, customer quotes, integration grids, and FAQ blocks are the usual gaps. Give each section a few options instead of open styling, such as an image on the left or right and a light or dark background. And decide who can publish what: blog posts can go live without review, while pricing, legal, and home page changes go through a reviewer.

Our own site runs on Astro and Sanity, and we build headless sites on Astro and Next.js with Sanity, so we have an interest in the topic. See our headless CMS agency page for how we run those projects, or our guide to Webflow vs custom code if you are still choosing between a visual builder and a headless stack.

Questions about headless CMS visual editors