# PrivateBin: a self-hosted pastebin where the server never sees the paste

> PrivateBin is a PHP pastebin that encrypts paste contents in the browser before upload, so the server stores only ciphertext. It is aimed at self-hosters who want plausible deniability over user content, and it is only as safe as the HTTPS setup and the instance you point your browser at.

**PrivateBin/PrivateBin** — A minimalist, open source online pastebin where the server has zero knowledge of pasted data. Data is encrypted/decrypted in the browser using 256 bits AES.

- Repository: https://github.com/PrivateBin/PrivateBin
- Website: https://privatebin.info/
- Stars: 8,603 · Forks: 1,033
- Language: PHP
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/privatebin-privatebin

## The problem PrivateBin solves: storing text you cannot read

A conventional pastebin stores your text as plain text on someone else's disk. That puts the operator in a legal position the README describes directly: PrivateBin is built so that "the server has zero knowledge of stored data", and the stated benefit for an administrator is plausible deniability of any paste content. If a takedown request arrives, the operator can delete a paste without ever having been able to read it.

The audience is therefore narrow and specific. It is the person who runs the server, not the person pasting. A company that wants an internal snippet store, a community that wants a place to put logs and config fragments, or an individual with a VPS and a domain. The README also lists the plain pastebin use cases: text documents, code samples, and anything else you would otherwise paste into a public service.

What it is not is a secure messenger. The README is unusually blunt about the trust model, and that bluntness is the most useful thing in the document. The encryption protects the data at rest on the server. It does not protect you from the server sending malicious JavaScript to your browser on the next visit, and it does not hide who accessed a paste first if the operator keeps access logs.

## How the browser-side encryption and the URL fragment work

The mechanism is split so that the server never receives the key. According to the README, data is encrypted and decrypted in the browser using 256-bit AES in Galois Counter mode, and the key used to encrypt the paste is carried in the fragment part of the URL, the portion after the `#`. Browsers do not transmit the fragment to the server, so the ciphertext goes up and the key stays in the address bar.

That design has a direct consequence the README spells out: if you publicly post the URL of a paste that is not password-protected, anyone can read it. The link is the secret. This is why the project offers an optional password on top of the link, and why the README advises a strong password shared privately and end-to-end encrypted.

The repository layout reflects the split. The top level holds `index.php`, `lib/` for the PHP backend, `js/` for the browser code, `tpl/` for templates, `cfg/` for configuration, and `vendor/` for Composer dependencies. The `Makefile` at the root declares `CURRENT_VERSION = 2.0.6` and drives the test and documentation targets, including `make coverage`, which runs `cd js && nyc mocha` for the JavaScript tests and `cd tst && XDEBUG_MODE=coverage phpunit` for the PHP tests. That two-language split is the architecture in miniature: PHP handles storage and delivery, JavaScript handles every operation that touches plaintext.

AES-GCM was chosen over a plain cipher mode because it authenticates as well as encrypts. A paste that has been altered in storage or in transit fails to decrypt rather than decrypting into something else. The README does not describe the key derivation details beyond the cipher, so treat the algorithm name as the boundary of what the project documents in the README itself.

## Installing PrivateBin and creating a first paste

The README does not embed installation steps. It points to `doc/Installation.md` in the repository and to the wiki, and the repository ships a `Makefile` and a `composer.json`, which tells you the project expects a PHP host with Composer available. Follow the installation guide for the authoritative procedure; the outline below is what the repository structure implies, not a substitute for that document.

The project is distributed as source, so the practical starting point is a checkout with its production dependencies installed. The `Makefile` provides a target for exactly that, described in the file as updating Composer dependencies with only production ones and an optimized autoloader:

```bash
make composer
```

After that, the web server needs to serve the application root, and the configuration lives under `cfg/`. The README states that several features are optional and controlled in the configuration file, including password protection, discussions, expiration times, Markdown, syntax highlighting, and file upload. File upload and preview are disabled by default, with an adjustable size limit.

