Most pastebins store your text in plain form on their servers, which means anyone with access to the database — an employee, a hacker, or a court order — can read everything you've ever pasted. urlpaste works differently. When you create a paste, your browser encrypts it locally before anything is sent over the network. What reaches our servers is mathematically scrambled ciphertext, and the key to unscramble it never leaves your device. It travels only inside the link you share, in the part after the # that browsers never send to servers. The result: even if someone seized our entire infrastructure tomorrow, they'd find nothing but unreadable noise.
The encryption itself uses AES-256-GCM, the same battle-tested standard that protects banking apps and government communications — it scrambles your paste with a 256-bit key and detects any tampering. AES-256 is also quantum-resistant: even a large-scale quantum computer using Grover's algorithm would only reduce its effective strength to roughly 128 bits, which remains computationally infeasible to break. This matters because of "harvest now, decrypt later" attacks, where adversaries store encrypted data today and wait for future quantum computers. With a 256-bit key, your pastes stay safe not just today, but decades from now.
You don't need to understand any of the math to benefit from it. Everything happens automatically in your browser the moment you hit "create" — no plugins, no passwords to manage, no extra steps. The link you copy contains everything your recipient needs, and opening it decrypts the paste instantly on their device. We also support burn-after-read, so a paste can delete itself from our servers the moment it's viewed once. Our threat model is simple and honest: trust no one, not even us. That's why we've engineered ourselves out of the loop entirely.
Key generation. When you click "Create link", your browser generates a random 256-bit key using crypto.getRandomValues — the browser's cryptographically secure random number generator, seeded by the operating system. This key is not derived from your text, your IP, or anything we could guess or influence. Encryption. AES-256-GCM encrypts your paste with that key using a fresh 96-bit random initialization vector. GCM is an authenticated mode: it produces a cryptographic tag that proves the ciphertext was not modified in transit — if even one bit flips, decryption fails visibly instead of returning corrupted text. Key delivery. The key is encoded in the URL fragment (#k=...). By HTTP specification, the fragment is processed by the browser alone and is never transmitted to any server — not to us, not to your ISP, not to a corporate proxy, not to a state-level traffic interceptor.
If you set a password when creating a paste, the system adds a second cryptographic layer called key wrapping. Your paste key (the 256-bit AES key) is itself encrypted with a Key Encryption Key derived from your passphrase using PBKDF2-HMAC-SHA256 with 600,000 iterations and a random 16-byte salt. What this means practically: even someone who captures the full link cannot decrypt without the passphrase, and the 600,000 iterations make brute-force attempts computationally expensive — roughly 600,000 times slower per guess than a direct attack. The salt guarantees that two pastes with the same password produce different wrapped keys, defeating precomputed tables.
When you create a paste, our servers receive exactly three pieces of information: a six-character random slug, an initialization vector, and the ciphertext. That is the complete inventory. We do not receive your decryption key (it never leaves the URL fragment), your email (there is no signup), your name (there is no profile), or your IP history (the rate limiter keeps only ephemeral 60-second counters that expire automatically). The ciphertext is stored in a key-value store with an automatic time-to-live — when it expires, it is deleted by the storage system itself, not by an administrator. There is no backup of paste content, no replication to a "safety" copy, and no analytics pipeline that could capture it on the way through.
When a paste is marked burn-after-read, its deletion is not a soft claim — it is a hard delete from the storage layer. The first successful read of a burned paste triggers removal of the ciphertext and all its metadata from the KV store. A second visitor finds an explicit "this paste was burned" state, not silent content. This differs from many services that mark content "deleted" while retaining it for backup cycles or legal holds: at urlpaste.com, a burned paste is gone from our storage immediately, and because we never had the decryption key, no retained copy — had one existed — would be readable anyway.
Every pastebin faces the moderation dilemma: content that operators cannot read cannot be proactively screened. Our answer replaces trust with cryptography. Each paste stores a SHA-256 verifier derived from its decryption key — mathematically, holding this hash does not reveal the key, but someone who actually read the paste (and therefore holds the key) can always produce a matching hash. When a visitor reports a paste, their browser computes this proof locally and submits only the hash: we can confirm the reporter genuinely read the content without ever learning the key or the plaintext. Reports accumulate in an auditable counter; at the threshold, the paste is hidden from the public index while an appeal path — verified by a separate owner key — allows wrongful hides to be reversed. Every step's aggregate totals are published on the transparency page: if the numbers ever change without an explanation visible to you, that itself is evidence of a problem.
Honest security documentation states its boundaries. A compromised recipient. If the person you send a paste to forwards the complete link (including the key fragment), the new holder decrypts it — the math cannot distinguish a legitimate recipient from an unauthorized forwarder. Malware on either device. Client-side encryption assumes a trustworthy browser; keyloggers and clipboard hijackers predate and bypass it. The metadata you create yourself. If you paste identifying information into the content, no cipher removes it. Legal compulsion against the infrastructure. We cannot hand over content we never had — but a jurisdiction could compel architectural changes, block the service, or pressure upstream providers; the honest mitigation is the same one Signal chose: exit a market rather than weaken the design. Future quantum computers against short keys. AES-256's ~128-bit post-Grover strength is safe by current analysis, but key lengths should be revisited as the field evolves — we commit to updating this document if the mathematics change.
Every claim on this page is checkable. The deployed artifact is publicly fetchable and its SHA-256 hash is published on our social channels — anyone can download the same JavaScript your browser runs and inspect the cryptography for themselves. The moderation counters are public. The API is documented with exact request formats, so independent tools can reproduce the flow. Security through obscurity is worthless; security through verifiability is durable. If you find a discrepancy between this page and the deployed behavior, it is a bug we want to know about — report it through a paste, ironically, or through any channel you prefer.
Does urlpaste have access to my encryption key? No. The key is generated in your browser, lives in the URL fragment, and is never transmitted. For password-protected pastes, the server holds an encrypted blob that only unwraps with your passphrase — we store the wrapping, not the key.
What cryptography standard is used? AES-256-GCM from the Web Crypto API for content, PBKDF2-HMAC-SHA256 (600,000 iterations) for password wrapping, and SHA-256 for moderation proof-of-read verifiers. All are published standards (NIST FIPS 197, RFC 8018, FIPS 180-4) implemented by the browser's native crypto engine.
Is the encryption quantum-resistant? AES-256 remains strong against Grover's algorithm at ~128 bits effective — safe against foreseeable quantum hardware. There is no RSA or elliptic-curve component in the flow that would fall to Shor's algorithm. If post-quantum symmetric standards evolve, the architecture accepts key upgrades without changing the sharing model.
What data do you log? Aggregate moderation counters only — reports, hides, appeals, restorations — published publicly. No per-paste logs, no per-user logs, no IP retention beyond 60-second rate-limit buckets.
Can a subpoena force you to reveal a paste? Content: impossible — we hold ciphertext without keys, and for burned pastes nothing remains to seize. Metadata: the pastes we store carry no identity to link to; the honest remaining exposure is metadata visible to the network between you and us (like any HTTPS connection), which the fragment design keeps free of key material.
What happens to my data when a paste expires? Automatic deletion by the storage layer's TTL. There is no archive, no cold storage, no backup cycle containing paste content.