Skip to main content
A preview link opens your real site with one specific variant rendered, exactly as a matching visitor would see it, without starting the test and without ABTestly recording any data. Use it to QA a change before you launch, to sanity check a running variant, or to send a colleague a link so they can see the variant for themselves. It works on draft experiments (before you’ve ever launched), on paused ones, and on running ones. The link is shareable: anyone who opens it on your site sees the same thing, for as long as the link is valid.
Two things this page is careful about, because both matter for trustworthy QA: a preview link for an unlaunched test is a real credential with an expiry (see How preview links are secured), and the “no data recorded” guarantee covers ABTestly’s own collection, not your variation’s code (see What preview does and does not suppress).
1

Open the experiment

In your dashboard, go into the site and open the experiment.
2

Find the variant

In the Variations list, each variant row has a Preview button.
3

Open or copy

Click Preview, then Open in new tab to view it yourself, or Copy URL to test in another browser or share with a teammate.
The link is your test’s page URL with the variant to force, plus a signed token when the experiment is not currently running:
abtestly_pt is a short lived credential the dashboard mints for you. A running experiment is already in your site’s published config, so its preview link carries no token. A draft or paused experiment is not, and its link needs the token to authorize reading the unpublished variant code. See How preview links are secured. When you open it on your site, the snippet renders that variant and shows a small Preview badge in the corner (see The preview badge).
The page the link points at comes from the target URL you set in the experiment’s Basics step. If you didn’t set one, it falls back to your site’s home page, so set a target URL if your test runs on a specific page.

What you can preview

  • Drafts, before launch. You don’t have to start a test to see it on your live site. This is the main reason to use a preview link, check your work on the real page first.
  • Running variants. Confirm a live variant looks right, or compare it against the control.
  • The control. Pick the control variant’s key (often control) to preview the original, unchanged page within the same flow.

Targeting is respected

A preview link forces the variant choice, but it still runs the experiment’s normal targeting, locations, and audiences. So the preview shows what a real matching visitor would see:
  • If the page and visitor match the experiment’s conditions, the variant renders.
  • If they don’t match (wrong URL, wrong country/device, etc.), you see the original page, the same as a non-eligible visitor.
If your variant doesn’t appear, the most common cause is targeting: you’re previewing on a page or in a context the test doesn’t target. Double-check the experiment’s Locations and Audiences against the page you’re opening.

Preview multiple tests at once

To see how several tests look combined on one page, separate the pairs with commas:
Each test is resolved and targeting checked independently, if one doesn’t match the page, the others still apply. You can preview up to 10 tests in a single link.
A preview shows only the tests named in the link. Preview does not bucket the visitor, so your other running tests are absent from the page rather than assigned as usual. Previewing a draft on its own therefore shows it in a state no real visitor is ever in, which is how a conflict between your draft and a live test survives QA.The preview modal lists the site’s other running tests so you can force an arm of each one alongside the draft. Use it whenever another test touches the same page. Note that exclusion groups are not enforced on this path either, so the modal can produce a combination that mutual exclusion would normally prevent.

The preview badge

While a preview link is active, a small Preview badge appears in the corner of the page. Each previewed test is shown as a row in the badge. Homepage CTA: [Variant B ▾], with the dropdown letting you switch to a different variant of that test in place.
  • Switch variants from the badge. Open the dropdown next to a test name and pick a different variant. The page does a full reload with the new variant forced, you don’t have to go back to the dashboard or copy a new link. The full reload guarantees the snippet re-runs cleanly against the new variant whether the link uses the query-string form or the hash form (see Single-page apps and the hash form). When previewing multiple tests, you get one dropdown per test on the same badge.
  • Drag it anywhere. The badge is a floating pill you can grab and move, so it never hides the element you’re trying to check. Its position is remembered for the rest of your session.
  • Exit preview. Click Exit ✕ on the badge to leave preview mode, it clears the session and strips the preview parameter from the URL, returning you to the normal page.
Variant labels in the dropdown come from the variant name you set in the dashboard (“Shorter headline”, “Sticky CTA”). If a variant has no name, it’s labeled Original for the control row or Variant 1 / 2 / … for the others.

Staying in preview as you click around

Once you open a preview link, preview mode persists across pages in the same browser tab for up to 1 hour, even if you navigate to URLs that don’t carry the parameter. This lets you click through a multi-step flow (e.g. a checkout funnel) while still seeing your variants. It ends when the hour elapses, when you click Exit ✕, or when you close the tab.

Single-page apps and the hash form

