---
title: "Cross-domain preview"
description: "Previewing when the Admin and a locale live on different hosts."
requested_language: fr
language: en
translation_notice: "This page isn't translated yet"
url: https://docs.systhema.app/fr/next/payload/frontend/live-preview/cross-domain
version: unreleased (main)
docs_index: https://docs.systhema.app/fr/next/llms.txt
---
> This page isn't translated yet. Showing English.


Live preview keeps working when the Payload Admin and the previewed page are served from different origins, as long as the deployment allows the frame and the messages between them.

## Cross-site Admin and locale domains

Payload sets `livePreview.url` as the iframe source and communicates with it through `window.postMessage`, so the Admin and preview iframe do not need to be same-origin. When they differ, allow the exact Admin and preview origins in Payload's CORS/CSRF configuration and ensure the frontend's Content Security Policy permits the Admin origin in `frame-ancestors` (plus any equivalent CDN or reverse-proxy frame policy).

Server Preview and server-mode Live Preview still use the authenticated `/sys/preview` route. Systhema verifies both the Preview secret and the signed-in Payload user before enabling Next draft mode; do not weaken either check to make an unrelated public domain accept the request. The browser must be able to send the authentication and draft cookies to the preview origin. HTTPS subdomains under a deliberately configured shared site can support that, but unrelated registrable domains cannot share those cookies.

For unrelated Admin/frontend domains, use `client` mode. The `/sys/preview` entry still authenticates on the Admin origin before redirecting the iframe to the selected locale's public origin; Payload then streams unsaved form state across origins with `postMessage`. Client mode does not need the Next draft cookie on that public origin. If a custom template requires server-mode fidelity, host a cookie-compatible preview origin instead of relaxing Preview authentication. The same recommendation applies to local `en.localhost`/`hu.localhost` testing when Admin runs on another origin.

## Previewing a locale that lives on another domain

With [domain-routed locales](https://docs.systhema.app/fr/next/nextjs/locales.md) the admin and the previewed page are different origins — an editor on `https://site.ae/admin` previewing a locale published at `https://site.hu`. Both modes handle that automatically; there is nothing to configure.

Payload validates every live-preview message with `event.origin === serverURL` and posts its readiness handshake back to that same origin, so the previewed page has to name the **admin's** origin, not its own. Systhema resolves it from the embedding window and accepts it only when it is one of the site's own configured origins — the canonical site URL or a configured locale domain — falling back to the frame's own origin otherwise, so an unrelated site that frames a preview URL can't drive the render.

One practical difference remains between the modes:

Preview is served **on the Admin's own origin**, not the locale's canonical domain — a preview of `hu` opened from an Admin on `example.ae` renders at `example.ae`, in Hungarian. That is deliberate: the Admin posts its live-preview messages to the origin it was configured with, so moving the frame to `example.hu` would make the browser discard every one of them and the preview would never update. Only the editor sees this; published pages always use their canonical domain.

- **`client` mode works across domains as-is.** It needs no cookie, and relationship population is fetched from the previewed origin (same Next app, so no CORS allowance is required).
- **`server` mode refreshes across domains but may show published content.** It depends on the Next draft cookie, which is a third-party cookie in the preview iframe when the domains differ — browsers increasingly block those. Prefer `client` mode for domain-routed sites.