How html.cloud encryption works

The plain-English version

When you drop an HTML file on html.cloud, the encryption happens on your own device before a single byte leaves it. Your browser generates a random key, scrambles the file with it, and uploads only the scrambled result. The key itself is tucked into the link you get back, after the # symbol.

That detail is the whole point. The text after a # in a URL is called the fragment, and browsers are built never to send it to the server — it stays in the address bar. So when someone opens your link, their browser fetches the encrypted blob from us, then uses the key from the fragment to decrypt it locally. We hand over scrambled bytes and never see the key needed to unscramble them. That is what “zero-knowledge” means here.

What we store — and what we can never see

The technical detail

For readers who want specifics, here is exactly what runs — all of it client-side, using the browser’s native Web Crypto API.

Encryption

• The file is encrypted with AES-256-GCM — a 256-bit key with an authenticated cipher mode that also detects tampering.
• A fresh 96-bit (12-byte) random nonce is generated for every encryption via crypto.getRandomValues.
• The uploaded payload is the nonce prepended to the ciphertext, base64url-encoded for transport.

Keys and the link

• The view key is a random AES-256 key generated with crypto.subtle.generateKey. It is exported and placed in the viewer link: html.cloud/v/{id}#{key}. It is the only thing that can decrypt your file, and it only ever exists in the fragment of that link.
• The edit key is 32 random bytes placed in a separate editor link: html.cloud/e/{id}#{key}. It lets you replace, re-expire, or delete the file.
• So the owner doesn’t need both keys, the view key is itself encrypted with the edit key and that encrypted copy is stored server-side. We also store SHA-256(edit key) as an auth token; edit and delete requests must prove they hold the edit key, and we compare hashes in constant time. The raw edit key never reaches us.

Because the keys live in URL fragments, they are never included in the HTTP request we receive — not in the path, not in headers. We genuinely cannot reconstruct them from anything on our servers.

Threat model & honest limitations

Encryption is only as strong as the assumptions around it. Here is what html.cloud does not protect against, stated plainly:

• The link is the credential. Anyone who obtains the full link — including the fragment — can read the file. There is no second factor. Share links over channels you trust, and use an expiry for sensitive files.
• Link handling is your responsibility. The key lives in the link, so it can leak if the full link is captured — by shoulder-surfing as you paste it, or by pasting it into a tool that previews or crawls it. To reduce this, the viewer strips the key from the address bar the moment the page loads, so screen-sharing or recording a file you’re viewing won’t expose it (use the “Copy link” button to forward the real link). The fragment is also never sent in the Referer header. Still: treat the original link itself as sensitive.
• You trust us to serve honest code. The encryption runs in JavaScript we serve, so a compromised or malicious server could in principle ship code that leaks a key. This is the standard trust caveat for all browser-based encryption — and it is why html.cloud is open source: you can read exactly what runs in your browser and confirm it does what this page says.
• No protection against a compromised device. If your machine or browser is compromised, the plaintext is readable before it is ever encrypted. Client-side encryption can’t help there.
• Symmetric, no forward secrecy. One key encrypts the file for its whole life. If that key leaks, the content is exposed; rotating it means re-uploading.

What we can see is limited to metadata: the size of the encrypted blob, the expiry, upload and access timestamps, and request-level network information such as IP address at the moment of a request. We never see the contents, the filename, or the key.

Open source — don't take our word for it

Every claim on this page is checkable, because the code that runs html.cloud is public. The browser-side encryption, the key handling, what the server stores — it is all there to read. If you are deciding whether to trust html.cloud with sensitive material, you don't have to rely on this page: read the source, or have your own engineers review it.

• The client is the part that matters most for privacy — it does the encryption before anything is uploaded. You can read it line by line and verify the key never leaves your browser.
• You can also check exactly what the server receives and stores: ciphertext, a nonce, the blob size, your expiry, and an auth hash — and nothing that could decrypt your file.

Read the source on GitHub →

FAQ