# Visual Editor

Build variants by editing your live site in a popup window. Apply changes to one element or all matching instances. 15-minute signed sessions, scoped to your verified project's domain.

Build A/B/n and personalization variants by editing your live site in a popup. No code, no iframes, no staging environment required.

The visual editor lets non-developers (and developers, honestly) build test variants by clicking around on the real page. You pick an element, change its text or style or visibility, repeat — and the resulting list of changes is saved as the variant's definition. When the test launches, the SDK replays those exact changes on the page for visitors assigned to that variant.

Unlike most visual editors, Otter doesn't use an iframe. It opens your live site in a real popup window so the page renders in the same top-level browsing context a visitor would see — cookies work, CSP works, third-party scripts work. The main Otter A/B tab acts as a control panel that talks to the popup via a server-side message relay.

## Launch requirements

- **Verified snippet.** The project's Otter snippet must be installed and verified before the editor can launch. Verify from Project Settings → Installation.
- **Role: owner, admin, or member.** Viewers have read-only access to the dashboard and can't open the editor.
- **Compatible URL match type.** Exact, simple, and trailing-wildcard URLs work (e.g. `https://example.com/pricing*`). Contains, regex, and patterns with embedded `*` characters are blocked — the editor needs one concrete page to load.
- **Target URL must match the project domain.** Same host as the project URL, or a subdomain of it. This is enforced server-side at session creation.
- **Test type: Visual or Personalization.** Redirect tests don't have in-page variants to edit, so the editor button is hidden for them.

## How the session works

1. **Click Open Visual Editor** — In the Variants step of the test wizard, click **Open Visual Editor** on the variant you want to build. Otter kicks off an editor session for your target URL and variant.
2. **A short-lived editor session is issued** — Behind the scenes Otter checks your role, the project's snippet status, and that the URL belongs to the project's domain. If everything passes, a short-lived signed session is issued — scoped to one variant on one page, valid for 15 minutes, and bound to the project's origin so postMessage traffic from other pages is rejected.
3. **Popup launches your site with ?optimo-editor=…** — The dashboard opens a popup window pointing at your target URL with the token appended as `?optimo-editor=<token>`. The SDK on your site sees that parameter, verifies the token, and switches into editor mode — rendering the toolbar, inspector, and change-history UI directly on the page.
4. **Edit, with two windows in sync** — Every action you take in the popup (pick selector, change text, toggle visibility, undo) is sent through a server-side message relay keyed by your token. The main tab's control panel mirrors the connection state and lets you close the session cleanly.
5. **Save sends changes back as variant config** — Hit save in the popup and the accumulated changes are pushed back through the relay to the main tab, which stores them on the variant. Close the popup — you're back in the wizard with the changes attached. Launch the test (or save as draft) to lock them in.

## What you can change

- **Text** — Rewrite an element's text content — headlines, button copy, body paragraphs.
- **Style** — Override CSS properties: color, font-size, padding, background, display. Applied as inline style with high specificity.
- **DOM** — Hide an element, show a hidden one, or insert new HTML at a chosen position relative to an existing element.

## Apply to one element, or all of them

When you select an element, the inspector shows an **Apply to** control with two choices. It defaults to **Only this one**, which targets the single element you clicked. Flip it to **All instances** when you want the same change on every element that looks like the one you picked — repeated listing badges, card labels, star ratings, "Add to cart" buttons, result rows, and the like.

Choosing **All instances** swaps the unique selector the editor generated for a reusable one — for example, the single badge selector becomes `.property-result.labels` — and tells you how many elements match right now (e.g. *All instances (12)*). The preview applies to all of them immediately, so what you see in the popup is exactly what visitors will get. If an element has more than one reusable selector, a dropdown lets you pick the one you want.

The best part is what happens *after* the page loads. An all-instance change keeps watching the page, so elements that appear later — from infinite scroll, filtering, pagination, or a framework re-render — get the change automatically the moment they show up. You don't need one change per element, and you don't need to predict how many there will be.

- **Only this one** — The default. Changes the first element matching the selector and nothing else. Best for one-off edits — a single hero headline, one CTA, a specific banner.
- **All instances** — Changes every element matching a reusable selector — now and as new matches appear. Best for repeated UI: product cards, listing labels, badges, repeated buttons.

Prefer to add changes by hand instead of clicking around the page? The same **Apply to** toggle lives on the manual change form in the test wizard and on the test edit screen, so you can set **Only this one** or **All instances** against any selector you type in. Existing changes you made before this feature shipped keep behaving as **Only this one** — nothing changes underneath you.

