The problem with ordinary pastebins
Pastebins are handy for sharing a stack trace or a snippet, which is exactly why they're risky for everything else. Public pastes can be crawled, indexed and archived. Unlisted isn't the same as private, either: GitHub's documentation on creating gists says secret gists aren't private, and anyone who has or discovers the URL can see them.
Most pastebins also store the paste in readable form on their servers, often indefinitely. For a log that happens to include a token, or config that includes a database URL, that's a leak waiting to be noticed.
How encrypted snippet sharing differs
An encrypted alternative flips the model. Your browser encrypts the snippet before upload, so the server stores ciphertext it can't read. The decryption key rides in the part of the URL after the #, which browsers don't send to the server (MDN), or reaches the recipient as a separate password.
Add an expiry and a read limit, and a shared snippet stops being a permanent artifact. The recipient gets what they need, and the paste is deleted when its job is done.
ProtectedShare's EnvShare works this way for config and keys, with 1 to 100 reads and up to 30 days, and Secure Notes handles anything else, with Markdown and inline code. PrivateBin is a long-standing open-source encrypted pastebin; ProtectedShare vs PrivateBin compares the two.
Before you paste anything
- Redact first. Logs often contain tokens, session cookies, email addresses and internal host names. Replace them with placeholders before sharing.
- Share the smallest snippet that reproduces the problem.
- If a secret did end up in a public paste, assume it's compromised. Revoke or rotate it, then delete the paste. Deleting alone doesn't undo copies already made.
When a public pastebin is fine
For public code samples, open-source bug reports and anything you'd be happy to see indexed, a public pastebin or gist is the right tool: being searchable and permanent is the point there. Keep encrypted, expiring sharing for everything else.