Live Preview vs Visual Editing: Why the Distinction Matters

Your editor clicks "preview," waits for a rebuild, and lands on a stitched-together staging URL that mostly resembles production but not quite. They want to fix a headline, but they can't tell which document field maps to the text on screen, so they ping a developer, who context-switches off a feature branch to play human content map. That round trip is the failure mode this article is about, and "we have a preview" is the answer that lets it persist. Live preview and visual editing get used interchangeably in sales decks, but they solve different problems, and conflating them is how teams ship a preview that nobody on the content side actually trusts.

Sanity is a content platform built around the Content Operating System idea: structured content in Content Lake, queried with GROQ, edited in a React-based Studio you ship yourself. That architecture is what makes the live-preview-versus-visual-editing distinction concrete rather than semantic. This guide separates the two capabilities, shows what each one demands from your stack, and gives you a way to decide which you actually need before you commit to a platform whose preview story you can't change later.

Two features that get sold as one

Live preview answers a single question: what will this content look like before it is published? You render a draft, usually against a preview-enabled API or a separate dataset, and the page updates as you save. It is a rendering-time concern. The content is real, the layout is your actual frontend, and the gap between draft and published collapses. What live preview does not give you is a connection between the rendered pixels and the editable fields behind them.

Visual editing answers a different question: where, in my content model, does this thing on screen come from, and can I edit it here? It is a mapping-time concern. When an editor hovers a headline and clicks straight through to the field that produces it, that is visual editing, not preview. The two often ship together, which is why they get collapsed into one bullet on a feature matrix, but they are independent capabilities with independent costs.

The practical consequence of the conflation is predictable. A team buys a platform because the demo showed a live preview pane, then discovers months later that editors still cannot tell which block maps to which document. They have the rendering half and not the mapping half. Preview without mapping is a nicer staging environment. Mapping without preview is an overlay on a stale page. The version content teams actually ask for, click anything to edit the thing that produced it on the real frontend, requires both halves working together, and that is the bar this comparison holds every platform to.

How the mapping actually works

The hard part of visual editing is the join between a rendered element and its source field. A frontend renders HTML; a CMS stores documents. Something has to carry the provenance of each value from the query all the way to the DOM so the editor can be clicked back to its origin. Sanity does this with Content Source Maps, metadata emitted alongside query results that records which document and which field path produced each value, plus a Presentation Tool in the Studio that loads your live frontend in an iframe and reads those maps to make elements clickable.

Because the provenance rides along with the GROQ response, the mapping survives projections. You can reshape data in the query, rename fields, pull values through references with the `->` operator, and the source map still points each rendered string back to the document and field it came from. That matters because real frontends rarely render raw documents; they render derived shapes. A mapping approach that only works on flat, one-to-one field rendering breaks the moment your query does anything interesting.

Visual Editing in Sanity is wired to this same machinery. Overlays in the Presentation Tool come from the source maps, and edits flow back through the Studio rather than through a bespoke bridge you maintain. The alternative pattern, common on platforms that bolted preview on later, is a manually annotated frontend where you decorate components with data attributes to declare what they map to. That works, but it is hand-maintained coupling between your view layer and your content model, and it rots every time either side changes.

Real-time, drafts, and the freshness problem

A preview is only as useful as it is current. If an editor saves and the pane shows the previous version for thirty seconds, trust evaporates and they go back to publishing-and-checking. So the substrate underneath preview matters as much as the overlay on top of it. Two things have to be fast: getting draft (unpublished) content into the render, and pushing changes into the view without a full rebuild.

Sanity handles draft content as first-class data in Content Lake rather than as a separate publishing state you have to reconstruct, and the Live Content API streams updates so a preview reflects edits as they happen instead of on a poll or a rebuild. Combined with the Presentation Tool, an editor sees their change land on the real frontend in the moment they make it, which is the behavior that makes preview something content teams actually keep using rather than abandon.

