urlpaste encrypts your paste in your browser with AES-256-GCM (quantum-resistant against Grover, ~128-bit effective — no asymmetric crypto vulnerable to Shor anywhere in the flow). You get a short, clean link — and we get nothing but ciphertext.
Every paste is encrypted client-side with AES-256-GCM — quantum-resistant against Grover (~128-bit effective), with no Shor-vulnerable asymmetric crypto anywhere in the flow. The server never sees your content — not even we can read what you share.
No random 20-character chaos. Every paste gets a short, human-friendly slug that's easy to type, read aloud, or drop into a chat.
A free REST API, a curl-friendly CLI workflow, and one-click burn-after-read make urlpaste perfect for developers, scripts, and secrets that shouldn't live longer than a single view.
Need a clean, short URL for anything you share? acortar.link turns long links into short, trackable ones — the perfect companion to a urlpaste link.
Before you open a suspicious link, check it. expandir.link expands and analyzes URLs for phishing and malware — paste, verify, then open safely.
urlpaste.com is an encrypted pastebin designed for people who need to share text and code securely without accounts, downloads, or trust in the server. Unlike traditional pastebins like Pastebin.com, dpaste, or controlc.com, every character you type is encrypted in your browser — using AES-256-GCM, a symmetric cipher resistant to Grover's algorithm (~128-bit effective security) with no Shor-vulnerable asymmetric cryptography anywhere in the flow — before a single byte reaches our servers. What we store is ciphertext: unreadable, unmoderatable at the content level, and unassociated with your identity, because we never ask for one.
Traditional paste services see everything you share. Whether you're pasting an API key, a database connection string, a stack trace with internal hostnames, or a confidential code snippet, a conventional pastebin stores it in plaintext. That data lives in their databases, appears in their search, gets scanned by bots looking for credentials — sites like GitHub's secret scanning exist precisely because millions of developers paste secrets into public pastebins every year. urlpaste.com closes that door structurally: the decryption key is generated in your browser and travels only in the URL fragment (#k=...), which browsers never send to servers. We physically cannot read what you share, and neither can a proxy, a corporate firewall, or an adversary harvesting traffic.
Sharing error logs with support teams. Logs frequently contain tokens, IPs, and internal paths. A burned, encrypted paste lets a support engineer read exactly what they need, then the paste destroys itself after a single view. Sending credentials to a colleague. Email and chat are logged forever; a 24-hour encrypted paste with a password wraps the secret in a second layer. Sharing config snippets in communities. Stack Overflow, Discord, and IRC links break when content is deleted; an indexable urlpaste link stays alive and decrypts only for the person holding the link. API responses and webhooks. Our free REST API accepts encrypted payloads directly from curl, scripts, and CI pipelines — perfect for sharing build logs without exposing secrets to the CI provider.
Enable "Burn after read" and the paste self-destructs the moment your recipient opens it. The stored ciphertext is deleted from our KV store on first read — a second visit returns a burned notice. This is ideal for one-time secrets: single passwords, one-time tokens, or links you want to survive exactly one handoff. Combined with the optional password wrap (PBKDF2, 600,000 iterations), even someone who obtains the URL cannot decrypt without the passphrase.
Most pastebins either don't moderate (becoming malware hubs) or moderate silently (reading your content without telling you). urlpaste.com does neither: since we can't read your pastes, moderation is driven by reader reports verified with a cryptographic proof-of-read — a SHA-256 hash derived from the decryption key, proving the reporter actually read the paste without ever revealing the key to us. Every report, appeal, hiding, and restoration is published on our public transparency page with aggregate totals. We cannot censor silently, and neither can a government order force us to hand over content we never had.
| Traditional pastebin | urlpaste.com | |
|---|---|---|
| Content visible to server | Yes — readable in plain text | Never (client-side E2EE) |
| Account required | Often, with email | No, ever |
| Tracking / ads | Common | None |
| Moderation | Opaque | Cryptographic proof + public totals |
| API | Rate-limited by account | Free, keyless, 10/min |
1. Type or paste your text into the editor above — encryption begins immediately in your browser. 2. Optionally enable burn-after-read, an expiry (1 hour to 30 days), a password wrap, or search-engine indexing. 3. Click "Create link" — you get a short URL like urlpaste.com/dDtJjM#k=.... The part after # is the key: browsers never transmit fragments to servers, so the decryption key lives only in the link you share. Send it through any channel; even we can't associate it with you.
Automate encrypted sharing with a single curl: POST your ciphertext to /api/paste and receive a short link in JSON. Rate-limited at 10 pastes per minute per IP, with an optional burn flag, expiry in seconds, and a password-wrapped key for sensitive payloads. The full API documentation covers every parameter — no account, no key, no cost.
Is urlpaste.com really end-to-end encrypted? Yes — encryption and decryption happen entirely in your browser with the Web Crypto API. The server receives only an initialization vector and ciphertext, and cannot recover the key because it never leaves the URL fragment.
What happens when a paste expires? The ciphertext and its metadata are deleted from our KV storage automatically. There is no archive, no backup, and no way for us to recover it.
Can the server read my paste if I report it? No. Reports are verified with a hash of the decryption key (proof-of-read) — the server confirms the reporter read the paste without ever learning the key itself. Our transparency page publishes these totals.
Is AES-256-GCM quantum-resistant? Against Grover's algorithm, AES-256 retains approximately 128 bits of effective security — considered safe against foreseeable quantum computers. There is no asymmetric cryptography (RSA, ECDH) anywhere in urlpaste's flow that would be vulnerable to Shor's algorithm.
Do I need an account? Never. No email, no signup, no tracking cookies — the service works anonymously by design.
How long do pastes live? You choose: 1 hour, 24 hours, 7 days, or 30 days. Burn-after-read pastes die after the first view regardless of expiry.
Encryption tools work best when paired with good habits. One: decide who legitimately needs the content — if the answer is "one person, once", burn-after-read plus a password is the right configuration. Two: send the link and any password through different channels: paste link in chat, passphrase by voice or a different app — an attacker now needs to compromise two systems. Three: set the shortest sensible expiry — a 1-hour paste for a live debugging session beats a 30-day link that outlives the incident. Four: for anything that could embarrass you or endanger someone, indexable stays off; search engines should never hold a pointer to your sensitive content. Five: keep the recovery key only if moderation reversal matters to you — and store it like you would store any secret, because it is one (it proves ownership of the paste's moderation state).
Versus one-time secret links (like one-time secret services): those tools share only passwords or short strings and rely on the server to enforce "one view". urlpaste shares full logs, code, and documents with the same burn guarantee — but the deletion is verifiable: the KV entry is gone, not just hidden behind a claim. Versus encrypted email: S/MIME and PGP require both parties to manage certificates; an encrypted paste requires nothing but a browser. The recipient clicks, reads, done — no keys to import, no trust chains to configure. Versus password managers' sharing features: excellent inside one team, useless for ad-hoc sharing with strangers; urlpaste fills the stranger gap without inviting them to install anything. Versus self-hosted PrivateBin: excellent if you can run infrastructure; urlpaste gives you the same zero-knowledge model with zero ops — no server to patch, no TLS certificates to renew, and moderation aggregates you can audit without running anything.
The client-side stack is deliberately boring — in the best sense. Key generation: 32 random bytes via the browser's CSPRNG. Encryption: AES-256-GCM from the Web Crypto API with a fresh 96-bit IV per paste; GCM's built-in authentication tag means any tampering with the ciphertext fails decryption loudly. Password wrap (optional): PBKDF2-HMAC-SHA256 at 600,000 iterations with a 16-byte random salt, deriving a Key Encryption Key that AES-GCM-wraps the paste key. Transport: HTTPS end-to-end; the key fragment rides in the URL but browsers strip fragments before any network request, so neither our logs — which we don't keep per-paste — nor any intermediary ever sees key material. Storage: Cloudflare Workers KV with automatic TTL expiry; burn-after-read pastes are deleted on first successful read. Moderation: a Durable Object per paste counts verified reports atomically; global aggregates go to a second Durable Object exposed on the transparency page.
Sharing the link and the password in the same message. If the channel is compromised, both secrets fall together. Split them. Reusing an old paste for new secrets. An indexable paste that once held a harmless snippet may be cached by search engines — new secrets belong in a new paste. Assuming expiry equals deletion everywhere. The recipient's browser may have cached the decrypted page; expiry protects our storage, not their screenshots. Set expectations accordingly. Trusting link shorteners with the full key URL. A third-party shortener sees the fragment in the long URL — use the short link we generate, which keeps the fragment intact and unobserved. Pasting on a compromised machine. Client-side encryption cannot defeat malware already reading your keystrokes; for high-stakes shares, a clean environment matters more than any cipher.
We commit to five principles you can verify: 1. The server cannot read pastes — architecture, not policy. 2. No accounts, ever — there is no signup flow to compromise or subpoena. 3. No tracking — no analytics, no ad scripts, no third-party requests beyond the Turnstile anti-bot challenge on reports. 4. Public moderation totals — hides, appeals, and restorations published; silent censorship is structurally impossible. 5. Open to scrutiny — the deployed artifact hash is public, the API is documented, and the cryptographic design (AES-256-GCM, PBKDF2, proof-of-read) follows published standards rather than invention. When we say "we get nothing but ciphertext", that is a testable statement, not a slogan.
Scroll to the editor at the top of this page. Type or paste your text. Watch the character counter — encryption is already happening as you type. Click Create link. Copy the short URL. Send it. That's the entire workflow: no account walls, no email confirmations, no upsell modals. The person who receives your link sees the decrypted content and nothing else — and neither do we. If this is your kind of tool, bookmark it: it will be here, anonymous and unreadable, whenever you need to share something that deserves better than plaintext.