Sanity visual editing review: click-to-edit over a live front end

What Sanity visual editing is, and who it is for

Sanity's position in this dataset is the most opinionated: content should be structured, layout should be code, and visual editing should be a way of navigating structured content rather than a way of designing pages.

The Presentation tool implements that. Your front end renders with source annotations; the Studio shows it in a preview pane; clicking an element opens the document field behind it. Editors get the context of the live site without gaining the ability to restyle it.

That suits engineering-led teams with real content models — product catalogues, documentation, multi-surface content — and frustrates marketing teams who expected Webflow. Knowing which of those describes your organisation before you buy is most of the evaluation.

Architecture

Three parts. The content lake is the hosted data store. The Studio is an open-source React application that lives in your repository, which means the editing interface is code you can modify — genuinely unusual, and the reason Sanity appeals to teams who dislike black-box admin panels. The visual editing package connects rendered output to documents through source annotations.

The overlay approach explains both the strength and the limit. Because it decorates your real front end, there is no canvas to drift from production. Because it decorates rather than composes, it cannot offer drag-and-drop layout.

How we assessed it

We have not run Sanity hands-on under our test procedure, so no score and no code sample appear here, per our methodology. Registry metadata confirms the MIT licence, publication history and current version of the visual-editing package; pricing comes from the vendor's published page with the date we checked it.

Strengths

The editing interface is yours. The Studio is open source and lives in your repository, so customising it is a code change rather than a support ticket.

Visual editing on the free plan. Not gated behind an enterprise tier, which is unusual in this category.

Structured content, properly done. The data model is the product's strength, and it holds up when content genuinely needs to serve several surfaces.

MIT-licensed packages. The client libraries and the visual-editing layer are open source, so inspection and patching are possible.

A generous free tier. Up to 20 seats is enough for a real team, not just an evaluation.

Limitations

No drag-and-drop composition. If stakeholders expect to rearrange a page visually, this will disappoint them, and no amount of modelling fixes that expectation gap.

React-first. Visual editing outside React is community territory.

Usage-based costs need modelling. API requests, bandwidth and asset storage all meter beyond the plan allowances, and surprise bills in this category usually come from there.

The content lake is hosted. The Studio runs anywhere; the data does not.

Annotation setup is developer work. Source annotations must be threaded through your rendering layer for the overlays to work, and a partial implementation gives editors an inconsistent experience.

Pricing

Vendor-published: free plan with up to 20 seats, two datasets and stated request allowances; Growth around $15 per seat per month billed monthly (roughly $12 annually); Enterprise by quote for SSO, audit logs and data residency.

If drag-and-drop layout is the actual requirement, compare with Storyblok and Contentful Studio, and if the editor needs to live inside your own product rather than in a CMS, look at Puck or GrapesJS instead.

Questions to ask before you buy

1. What will our usage cost beyond the plan allowances? API requests, CDN requests, bandwidth and assets all meter; get a modelled figure for your traffic.
2. How much work is threading source annotations through our rendering layer? This is the real integration cost of visual editing here.
3. What is the upgrade story for the Studio living in our repository? Owning the code means owning the upgrades.
4. Can we meet our data residency requirement? The content lake is hosted; residency options are an Enterprise conversation.
5. How do we model a page builder if stakeholders insist on one? Ask for the reference pattern before promising the feature.
6. What happens to visual editing when a document type changes shape?

Where it sits in this dataset

Sanity is the most developer-owned CMS profiled here: the editing interface is code in your repository, the client packages are MIT licensed, and the visual editing layer decorates your real front end rather than replacing it with a canvas.

That makes it the natural comparison against Storyblok, which trades that ownership for a more polished hosted app that non-technical teams adopt faster. Against Contentful Studio, Sanity includes visual editing on the free plan where Contentful sells it as a quote-only add-on — a large practical difference for a team trying to make a decision this quarter.

The boundary worth restating: none of the three composes layout freely. If a stakeholder is describing drag-and-drop page building, the honest answer is that they want a different category, and the comparison table shows which products are in it.