Once the instance is reachable over HTTPS, the first real use is a paste with an expiry and a password. The README describes the flow rather than the interface, so the concrete thing to check after your first paste is the URL you get back: the fragment after `#` is the key. Copy the full URL, not the part your browser shows before the hash, or the recipient will get ciphertext they cannot open.

If you would rather not run PHP at all, the related searches for this project include `privatebin docker` and `privatebin docker compose`, and the repository ships a `Procfile` and a `.devcontainer/` directory. The README itself does not document a container image, so verify any container route against the source you actually pull.

## The trust boundaries the README is honest about

The strongest section of the README is the list of things PrivateBin does not provide, and it should be read before deployment rather than after. The first item is that as a user you have to trust the server administrator not to inject malicious code. The README states that a PrivateBin installation has to be used over HTTPS, that the instance should be secured with HSTS, and that it can use traditional certificate authorities or a DNSSEC-protected DANE record. An HTTP-only deployment protects you from nobody except a passive observer inside the data centre.

The second boundary is the link itself. Anyone holding a non-password-protected URL can read the paste, because the key is in the fragment. A paste shared in a chat channel, a ticket, or a log is effectively public to everyone who can see that channel.

The third is metadata. The README states that a server admin can be forced to hand over access logs to the authorities, and that while the text and discussion contents are encrypted, who accessed a paste first may still be disclosed. Encryption of content does not encrypt the fact that someone fetched a URL at a particular time.

The fourth is the compromised-instance case. If a server is breached, stored data stays encrypted, but the README warns that the server could be abused or its admin legally forced into serving malicious code that logs the decryption key when a user opens a paste. The recommended response is to stop accessing the instance. A previously generated URL that nobody opens remains unreadable, which is a real property and also a fragile one.

## Where PrivateBin is the wrong tool

PrivateBin is the wrong choice when the secret has to survive the recipient being careless. The URL is the key, so any workflow that copies links into systems you do not control, or that lets a link preview bot fetch the URL, defeats the password-free case. If a chat platform unfurls links, the fetcher may retrieve the paste. Use the password option or do not use PrivateBin for that content.

It is also the wrong tool when you need an audit trail of who read what. The design deliberately leaves the operator with almost nothing to inspect, and the README treats that as the point. A team that needs access control, user accounts, or retention policy enforcement will find the model backwards.

Self-hosting is not optional for the trust argument. Using a public instance means trusting a stranger's server, which is exactly the assumption the encryption is meant to remove for the operator but cannot remove for the user. The README's warning about malicious code injection applies to every instance, including well-run ones, because the JavaScript that performs decryption is delivered by the server on every visit.

Finally, the project is PHP. If your infrastructure is a static site or a serverless platform without PHP runtimes, PrivateBin is a poor fit regardless of its features, and the repository gives no indication of a non-PHP deployment path.

## PrivateBin compared with MicroBin, Wastebin and ZeroBin

The related searches for this project pair it with MicroBin and Wastebin, and the comparison that matters is where the encryption happens. PrivateBin's defining property is client-side encryption with the key in the URL fragment, so the server stores ciphertext. MicroBin and Wastebin are paste services in the same self-hosted family, and the practical difference to check before choosing is whether the server can read stored pastes; if it can, the plausible-deniability argument in PrivateBin's README does not carry over.

ZeroBin is the ancestor, not a competitor. The README states that PrivateBin is a fork of ZeroBin, originally developed by Sébastien Sauvage, and that it was refactored to allow easier and cleaner extensions along with many additional features. Anyone searching for a ZeroBin replacement is looking at the lineage in the right direction, but the codebases have diverged and the feature set is not the same.

Against a general-purpose pastebin such as Pastebin itself, the difference is the business model and the storage model together. A hosted pastebin has to be able to read and moderate content, and it has to keep the service running. PrivateBin moves both the storage and the operational burden to you, and in exchange the stored bytes are useless without a key you hold. That trade is the whole product.

