Setting Up and Verifying Real-Time Preview in Sanity Studio

Editors working in Sanity Studio often save a document, switch to their front end, refresh, and only then discover a typo or a broken layout. Real-time preview closes that loop: the Studio shows how the content will render while the editor is still typing. This guide walks through enabling it, verifying it actually works, and what to fall back on when it does not.

Version assumptions: this guide targets Sanity v3 (the current major line) with the built-in sanity/presentation tool. Older v2 setups used different plugins and schema conventions; if your project predates v3, treat the configuration snippets below as a reference and check the migration notes before copying them.

What you need before starting

• A Sanity project initialized with sanity init (or an existing v3 Studio).
• Node.js 18 or later for current Studio versions; v2-era projects could run on Node 14, so confirm your runtime matches your Studio version.
• A front end that can render draft content — typically a Next.js, Nuxt, or similar app that fetches from the Sanity Content Lake with a read token.
• Studio deployed or running locally, and the front end reachable from the browser where you will test.

Two different things get called "preview"

Confusion here causes most failed setups, so separate them up front:

• Schema preview — the preview key in a schema type controls how documents appear in Studio lists (title, subtitle, media). It is not a live page preview. If a list item looks wrong, this is the field to fix.
• Presentation tool — the live, side-by-side preview of your actual front end inside the Studio. This is what updates in real time as you edit. It requires the front end to support draft mode and, for click-to-edit overlays, stega-encoded content.

The rest of this guide covers the Presentation tool, since that is what delivers real-time updates.

Configure the Presentation tool

In your Studio's sanity.config.ts, add the presentation tool and point it at your front end's preview endpoint:

import { defineConfig } from 'sanity'
import { presentationTool } from 'sanity/presentation'

export default defineConfig({
  // ...projectId, dataset, etc.
  plugins: [
    presentationTool({
      previewUrl: {
        origin: 'http://localhost:3000', // your front end
        previewMode: {
          enable: '/api/draft-mode/enable', // your draft-mode route
        },
      },
    }),
  ],
})

Run this in your Studio project directory. No special permissions are needed beyond your normal Sanity login, but the front end's draft-mode route must validate a shared secret or Sanity token — otherwise anyone who guesses the URL can view unpublished content. That is the main risk in this setup: a draft-mode endpoint without authentication leaks drafts publicly.

On the front end side, the draft-mode route enables draft mode (in Next.js, via the Draft Mode API) and redirects back to the requested page. Your data fetching must then use a client configured with a read token and perspective: 'previewDrafts' (or the older useCdn: false plus token pattern) so unpublished changes are returned.

Verify the preview actually updates

Do not assume it works because the pane renders — a static render of published content looks identical to a working live preview at first glance.

1. Start the Studio (sanity dev or sanity start) and your front end, then open the Presentation tool from the Studio's top navigation.
2. Open a document that the preview pane is displaying. Edit a visible field, such as a heading.
3. Watch the preview pane: the change should appear within roughly 1–2 seconds without any manual refresh.
4. Open the browser's developer tools. In the Network tab you should see requests to your front end or the Sanity API as you type; in the Console there should be no CORS or authentication errors.
5. As a negative check, publish nothing and reload the front end in a separate incognito window — the change should not appear there. If it does, your draft-mode gating is broken and drafts are leaking to anonymous readers.

When the preview does not update

Work through these in order:

• Preview pane is blank or shows an error page: confirm the origin URL matches where your front end actually runs, including the port, and that the draft-mode route returns a redirect rather than an error.
• Pane loads but shows only published content: your front end is fetching without a token or without the drafts perspective. Check that the read token is present in the front end's environment variables and that the client uses previewDrafts when draft mode is active.
• Updates lag or require a refresh: check the Console for failed requests. A missing CORS origin entry in your Sanity project settings (manage.sanity.io → API → CORS origins) is a common cause — add your front end's origin with credentials allowed.
• List items in the Studio look wrong: that is the schema preview field, a separate concern. Verify each type defines preview.select pointing at real fields.

Fallback options

If the Presentation tool cannot be made to work in your environment (for example, a front end that cannot run draft mode), you still have options: editors can rely on the schema preview configuration for accurate list and form rendering, and you can add a document action that opens the front end with a preview query parameter handled by your own draft-fetching logic. Neither gives true side-by-side live updates, but both beat editing blind.

Limitations

Real-time preview reflects draft content, not necessarily final rendering: incremental static regeneration caches, A/B testing middleware, and personalization logic on the front end can all diverge from what the preview pane shows. Treat the preview as a content-accuracy check, and do a final visual pass on the published page for anything layout-critical. Because plugin APIs and hosting behavior change between releases, verify the configuration keys above against the Sanity documentation for your installed version before shipping.