> **Editor tips:**
>
> - **Pick stable selectors.** The editor auto-generates a CSS selector for every change, preferring stable hooks (`id`, `data-*`) over deep descendant chains. If your site rebuilds the DOM frequently, add `data-optimo-id` attributes to elements you regularly test so the selectors don't go stale.
> - **Allow popups for the dashboard.** The editor is a popup, and most browsers block popups by default. Whitelist the Otter dashboard in your popup settings, or just click the popup-blocked notification to allow it.
> - **Don't leave the session open all day.** Sessions expire after 15 minutes. If you walk away mid-edit, the popup may disconnect and you'll need to relaunch. Save often.
> - **Reach for All instances on repeated UI.** If you find yourself making the same edit to a row of cards or a list of badges, you're looking for **Apply to → All instances**. One change covers every match — and the new ones that load later — instead of a separate change per element.
> - **Editing is per-popup, not collaborative.** Two people opening the editor on the same variant at the same time will fight — last save wins. Coordinate or split variants across people.

> **Note:** Changes you build here only affect real visitors once you launch the test. To *see* a variant across your whole site before launching — drafts included — use the [Preview Bar](https://www.otterab.com/docs/building-tests/preview-bar).

## Frequently asked questions

### Who can use the visual editor?

Anyone on your account with the owner, admin, or member role. Viewers cannot launch the visual editor — they have read-only access to the dashboard. The project also needs to have a verified Otter snippet before the editor can launch (the editor talks to the SDK, so the SDK has to be installed first).

### What URL match types support the visual editor?

Exact, simple, and a single trailing wildcard (e.g. https://example.com/pricing*). Contains, regex, and wildcards with embedded * or multiple * characters are not supported — they describe a pattern rather than a specific page, and the editor needs to load one concrete URL to edit. The wizard surfaces a clear message telling you what to change if your URL match is incompatible.

### Why does the visual editor open in a popup window?

Because we don't want to iframe your live site. iframes restrict cookies, break some sites' Content Security Policies, and force everything into a sandbox that interferes with how a real visitor would interact with the page. The popup loads your real site in a real top-level browsing context — the same one a visitor would see — and the main Otter tab acts as a control panel that talks to the popup.

### How does the editor know which site to load?

It uses the test's page URL and URL match type to derive a concrete target URL: exact and simple just use the URL as-is, a trailing-wildcard URL drops the trailing star. The server then verifies that the resolved target URL is on the same domain as the project (or a subdomain of it) before issuing a session token, so you can't accidentally point the editor at someone else's site.

### What's in the session token?

A short-lived signed session that's scoped to one variant on one page. It binds the editor popup to the project's origin (so cross-origin postMessage chatter is rejected), expires after 15 minutes, and can't be tampered with. When it expires, the popup loses its connection and you'll need to relaunch from the wizard.

### How does the editor send my changes back to Otter?

As you work in the popup — picking elements, changing text or styles, undoing — your edits are passed securely back to the main Otter tab, tied to your signed session. When you hit save, the full list of changes is attached to the variant you're building. Close the popup and you're back in the wizard with everything in place, ready to launch or save as a draft. It all happens over your short-lived session, so nothing leaks between tabs or sticks around afterwards.

### Will my changes break my real site for visitors?

No. The editor only modifies the DOM inside the popup — your real visitors aren't seeing anything you do in there. Changes only affect real visitors after you save the variant AND launch the test (which moves it from draft to running). Until then, you can experiment freely.

### What kinds of changes can the visual editor produce?

Three categories: text changes (rewrite the contents of an element), style changes (CSS property overrides like color, font-size, display), and DOM changes (hide, show, move, or insert elements). The change history panel shows everything you've done; you can undo individual changes or clear them all before saving.

### What's the difference between 'Only this one' and 'All instances'?

When you select an element, the inspector shows an 'Apply to' control. 'Only this one' (the default) changes just the single element you clicked. 'All instances' applies the same change to every element matching a reusable selector — for example, every product card label or listing badge on the page. It's built for repeated UI where you'd otherwise have to add one change per element.

### Do 'All instances' changes apply to elements that load later?

Yes. An all-instance change keeps watching the page after it loads, so elements added later — by infinite scroll, filtering, pagination, or a framework re-render — receive the change automatically as soon as they appear. You don't need to know in advance how many matching elements there will be.

### Can I set the scope without using the visual editor?

Yes. The same 'Apply to' toggle (Only this one / All instances) is on the manual change form in the test wizard and on the test edit screen, so you can set the scope against any selector you type in by hand. New changes default to 'Only this one', and changes created before this feature shipped continue to behave as 'Only this one'.

### Why isn't the visual editor connecting?

Three usual causes: (1) the project's snippet isn't verified — fix this from Project Settings → Installation; (2) your target page is on a different domain than the project URL — the editor requires the target host to equal the project host or be a subdomain of it; (3) the popup got blocked — most browsers block popups by default; allow popups for the Otter dashboard.

### Does the visual editor work for redirect tests?

No — only A/B/n Visual and Personalization tests. Redirect tests don't have variants you can edit in-place; each variant is a separate URL. The wizard hides the visual editor button for redirect tests.

### Can two people edit the same variant at the same time?

Today, no — there's no real-time collaboration. Each editor session is scoped to one user, one variant, one popup. If two people launch sessions on the same variant simultaneously, the last save wins. We're tracking real-time co-editing as a future feature.

---

Canonical page: https://www.otterab.com/docs/building-tests/visual-editor