## Maintenance, releases and the licence question

The repository is not archived, and the last push was on 2026-09-10, so the project is being worked on. The recent release history shows the shape of that work: 2.0.6 on 2026-08-08 restricted the MIME types accepted for PDF and sanitized SVG previews to prevent an HTML render fallback; 2.0.5 on 2026-07-11 fixed rendering of unsafe attachments and a base path issue in JSON API responses; 2.0.4 on 2026-05-03 added Swedish and Persian translations. Two of those three releases are security-adjacent fixes to the preview and attachment paths, which is where a pastebin with file upload carries its risk.

That pattern matters for upgrade cost. The `Makefile` declares `CURRENT_VERSION = 2.0.6` and a `VERSION` variable, with an `increment` target that rewrites the version across `README.md`, `SECURITY.md`, `doc/Installation.md`, `js/package.json`, `lib/Controller.php` and the `Makefile` itself. In other words, the version string is duplicated across several files and the project maintains a target to keep them in sync. If you patch or vendor the source, expect to track those files yourself.

On licensing, the repository metadata reports the licence as NOASSERTION and ships a `LICENSE.md` file. That means the automated classifier could not map the file to a known identifier. Read `LICENSE.md` in the repository and confirm the terms with whoever handles licensing in your organisation before you redistribute or modify the code; nothing in the README states the licence terms.

## Conclusion

Adopt PrivateBin if you want to run a pastebin whose stored data is unreadable to you, you control the host, and you are prepared to serve it over HTTPS with HSTS. Do not adopt it as a way to share secrets with someone who must not learn the URL, or as a drop-in replacement for a login-based paste service: the encryption key lives in the URL fragment, and the README states that a server admin can be forced to hand over access logs. Before deploying, verify that your web server terminates HTTPS correctly, that the size limit and file-upload option in the configuration match what you want, and that you know which PrivateBin instance your users are actually pasting into.

## FAQ

### Is PrivateBin trustworthy?

The README states that as a user you have to trust the server administrator not to inject malicious code, and that a compromised instance could serve code that logs the decryption key. Stored paste data is encrypted, but the JavaScript that decrypts it comes from the server on every visit, so trust in the operator is not removed by the encryption.

### Is PrivateBin legal?

The README frames the design around the administrator's plausible deniability of paste content, and notes that if requested or enforced, an administrator can delete any paste from the system. It does not make any statement about the legality of operating or using an instance in a particular jurisdiction.

### What is a PrivateBin?

The README describes it as a minimalist, open source online pastebin where the server has zero knowledge of stored data. Data is encrypted and decrypted in the browser using 256-bit AES in Galois Counter mode, and the project is a fork of ZeroBin.

### Is PrivateBin free to use?

The README describes PrivateBin as open source and the repository is public, but the licence is reported as NOASSERTION and the terms are in the repository's `LICENSE.md`. Check that file before relying on any particular usage right.

### How do I install PrivateBin?

The README does not include installation steps; it links to `doc/Installation.md` in the repository and to the wiki installation guide. The repository ships a `composer.json` and a `Makefile` with a `composer` target that runs `composer update --no-dev --optimize-autoloader`.

### How do I use PrivateBin?

The README describes a pastebin-like system for storing text documents and code samples, with optional password protection, expiration times including a burn-after-reading option, and Markdown or syntax-highlighted pastes. The key is carried in the URL fragment after the `#`, so a paste shared without a password can be read by anyone holding the full link.

## Sources

- [Issues](https://github.com/PrivateBin/PrivateBin/issues)
- [PrivateBin/PrivateBin on GitHub](https://github.com/PrivateBin/PrivateBin)
- [Project website](https://privatebin.info/)
- [README](https://github.com/PrivateBin/PrivateBin/blob/master/README.md)
- [Releases](https://github.com/PrivateBin/PrivateBin/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/privatebin-privatebin