Documentation has an awkward middle ground. Publish it and it’s on the open web, indexed under your client’s product name before the product exists. Keep it in the company wiki and the person who most needs to read it — the client, the auditor, the contractor doing the integration — doesn’t have an account and isn’t getting one for a two-week review. Every docs generator builds to a folder of static files, which means there is a third option that gets overlooked: zip the build, upload it, send one unguessable link. They open it in a browser, use the sidebar and the search box, and sign into nothing.
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 normal build and zip the output folder. The entry page is detected automatically, nested paths are served as they sit in the bundle, and the sidebar, search index and cross-page links keep working — because a built docs site is already just static files with no server behind them. Drop the zip in and you have a link in seconds.
One thing to check before you upload, and it takes ten seconds: open the built index.html and look at how it references its own CSS and JavaScript. Paths like css/base.css are relative and resolve correctly here. Paths that begin with a slash — /assets/main.js — are absolute, and they’ll look for those files at the root of the domain rather than inside your bundle. MkDocs builds relative by default and works as-is. Docusaurus builds absolute by default and needs its baseUrl set to the path it’s served from, which means publishing once to get the address and rebuilding against it.
The link is a 32-character unguessable string carrying a noindex tag and an X-Robots-Tag header, which matters more for docs than for most documents: internal endpoint names, unreleased feature names and architectural decisions all sit in docs in exactly the form a crawler reads best. Add a password for work under NDA and an expiry so a review window closes itself — both free on every plan. Rebuild and replace at the same address later and the URL, password and expiry all carry over.
Yes, as long as it’s a static build — which nearly all of them are. A docs generator’s output is a folder of HTML, CSS, JavaScript and assets with no process behind it, which is the same shape as any other static site. Zip the output folder, upload it, and the entry page is served with its subpaths intact. Navigation works, the client-side search index loads, anchors resolve, and versioned or multi-language trees come along because they’re just more folders in the same bundle.
Open the built index.html in a text editor and look at how it points at its own CSS and JavaScript. If those paths are relative — css/base.css, js/main.js — the bundle is self-locating and works here without changes. If they start with a slash — /assets/styles.css — the site was built expecting to sit at the root of a domain, and it will look for those files there instead of inside your bundle. That single check is more reliable than any list of supported tools, because it depends on your configuration rather than on the generator’s name.
It does. A default MkDocs build emits relative asset paths — css/, js/, img/ sitting beside the pages that use them — so zipping the site folder and uploading it is the whole procedure. Sphinx behaves the same way with its _static folder. These are the generators where this route is genuinely one step, and they’re also the ones most likely to be holding internal or client documentation in the first place.
A stock Docusaurus build points at /assets/… — absolute paths, because its baseUrl defaults to the root of a domain. Served underneath a link’s own path, those assets won’t be found and you’ll get an unstyled page. The fix is to build with baseUrl set to the path the site will actually be served from: publish once to get the address, set baseUrl to it, rebuild and replace the file at that same address. It works, but it’s two passes rather than one, and it’s worth knowing that before you promise a client a link in five minutes.
That’s the default rather than a setting. Every link is a long unguessable address carrying a noindex meta tag and an X-Robots-Tag header, and there is no public directory or gallery here to browse your way into. For documentation this is worth more than it first appears — docs leak internal service names, unreleased feature names, rate limits and architectural choices, all as plain readable prose, which is the format search engines handle best.
The per-file ceiling 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 on the paid plans. A text-heavy docs site is usually comfortable inside that; what pushes a build over is almost always images — uncompressed screenshots and diagram exports. If your zip is unexpectedly large, that’s where to look first, and trimming it is worth doing regardless of where the site ends up living.
No. They click the link and the documentation opens in their browser. Nothing to install, no account to create, no invitation to accept, no VPN. If you’ve set a password they’re asked for that one passphrase and nothing else. That’s usually the entire reason this route gets chosen over adding a seat in the internal wiki — the friction lands on you once, at upload, instead of on the person whose review you’re waiting for.
Turn Review on for the document and anyone holding the link can pin a note to the exact paragraph they’re asking about, reply to each other, and have notes marked resolved as you work through them — no account on their side. For documentation that’s a meaningful upgrade on the usual alternative, which is an email listing eight vague page references. On Studio you can export the whole thread as a markdown brief and hand it straight back to whatever you’re writing the docs in.
No. For public documentation that ships with your product and is continuously deployed from your repo, a real static host is the right answer and this isn’t competing with it. This is for the delivery case: a specific build, a specific outside reader, a specific window — a client reviewing a handover pack, an auditor reading integration notes, a contractor who needs the API docs for a fortnight. Most teams keep their real docs pipeline exactly where it is and use a private link for the handful of moments when someone outside needs to read 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.