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>.app.sitebin.io. 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.

Save the edit password immediately. It is shown only once — the server stores nothing but its Argon2id hash, so it can never be recovered or reset.

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.

Editing and managing a site

Everything below lives on the edit URL:

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.

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.

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:

Mode	Site URL	Certificate
subdomain (default)	`<id>.sitebin.example.com`	wildcard cert required; strong per-site origin isolation
path	`sitebin.example.com/v/<id>/`	no wildcard needed — a normal single-domain cert suffices
both	subdomains and paths	wildcard cert required

Security note for path/both: path-served content shares the main domain's origin with the edit UI and API, so it does not get the origin isolation that subdomains provide. For that reason the Enterprise edition refuses to start with path/both view access and accounts enabled (a malicious path-hosted page could ride a logged-in visitor's session). Prefer subdomain whenever you run accounts or host untrusted HTML/JS; use path for simple, wildcard-free deployments of trusted content. Path-served sites should use relative links (css/x, not /css/x).

← Quickstart API →