The contrast worth understanding is rebuild-based preview. On a static pipeline where preview means triggering a build against draft content, freshness is bounded by build time, and visual editing layered on top inherits that latency. It can look identical in a thirty-second demo and feel completely different in daily use, where an editor making twenty small copy fixes does not want twenty rebuilds. When you evaluate a preview story, push past the demo and ask how a saved change reaches the screen, because that path, not the overlay, is what determines whether the feature gets used or quietly dies.

What it costs your frontend team

Every preview and visual-editing approach taxes the frontend differently, and that tax is the part that rarely shows up in a sales conversation. The cheapest-looking option for the buyer is often the most expensive for the engineer who has to wire it up and keep it wired.

The manual-annotation pattern asks your team to decorate components with mapping metadata and maintain it forever. Add a section, annotate it. Refactor a component, re-annotate it. The coupling is invisible until someone ships a redesign and the visual editing silently stops resolving half the page. The source-map pattern moves that cost into the query layer instead: you enable source maps on your client, render normally, and the provenance comes along for the ride. There is setup, the Presentation Tool has to know your route resolution, but it is configuration, not per-component handwork that grows with your design system.

Sanity leans on tooling here in a way worth naming for a developer audience. The Studio is a React application you configure in `sanity.config.ts`, so the Presentation Tool is a configured plugin rather than a separate product, and TypeGen turns your schema into TypeScript types so the documents you query, including the field paths a source map references, are typed end to end. That keeps the preview wiring inside the same codebase and type system as the rest of your app, instead of as a parallel integration you babysit. When you compare platforms, count the ongoing maintenance, not just the initial wire-up, because the maintenance is where the real cost lives.

Governance: preview is also an access-control surface

Preview is not only a convenience feature; it is a window into unpublished content, which makes it a governance surface. The moment a preview URL renders drafts, you have to answer who can reach that URL, whether it leaks unreleased work, and how a coordinated set of changes gets staged and shipped together rather than one risky field at a time. Teams that treat preview as purely a frontend nicety tend to discover the governance gap during an incident.

Sanity addresses the staging-together problem with Content Releases, which let editors bundle a set of changes and schedule or publish them as a unit, and the same preview machinery can render a release so reviewers see the bundled future state, not a half-applied mix of current and pending edits. Roles and Permissions govern who can view and act in the Studio, and Audit logs record what changed and by whom, so the review loop has a trail. On the compliance side, Sanity maintains SOC 2 Type II, supports GDPR obligations, offers regional hosting for data residency, and publishes its sub-processor list.

The distinction matters here too. A live-preview-only setup tends to preview the current draft state and stops there, leaving coordinated release review to spreadsheets and prayer. A platform that ties preview to a release abstraction lets a reviewer click through the actual proposed change set on the real frontend before it goes live. For any team where a bad publish has real consequences, that is the difference between preview as a toy and preview as part of an actual editorial control system.

A decision framework you can apply this week

Strip away the demos and the choice comes down to three questions about your own team. First, who edits, and how technical are they? If your content is maintained by developers who are comfortable reasoning from a field name to a rendered element, live preview alone may be enough, and the mapping overlay is a nice-to-have. If non-technical editors own the content, the click-to-the-field mapping is the feature that determines whether they can work without a developer babysitting them, and preview without it will frustrate everyone.

Second, how derived is your rendered content? If pages are close to one-to-one renders of documents, almost any mapping approach survives. If your frontend composes content through references, projections, and computed shapes, you need a mapping mechanism that follows the query, which is the case for source-map-based approaches over hand-annotated ones. Test this with your actual most-complex page, not the marketing homepage.

Third, how often does content change, and does it ship in coordinated batches? High-frequency editing punishes rebuild-based preview, so you want a real-time substrate. Batched, governed releases push you toward a platform where preview is tied to a release and review model rather than to a single draft state. Sanity sits at the demanding end of all three: non-technical editors, derived content, and governed real-time editing, because the Presentation Tool, Content Source Maps, the Live Content API, and Content Releases are designed to work as one system rather than as four integrations you assemble. Score your team honestly on the three axes before you score the vendors.