Using Sitebin

Drop files, get a website — no account, no login. Every upload becomes a site behind unguessable URLs. This page covers the claim ticket, the two serving modes, editing, passwords, expiry, and how sites are addressed.

The claim ticket

Creating a site returns three things, shown exactly once:

• View URL — https://<random-id>.sitebin.app. This is the public address; share it.
• Edit URL — https://app.sitebin.io/e/<random-id>. Manage the site here: files, settings, passwords, expiry.
• Edit password — a random secret that authorizes every change to the site.

Signed in to your account? A site it owns opens on its edit URL straight away, without the password — the dashboard's Manage button takes you there. The password still works as before, and remains what WebDAV, FTP and scripts use.

Two modes: web server or file viewer

Each site serves its files in one of two modes, and you can switch between them at any time — switching is lossless, your files are never modified.

• Web server — files are served exactly as uploaded, with index.html as the entry point. Perfect for HTML apps and static sites. When no index exists, visitors get a directory listing instead.
• File viewer — the site renders one document directly in the browser: PDF, Markdown, DOCX, CSV/TSV, Jupyter notebooks, images, video, audio, and code/text with syntax highlighting. The raw files stay available under /_raw/… paths, and the viewer has a built-in file switcher and a download button.

On Enterprise and the hosted Pro and Studio plans there is a third mode, Container: the site runs the Node.js and MySQL services its sitebin-container-compose.yaml declares, and Sitebin proxies to them instead of serving files. See Containers.

Editing and managing a site

Everything below lives on the edit URL:

• Name — an optional private label, so a list of random URLs becomes one you can read. It heads the edit page and your account's site list, and is never shown to visitors.
• In-browser editor — open any file and edit it right on the edit page, no tooling required.
• ZIP download and upload — download the whole site as a zip, or upload a zip that is unpacked server-side.
• QR code — scan it to open the site on your phone.
• View counter — a per-site counter tracks page views and when the site was last seen.

Browser caching

Every site sends a Cache-Control header, so browsers keep what does not change and fetch what does. Pick the policy on the edit page (Behavior → Browser caching), through the API ("cache") or with MCP's update_site:

Revalidate means the browser keeps the file but asks on every visit; an unchanged file costs a tiny 304, and an upload is visible at once. Pages and data — HTML, JSON, XML, TXT, names without an extension — always revalidate, because they point at everything else. Hashed build files are the ones whose name carries a content hash, as Vite, webpack, Next.js, SvelteKit, Astro, Nuxt or Expo build them (index-BqCz7v8e.js, main.8f9e7d6a.css, everything under /_astro/, /_nuxt/ or /_next/static/): such a name never holds other content, so auto caches it for a year — which is what Lighthouse's efficient cache policy check wants. A hand-named file like style.css is never mistaken for one.

The fixed times cache every file but pages and data that long. Pick one only if your files never change under the same name — otherwise returning visitors keep the old version until the time runs out. A site behind a view password is cached privately, never by a shared cache; error pages and the password page are never cached.

View passwords

A site can optionally require a view password: visitors must enter it before the content is served. Like the edit password, only its Argon2id hash is stored, and password attempts are rate limited per IP and per site.

Expiry

A site can be given an expiry time. Once expired, it answers 410 Gone; the cleanup worker deletes its files 24 hours after expiry. Until then, removing the expiry brings the site back.

Locked sites

The operator can lock a site that breaks the terms — phishing, a scam, malware — instead of deleting it, so the evidence survives. A locked site answers 410 "Site suspended" to every visitor, on every address it has. Its owner still sees it on the edit page and in the dashboard, with the date and, when the operator gave one, the reason; but it can no longer be changed, downloaded, renamed or deleted, by any route — edit page, API, MCP, WebDAV or upload link. It does not expire while it is locked. If you think a lock on your site is a mistake, contact us.

Every upload is also checked automatically for the signatures of known phishing and scam kits. On an anonymous or Free site a clear match locks the site before the file goes live — the upload answers "held for review" — and a person looks at it; on Pro and Studio a match is only flagged for review.

What a page may load from elsewhere

Drops and Free sites on app.sitebin.io — on a self-hosted instance, anonymous sites and every plan not marked trusted — are served with a strict content-security policy that keeps a phishing page from sending what visitors type anywhere. The browser enforces it, so it decides what those pages can load:

• Images, video and audio only from the site's own files, plus data: and blob: URLs. A picture hotlinked from another website, or a badge in a README, does not show: upload it into the site.
• Scripts from the site itself (inline ones included) and from cdnjs, jsDelivr, unpkg, the Tailwind CDN and the jQuery CDN.
• Stylesheets from the site, Google Fonts, cdnjs, jsDelivr and unpkg; fonts from the site, Google Fonts, cdnjs, jsDelivr and unpkg.
• No requests to other servers — no fetch, XHR or WebSocket to another host — no form that posts anywhere, no iframes, and no other site may frame the page.

Everything else on the page keeps working; the browser's console lists what it refused. Pro and Studio sites load from anywhere, call any API and can have forms. The exact policy is on Operations & security.

View access modes

By default every site is served on its own random subdomain, which is why the instance needs a wildcard certificate. On a self-hosted instance, SITEBIN_VIEW_ACCESS selects how site content is addressed: