Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
You encrypted the page, uploaded it, and sent the link. Then the client replies: can we change the third paragraph?
Worth being concrete, because the workflow follows directly from the mechanism.
A tool like StatiCrypt takes report.html and writes encrypted/report.html. The output is a complete HTML page whose body is your content as AES-256 ciphertext, plus a password prompt and the JavaScript that decrypts it in the reader's browser. No server is involved anywhere — that is the whole point, and it is why the approach works on any static host that will serve a file.
The consequence is structural: you now have two files. The source you can read and edit, and the encrypted output you actually uploaded. The uploaded one contains no plain text to change — open it in any HTML editor and you will find the ciphertext, not your third paragraph.
So the edit loop is:
Three steps instead of one, every time. For a page you publish once, that is a rounding error. It is when the document is in review that it starts to be the thing you notice.
This is the one worth knowing before you need it, because it fails quietly.
StatiCrypt can generate an auto-decrypt share link — a URL with #staticrypt_pwd=... on the end that opens the page without the reader typing anything. Convenient, and widely used for exactly the client-delivery case.
That hash is derived from your password and a salt. StatiCrypt's README is explicit about what happens if the salt moves: keep the .staticrypt.json config file so the salt is the same each time you encrypt, or re-encrypting will invalidate the link. The same section documents pinning the salt for CI and build steps, for the same reason.
(Checked against the StatiCrypt README on 8 September 2026. It is an actively maintained MIT project and its authors set their own behaviour — check the current docs before relying on this.)
Read that alongside the edit loop above and the failure mode is obvious in hindsight and invisible in advance:
.staticrypt.json never committed because it looked like a build artifact.The fix is documented and it works. It is just a thing you have to know, on a page whose whole promise was that you did not need infrastructure.
Not a ranking — they are different trades, and the first one is genuinely better for a large class of jobs.
| Encryption in the file | Password on the link | |
|---|---|---|
| Where the protection lives | inside the artifact | on the host, beside the artifact |
| What reaches an unauthorised reader | the ciphertext | nothing |
| Editing | edit source → re-run → re-upload | replace the file |
| Share links surviving an edit | only if the salt is pinned | unaffected — the URL is not derived from content |
| Needs a host you trust | no | yes |
| Works on any static host | yes | no — the host has to offer it |
| Cost | free, MIT, no account | depends on the host |
Reach for client-side encryption when the page is essentially final, when you cannot or will not trust a third-party host with the contents, when it has to sit on infrastructure you already control, or when you want the ciphertext itself to be meaningless to anyone who grabs the file. Those are real requirements and no hosted gate answers them.
Reach for a hosted password when the document is still moving. If you already know there will be a round two, the difference between "replace the file" and "rebuild and redeploy the protection" repeats on every round.
We have gone through what the two serverless routes actually protect against, side by side, in password-protecting static HTML without a server — and the related question of why .htaccess password protection quietly does nothing on a static host.
Upload the plain HTML, set a password on the link, and when round two comes in, replace the file. The URL and the password stay where they are. Passwords come with the free account.
When the password is a property of the document rather than a property of the file, the edit loop collapses back to one step: upload the new file to the same document. The URL does not change, because it was never derived from the contents. The password does not change, because it was never inside them.
On miinideck those two live on the document record, not on the file — so replacing the file, or rolling back to an earlier version, leaves both the link and the password exactly where they were. The mechanics of keeping one address across revisions are in replacing a published HTML file without git, and if you want to try the protection on a file before deciding anything, the password-protect a page tool runs it in the browser.
Password protection is on every tier here including the free account, which is a deliberate choice rather than a promotion: a document you would not send unprotected is not a document anyone should have to pay to send.
A password is not the same as privacy. Whoever has the password can forward it along with the link, and neither approach stops that. If the risk you are managing is onward sharing rather than discovery, you want an expiry and a view log, not a stronger password.
Neither approach protects the contents from the person you gave the password to. That is the intended reader, and it is a solved problem only in the sense that it is not a problem.
Re-encryption is not the slow part of your week. If you publish protected pages that rarely change, this whole article is describing a cost you will pay twice a year. The reason it is worth thinking about up front is that the choice is easy to make at the start and annoying to reverse in the middle of a client review.
Your Slidev or reveal.js deck is already a self-contained web app. Skip the public deploy, the screenshot, and the PDF flattening: run the build, zip the dist folder, and turn it into one private link that keeps every fragment, transition, and code highlight stepping exactly as it did locally.
The person who needs your dashboard usually has no seat in your BI tool — and buying one is the wrong fix. How to ship a live, interactive dashboard to a no-login viewer, and where a live connection beats a snapshot.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.