Most preview links use a normal query parameter (?abtestly_preview=…). A few frameworks (some Next.js, Remix, and Nuxt setups) reject unknown query parameters at the server and return a 404 before the page ever loads. If your query-parameter link 404s, use the hash form instead, a hash fragment never reaches the server, so the app can’t reject it:
It also works inside hash-router URLs, e.g. https://acme.com/#/products/123?abtestly_preview=<expId>:<variant>. Both shapes are parsed identically and pass the same security checks.
Switching variants from the badge’s dropdown writes the updated token back to whichever channel you started with, a hash-form preview keeps using the hash on subsequent switches, so SPAs that reject unknown query params don’t break mid-session. Each switch triggers a full page reload either way, so the snippet always boots fresh on the new variant rather than trying to swap variants in place.
See Single-page apps for more on running tests in client-side routed apps. If you’re writing variant code locally and want fast feedback in your own browser (devtools console, a userscript, a browser extension) you can activate the experiment without a preview URL by calling, from the console on your own site:
This treats the experiment as active for the rest of the tab session. your onApply callbacks fire, and SPA navigations re-cycle the lifecycle (cleanup, then re-apply) the same way they would for a real visitor. It does NOT inject the variant’s CSS or JS from the dashboard; it’s a flag-flip for the lifecycle hooks. Read more in Single-page apps → dev.apply.
abtestly.dev.* is console / userscript only. Don’t leave it in variant code, the dashboard editor will flag it.

Requirements

For a preview link to work:
  • The snippet must be installed on the page, loaded over HTTPS. See Installing the snippet.
  • Preview only activates on your registered domain or one of its subdomains. localhost works only if you tick that option before creating the link, because the choice is signed into the token.
  • A link can only preview your own site’s tests. Even on your domain, an experiment belonging to a different site is refused.
A preview link for a draft or paused experiment carries a signed token in abtestly_pt. The token is verified on our servers, not in the browser, before any unpublished variant code is returned.
  • It expires. 24 hours by default. After that the link stops working and you create a new one from the modal.
  • It is bound to your site and your domain. The check uses the browser’s Origin header, which page scripts cannot forge, so the link does nothing when opened against another origin.
  • It is scoped to one experiment. A link for one test cannot be replayed against a different one. The broader, site wide credential is the separate QA session link.
  • It can be revoked in bulk. Settings → Danger zone → Revoke preview links invalidates every preview and QA session link for that site immediately, including ones already open in someone’s browser. Use it when a link leaks or someone leaves the project.
  • It leaves the address bar as soon as it is used. The snippet reads the token, then removes it from the visible URL. It stays available for the rest of the session, but it is no longer in anything that reads the current URL: your server logs, browser history, a screenshot, or the analytics and session replay tools running on your own page.
Because the token leaves the URL, copying the address bar mid session no longer gives a working link for a draft. The pairs are still there, so the page keeps previewing for you, but a colleague opening that copied URL would see the original page. Share with Copy URL in the preview modal, which builds the full link from a freshly minted token.
A preview link for a running experiment carries no token, because that variant is already being served to real visitors from your published config.
Within its lifetime a preview link is a bearer credential: anyone who has the URL and opens it on your domain sees the variant, including an unlaunched draft, without signing in. That is what makes it shareable with a client or openable on your phone from the QR code. Treat it accordingly: share it deliberately, and revoke if it goes somewhere it should not.

What preview does and does not suppress

ABTestly records nothing from a preview session. Preview never buckets the visitor, and every outbound path the snippet owns is suppressed: the exposure and error beacons, the GA4 push, the Segment, RudderStack, Amplitude and Mixpanel adapters, heatmap capture, and page speed samples. Nothing counts toward your monthly tracked users. Previewing, or sharing the link with your whole team, cannot pollute your results.
That guarantee covers ABTestly’s own collection, not your variation’s code.A preview renders the variant for real, which means the variation’s JavaScript executes normally on your live site. Anything it does happens for real:
  • Calls it makes to your own analytics, a tag manager, or a third party pixel.
  • dataLayer pushes and custom events your other tools are listening for.
  • Requests to your APIs, and any state they change.
The page is also still your live site, so ordinary actions taken while previewing, submitting a form, starting a checkout, sending a support message, are real. If your variation code has side effects you would not want fired during QA, guard them, or preview against a staging environment.

Troubleshooting

The snippet probably isn’t loading, or you’re not on the registered domain. Open DevTools → Console and check window.__ABTESTLY_CONFIG__ returns your config (see Verify installation). Preview also requires HTTPS and only activates on your registered domain or a subdomain of it.
Not through ABTestly. Preview never buckets the visitor and suppresses every event the snippet would send, including the GA4 and product analytics pushes. Your variation’s own code still runs for real, though, so anything it sends is not suppressed. See What preview does and does not suppress.
Expected. The token is removed from the address bar once the snippet has read it, so a copied URL carries the variant but not the authorization. Use Copy URL in the preview modal instead.
If a preview still behaves unexpectedly after these checks, email support@abtestly.com with the link and the page you’re testing, we’ll help you track it down. Last verified against the shipped dashboard and snippet on 2026-09-01.

Start testing

You can start a 14 day trial on monthly Starter, Pro or Business and run this against your own traffic. Annual billing and Enterprise are not eligible, and the trial page explains why.

Start a 14 day ABTestly trial

Fourteen days on monthly Starter, Pro or Business, at your own traffic. A card is required when you start the trial and the first charge lands on day 15. The snippet is served from Cloudflare’s edge, and every result carries a confidence interval.
Last modified on September 11, 2026