Privacy and Security
What rendrd does to keep a published page private, and how to check each claim yourself. This page describes the shared domain (view.rendrd.io); differences on a custom domain are called out where they apply.
Password protection
Password protection is per link and available on every plan, including the free one.
- Set a password at upload, or later from the dashboard.
- The password is stored as a hash, not as text.
- A request for a protected page returns an unlock prompt instead of the page.
- A correct password sets a first-party
HttpOnly; Secure; SameSite=Laxcookie scoped to that one link's path, valid for 24 hours. It carries the unlock proof and nothing else. - Changing the password invalidates existing unlock cookies; removing it makes the page open again.
This is the only control that decides who can open a page. Everything below reduces the chance of a link being found; the password is what stops it being read.
Search engines
Every page served from the shared domain carries two directives, which you can verify on any published page:
| Where | Value |
|---|---|
Page <head> | <meta name="robots" content="noindex, nofollow"> |
| Response header | X-Robots-Tag: noindex, nofollow |
Both are applied at serve time, so they cover pages published before this behaviour existed as well as new ones.
noindex is a directive, not an access control. Google, Bing and the other major crawlers honour it, but it depends on the crawler choosing to obey it, and it cannot stop a person who already has the link from opening the page or pasting it somewhere else. Treat it as a layer that keeps pages out of search results, not as a guarantee about who can reach a URL. For anything sensitive, add a password.
Two supporting properties:
- Slugs are random and unguessable unless the owner picks a custom one.
- No rendrd page indexes, lists or links to user pages, so there is no crawl path into them from our own site.
On a custom domain, the owner can opt a page in to indexing per page. Until they do, the same noindex directives are sent there too.
Origin isolation
A published page can run arbitrary JavaScript, so published pages are served from view.rendrd.io, a separate origin from rendrd.io, where the dashboard, sign-in, API and MCP live. A script inside a published page has no same-origin access to a signed-in session, the dashboard or the API.
Sanitisation and CSP
Uploaded HTML is sanitised at publish time against the accepted-frameworks policy, and constrained again in the browser at view time by a Content-Security-Policy sent with every page; you can read it in the response headers. The policy includes connect-src 'none', which blocks fetch, XMLHttpRequest and WebSocket, so a published page cannot call out at runtime, which also means it cannot exfiltrate what a reader types into it.
The allowlist both layers are built from is published live at rendrd.io/allowed.json and documented on Accepted frameworks.
View counting
View counts are recorded on our servers when a page is served.
Deletion and expiry
- Deleting a link takes the page offline immediately: the next request gets a 404 and the stored HTML is no longer served.
- Pausing a link takes it offline reversibly.
- Free links expire 7 days after publication and then return a "link expired" page.
- Paid links do not expire on a timer; they stay live until deleted, bounded by the plan's storage.
- A page can also be reported by any reader, and a suspended page returns 410.
Making a page public instead
None of this is one-way. Leave the password off and the link works for anyone who has it. On a custom domain you can opt a page in to indexing so it can appear in search results.