NoPaste: What Storing Data in the Link Means for Privacy and Permanence

NoPaste is a client-side paste service that keeps no database and no back-end code: the data you paste is compressed and stored entirely in the link you share, nowhere else. That single design choice produces four practical consequences — your paste can't be deleted or censored, the server can't read it, it stays accessible as long as you keep the link, and public links aren't indexed by search engines. The trade-off is that the link is the data: lose it, and the paste is gone.

How the data ends up in the link

When you paste content into NoPaste, the page compresses it in your browser and encodes it into the URL fragment (the part after #). The site offers Generate link, Generate markdown, and Embed outputs, plus an Edit option and a live Length / Lines counter as you type.

Two things follow from this:

• Nothing is sent to a server for storage, because there is no storage layer to send it to.
• The URL fragment is not transmitted to the server in normal HTTP requests, which is why the hosting server — or any clone of NoPaste — cannot read or access the data.

If a link fails to open, NoPaste shows a specific error: "NoPaste cannot decompress the URL. It's possible that you clicked on an invalid link." That message is the practical signal that the fragment was truncated, altered, or incomplete.

Privacy implications

The censorship point deserves precision: NoPaste's own documentation states your data cannot be censored because of this design. What can still happen is that a specific host or network blocks access to the NoPaste site itself, or that a platform where you post the link removes the link. The payload isn't removable, but your route to it can be.

Permanence implications

Because the data lives only in the link, permanence is conditional on the link surviving:

• Accessible forever — as long as you have the link. NoPaste's own wording ties durability directly to link possession.
• Cannot be deleted from NoPaste. There is no delete function, because there is no stored copy to delete. This cuts both ways: nobody else can remove your paste, and you can't retract it either.
• Portable across clones. The same link works on every NoPaste clone, including one you host yourself, since decoding happens client-side.

The failure mode to plan for

The realistic risk isn't deletion — it's loss. If the link is truncated by a chat app, wrapped by a URL shortener that mangles the fragment, or simply forgotten, the content is unrecoverable. There is no "recover my paste" path, because no copy exists anywhere but in that string.

Practical guidance

• Treat the link as the only copy. If the content matters, save it somewhere you control in addition to sharing the link.
• Test the link before relying on it. Open it in a fresh browser session; if you see the decompression error, the fragment didn't survive the trip.
• Don't assume secrecy from obscurity alone. The server can't read the payload, but anyone you send the link to can — and so can anyone they forward it to.
• Use it for sharing, not archiving. NoPaste is described as an open-source Pastebin alternative for storing code and generating shareable links; its design makes it strong for censorship-resistant sharing and weak as a backup.

NoPaste is an improved version of Topaz's Paste, and its source and further details are available on GitHub if you want to verify the mechanism or run your own clone.