A Storybook is the clearest artefact a front-end team produces — every component, every state, every variant, browsable. It's also the artefact that's hardest to hand to an outsider, because the obvious ways to share it are all wrong-shaped: publish it publicly and your unshipped design system is on the open web, put it behind your SSO and the client needs an account in your tooling, or send screenshots and throw away the interactivity that made it worth building. Storybook builds to a static site, which means there's a fourth option that gets overlooked: zip the build, upload it, send one unguessable link. The reviewer opens it in their browser, clicks through the sidebar, toggles the controls, and never signs into anything.
Try it now
Drop a file — get a private link in seconds. No sign-up.
Drop an HTML file or ZIP bundle, or click to choose.
Single file or ZIP. Max 3 MB.
Up to 3 MB, link self-destructs after 7 days. Sign up free to keep links forever, password-protect them, and store more.
Run your usual static build — Storybook outputs a self-contained folder with an index.html at its root, the story iframe, the manager UI and all the assets alongside it. Zip that folder and drop the zip in. The root index.html is detected as the entry page automatically, and every relative path inside the bundle keeps resolving, so the sidebar, the story canvas, the controls panel and the docs pages all behave exactly as they do locally.
The link you get back is a 32-character unguessable string carrying a noindex tag, so an unreleased design system doesn't turn up in a search for your client's brand name. Add a password when the work is under NDA, or an expiry so a review round closes by itself on the date you agreed — both free on every plan. The reviewer needs no account, no VPN and no seat in your repo.
Then rebuild and replace at the same address. The URL, the password and the expiry carry over, so the link you sent at the start of the engagement is still the link at the end of it — it just shows the current components. Turn Review on and anyone holding the link can pin a comment to the exact spot on a story without an account, and you can export the whole thread as a markdown brief on Studio.
Yes — that's what the static build is for. Storybook's build command produces an ordinary static site: an index.html at the root, the story iframe, the manager assets and your component bundles. Zip the output folder and upload it, and it's served as a site with the root index.html as the entry point. The sidebar navigates, stories render, the controls and actions panels work, and autodocs pages load, because none of it needs a server at request time.
Bigger than people expect — a design system of any size regularly lands in the tens of megabytes once fonts, icons and every component bundle are in there. The per-file ceiling here is 10 MB on a free account, 25 MB on Solo ($4.99/mo) and 50 MB on Studio ($14.99/mo), with 100 MB and 500 MB of total storage respectively. Check your build's zip size before you plan around it. If it's over, the usual culprits are unoptimised fonts, bundled video and stories that import a full icon set — and trimming those is worth doing regardless of where it's going to live.
No. They click the link and the built Storybook opens in their browser like any other site. There's nothing to install, no account to create, no invitation to accept and no VPN to be on. If you've set a password they're asked for that one passphrase and nothing else. That's usually the whole reason this route gets chosen over a hosted Storybook service — the friction lands on you once, at upload, rather than on the person whose opinion you're trying to get.
Yes, and it's the default rather than a setting to remember. Every link is a long unguessable string carrying a noindex meta tag and an X-Robots-Tag header, and there's no public directory or gallery anywhere on the service, so there's nothing to browse your way into. For an unshipped design system that matters more than for most things: component names, product surfaces and internal terminology all leak from a Storybook, and they leak in a form search engines find very easy to read.
Anything in the static build works, and anything that needed a running process doesn't. The manager UI, stories, controls, actions, viewport and autodocs are all in the build. What isn't is anything requiring something live behind it: test runners, addons that call a local service, or stories that fetch from an API only reachable inside your network. Mock those in the build if reviewers need to see them, or accept that a review Storybook is a viewing surface rather than a test harness.
Turn Review on for the document. Anyone holding the link can then click the exact spot on a story and leave a note anchored to it — no account, no install, and they can reply to each other rather than sending you six separate emails saying the same thing. You mark notes resolved as you work through them. On Studio you can export the whole thread as a markdown brief, which is unreasonably useful when the components were AI-assisted in the first place: paste the brief back into your tool and it has the same precision the reviewer had.
For a permanent, continuously deployed Storybook wired into your CI, no — a dedicated service or your own static host is the right answer, and Chromatic in particular does visual regression work that has nothing to do with this. This is for the delivery case: a specific build, a specific external audience, a specific review window. The two coexist happily. Most teams that do this keep their internal Storybook exactly where it is and use a private link for the handful of moments when someone outside needs to see it.
No card to try, no sign-up to get a link. Sign up free to keep links forever, password-protect them, and store more.