Unlisted limits discovery
Good for routine review: the paste stays out of public listings, but anyone with its URL can open it. The pastebin privacy guide compares every visibility choice.
How Pastebin.ai handles readable, password-protected, expiring, and client-side encrypted pastes - And where each protection ends.
Last updated August 3, 2026 · By Pastebin.ai Editorial Team
Good for routine review: the paste stays out of public listings, but anyone with its URL can open it. The pastebin privacy guide compares every visibility choice.
Useful for a known group: recipients must enter the password before the server returns readable text. Follow the password-protected paste guide to share the password safely.
Best when the server must not read the text: the browser encrypts first and keeps the key in the link fragment. See the encrypted paste workflow.
Standard and password-protected pastes reach the application as readable text. HTTPS protects them in transit, access controls limit discovery, and expiration limits retention. These modes are not zero knowledge. Anyone who receives an available unlisted URL can open it unless another access control is enabled.
A paste password is verified against a salted PBKDF2-SHA256 hash; the original password is not stored. After a successful check, the browser session is allowed to request that paste. The underlying standard paste remains server-readable. Owner-only visibility is different: The content is returned only while the creating Google account is signed in, and other visitors receive a not-found response.
The editor generates a random 256-bit AES-GCM key and encrypts content with the browser Web Crypto API before upload. A unique 96-bit initialization vector is combined with the authenticated ciphertext for storage. The key is added after # in the final URL; normal HTTP requests do not transmit that fragment. The recipient’s browser downloads the ciphertext and decrypts it locally.
Expiration makes the source URL unavailable after a chosen deadline. Burn-after-read removes the paste after its content endpoint is deliberately opened. Neither control can erase screenshots, downloads, browser extensions, copied text, caches, or a recipient’s independent record. Do not treat either feature as digital rights management.
Encrypted content still has metadata: A random identifier, title if supplied, language selection, timestamps, approximate size, expiry, and access events. Encrypted, password-protected, owner-only, and one-time pastes do not expose ordinary raw or public API retrieval endpoints. Operational logs may retain request and security signals independently of paste content.
Client-side encryption does not protect a compromised device, malicious extension, unsafe recipient, copied plaintext, or a complete link exposed in the wrong channel. Losing the fragment key also means the service cannot recover the content. Credentials, recovery codes, private keys, and regulated records belong in systems designed specifically for secret custody.
The editor warns on several common credential patterns before an unencrypted submission. Pattern matching is incomplete and may produce false positives. It is not a promise that content is safe. Review personal data, internal infrastructure, signed URLs, tokens, cookies, connection strings, and contextual secrets manually. Use the secret-scanning checklist before sharing code, logs, or configuration.
Encrypted mode uploads ciphertext. The AES-GCM key stays in the URL fragment and is not included in normal server requests.
No. Unlisted limits discovery but anyone with the random URL can open the paste.
The service cannot recover readable content without the complete fragment key.
No. Expiration ends future access to the source URL but cannot recall recipient copies.
Send a concise report to [email protected]. Include the affected route, impact, reproduction steps, and a safe proof of concept. Do not access other users’ content or degrade the service.