Is Pastebin safe? For sharing a stack trace or a config sample, yes. For anything that would hurt you if a stranger read it, no, and no visibility setting changes that. Pastebin’s own rules say not to post login details or password lists, and the safest habit is the plainest one: keep secrets out of any paste, then choose the visibility that fits who needs to read the rest.
That second step is where people trip, because “unlisted” and “private” sound similar and aren’t. This post explains the three levels as Pastebin documents them, how the same idea works in a self-hosted tool like SnipShare, and what no paste tool can protect you from.
Is Pastebin safe for code? What each visibility means
Everything here comes from Pastebin’s FAQ, under “Who can see my pastes?”
A public paste is the default. It shows up for everybody in the menu and on the archive pages, and the FAQ says search engines index only public pastes. An unlisted paste is invisible to others unless you share its link. A private paste can be viewed only by you, when you’re logged in.
There’s a catch on the account side. The same FAQ says guests can’t create private pastes at all, and free members get a capped number of unlisted and private pastes, with PRO members getting unlimited. Check the FAQ for the current limits. So if you’re pasting as a guest, your choices are public or unlisted.
Notice what that list doesn’t say. Unlisted is not a lock. It means the paste isn’t advertised, and the link is the only thing between a reader and your text.
What gets scraped, and why public means public
If a paste is public, assume someone’s reading it. Pastebin runs a scraping API for exactly this. Its documentation describes a recommended routine for anyone who wants to read all new public pastes: list the 100 most recent once a minute, store the IDs and fetch each one. That’s Pastebin’s own description of how people consume the public feed, and it’s reasonable for researchers and security teams to do it.
The practical consequence is simple. A public paste that contains a key, a token or a customer’s email address may be read within minutes of being posted, by software, long before you notice the mistake. Deleting it afterwards doesn’t un-read it.
Never paste secrets, whatever the visibility
Pastebin’s acceptable use rules tell users not to post email lists, login details, password lists, banking information or personal information. That’s a content policy, but it’s also good engineering advice for every paste tool.
Before you paste anything, scan it for four things: API keys and tokens, passwords and connection strings, private keys, and personal data about real people. Replace them with obvious placeholders such as YOUR_API_KEY. If a secret has already gone into a public paste, treat it as leaked: revoke it and issue a new one. Then clean up the paste.
This rule beats every setting below. A password-protected, burn-after-read paste is still a copy of your secret sitting on a server, in an inbox and probably in a chat window.
Pick the visibility by audience
Think about who needs to read the paste, then choose the smallest circle that works.
If it’s a snippet for a public tutorial or a bug report on a public issue tracker, public is fine, as long as you’ve cleaned it. If it’s something you’re sending to one colleague or one client, unlisted works for low-stakes material, with the understanding that anyone who gets the link can read it. If it’s for you alone, such as a draft or your own reference, private is the right level.
SnipShare uses the same three words, and the code supports them exactly as follows. Public pastes can be seen by anyone and appear in the public archive. Unlisted pastes can be opened by anyone who has the direct link and stay out of the archive. Private pastes can be opened only by the person who created them. A site setting controls the default for new pastes, and unless the admin changes it, the default is public. That’s worth checking on day one if you run a team site, because a default of public is the wrong starting point for internal code.
Passwords, burn after read and expiry
Visibility is only one of the dials. SnipShare adds three more, and each answers a different worry.
A password puts a gate in front of the paste. Visitors have to enter it before they see the content, and the plugin stores the password as a hash, not as plain text. A password helps when you’re sending a link through a channel you don’t fully trust, as long as you send the password through a different one.
Burn after read lets a paste be viewed once. After a reader who isn’t the owner has opened it, the paste is marked expired and the next visit fails. The owner’s own views don’t burn it. It’s handy for a one-off hand-off, but it won’t help if the reader copies the text.
Expiry removes the paste from view after a set time: ten minutes, an hour, a day, a week, one, three or six months, a year, or never. For a snippet that’s only useful this afternoon, a short expiry means you don’t have to remember to clean up.
Self-hosting changes who can read it
When you use a hosted paste site, the company runs the servers and writes the rules. With SnipShare, pastes live in your own WordPress database on your own host. That changes who has access: your hosting provider, your site administrators and anyone who can read your database or backups can reach what’s stored.
It’s worth being exact about the limits. SnipShare doesn’t encrypt paste content, and it isn’t a zero-knowledge tool. The text is stored as text, like a post, and the visibility, password, burn and expiry settings control who can view it through the site. They don’t scramble it. If you need content that even the server operator can’t read, you need a tool built around browser-side encryption, and SnipShare isn’t that tool.
What self-hosting does give you is control over the rest: who can register, what the default visibility is and who administers the site. Our Pastebin alternative page covers the comparison, and the self-hosted Pastebin replacement use case shows the setup. For a team keeping snippets internal, see the team snippet intranet.
Limits of any paste tool
A paste tool is a sharing tool. It’s not a secrets manager, and none of the settings above turn it into one. Keep credentials in a proper secrets store, send people the placeholder version of a snippet and let the real values live elsewhere.
The checklist is short. Clean the paste first, pick the smallest audience that works, add a password or expiry when the link will travel, and remember that public means public. If you want to see how SnipShare compares on the rest, the comparison page lines it up, and the broader code snippet sharing overview explains the day-to-day workflow.