Self-destructing secret notes with zero-knowledge encryption. Create an encrypted note, get a one-time link, share it — the note is gone after a single read. The server never sees your content. Not even once.
Notefade splits your encryption key so the server stores only 16 meaningless bytes. Everything else lives in the URL fragment, which browsers never send to the server. No accounts. No cookies. No tracking. Just end-to-end encrypted, one-time-read secret sharing that you can self-host anywhere.
- 🔐 AES-256-GCM encryption — Web Crypto API only, zero external crypto dependencies
- 🔑 XOR key splitting — server stores just 16 bytes; each shard alone is an information-theoretic one-time pad, making reconstruction without both halves mathematically impossible regardless of computational power
- 🔗 URL fragment architecture —
#fragmentis never sent to the server, by design - 💥 One-time read — shard is deleted the moment it's served
- ⏳ Auto-expiring links — 1 hour, 24 hours, or 7 days
- 🗝️ Password protection — optional PBKDF2 layer (600k iterations, SHA-256)
- 📱 QR code sharing — generate and export as PNG
- 🕵️ Steganographic sharing — hide your note link inside innocent-looking text (zero-width Unicode) or images (LSB pixel encoding)
- 🌗 Dark / light theme — auto-detects system preference, manual toggle to override
- ✍️ Rich text editor — formatting toolbar with bold, italic, headings, lists, code blocks, and links; notes render as markdown
- 📬 Dead drop mode — encrypt now, share an inert link, activate later via launch code
- 🕯️ Burn-after-reading — configurable fade timer (30 s, 1 min, 5 min, 15 min) clears the decrypted note from the browser
- 👁️ Multi-read notes — allow up to 10 reads before the note is gone
- 🔒 Time-lock — schedule when a note becomes readable with a live countdown
- 🧾 Proof of read — cryptographic HMAC receipt the sender can verify without knowing who read it
- 🃏 Decoy links — generate 1–3 extra encrypted notes with plausible alternate content for deniability
- 🧩 7 backend adapters — Cloudflare KV, Cloudflare D1, Upstash Redis, Vercel KV, Supabase, AWS DynamoDB, or your own API
- 🏠 Self-hostable — frontend and backend, no vendor lock-in
- 🔁 Reproducible builds — deterministic Docker builds, SHA-256 build manifests on every release
- 🛡️ Subresource Integrity — every script and stylesheet in production includes
integrityattributes - 👻 No accounts, no cookies, no tracking — anonymous by default
- 📖 Open source — MIT licensed
- You write a note
- The client encrypts it with AES-256-GCM (Web Crypto API)
- The 32-byte encryption key is split via XOR into two shares
- A 16-byte shard goes to the server (stored in KV with a TTL)
- Everything else goes into the URL fragment:
notefade.com/#<id>:<payload> - The recipient opens the link → client fetches the shard → server deletes it → client reconstructs the key → decrypts → done
URL fragment (#) — never sent to server:
├─ shard ID → tells server which shard to fetch
├─ integrity check → FNV-1a hash for tamper detection
├─ XOR share (48 B) → meaningless without the server shard
├─ IV (12 B) → safe to be public
└─ ciphertext → the encrypted note (padded to fixed length)
Server KV:
└─ 16 bytes → deleted after first read or TTL expiry
The server never has enough information to decrypt anything. Even if it's compromised, seized, or subpoenaed — there's nothing useful to hand over.
Notefade is designed so the server is never trusted with secrets.
What the architecture protects against:
- 🖥️ Server compromise — the shard alone can't decrypt anything
- 💾 Data breaches — no content is ever stored server-side
- ⚖️ Subpoenas / legal requests — there's nothing meaningful to produce
- 📡 Network surveillance — the URL fragment never leaves the browser
- 📏 URL length analysis — all links are padded to a fixed length regardless of message size
- ♻️ Link reuse — the shard is deleted after a single read
What it does not protect against:
- 📸 Screenshots or copy-paste by the recipient
- 🦠 Compromised devices (keyloggers, screen capture malware)
- 💾 A recipient intentionally saving the content
We're honest about this. Once someone reads a note, they have the plaintext. Notefade ensures only one person reads it, and that the server is never in a position to.
Security headers: no-referrer policy, no-store cache headers, HTTPS-only in production, origin-locked CORS.
For a full technical breakdown, see notefade.com/docs.
Two methods to disguise a note link so it doesn't look like a link at all.
The URL is converted to binary, then encoded as invisible zero-width characters — U+200B (zero-width space) for 0, U+200C (zero-width non-joiner) for 1, and U+200D (zero-width joiner) as a separator — interleaved into cover text you provide.
The result looks like a normal sentence. The link is invisible to human eyes but recoverable by the decode page.
Limitations: Some apps strip zero-width characters on paste. If the recipient can't decode, send the link directly. The encoding is invisible to humans but detectable by tools inspecting Unicode codepoints.
URL bits are written into the least-significant bit of each R, G, B channel (alpha is untouched). A 4-byte big-endian length header precedes the UTF-8 payload.
Two modes:
- Generate — creates random abstract art as the cover image
- Upload — use your own image as the cover
The image must have enough pixels to hold the URL data. The LSB changes are visually imperceptible.
Messengers (WhatsApp, Telegram, Signal, etc.) recompress images by default, which destroys LSB-encoded data.
- PNG download — use when sending as a file/document (e.g. WhatsApp's "send as document" or "original quality" mode), or over channels that don't recompress (email attachments, cloud storage links, AirDrop)
- ZIP download — wraps the PNG in a ZIP archive that messengers won't recompress. The recipient extracts the PNG and decodes it. Safest option for messenger sharing.
Every download gets a randomized filename from 16 patterns (camera roll, screenshot, casual share, art/creative, social, etc.) using cryptographically random selection. An interceptor seeing the file cannot determine it came from notefade — filenames look like IMG_20260303_142517.png, sunset_v2.png, from_alex_painting.png, etc. No two downloads produce the same filename.
The built-in /decode page extracts hidden links from both images and text. Drag-and-drop or file upload for images, paste for text.
yarn buildServe the dist/ directory from any static host — Cloudflare Pages, Vercel, Netlify, Nginx, or a simple file server.
The default backend is a Cloudflare Worker with KV storage. Deploy your own:
yarn worker:deployOr use any of the 7 supported shard storage providers:
| Provider | Type | Notes |
|---|---|---|
| Cloudflare KV | cf-kv |
Default. Native TTL support. |
| Cloudflare D1 | cf-d1 |
SQL-based alternative. |
| Upstash Redis | upstash |
REST API, serverless Redis. |
| Vercel KV | vercel |
Backed by Upstash. |
| Supabase | supabase |
Postgres-backed. |
| AWS DynamoDB | dynamodb |
Via API Gateway. |
| Self-hosted API | self |
Any server implementing the ShardStore interface. |
Implement this interface and you can use any storage backend:
interface ShardStore {
put(id: string, shard: string, ttl: number): Promise<void>;
get(id: string): Promise<string | null>; // fetch and delete
exists(id: string): Promise<boolean>;
delete(id: string): Promise<boolean>;
}The get method must delete the shard after returning it (one-time read semantics).
When someone opens a note stored on a non-default server, notefade displays which provider holds the shard so users know what they're trusting.
- Node.js 22.14.0 (see
.nvmrc) - Yarn
# Clone the repo
git clone https://github.com/SaschaWebDev/notefade.git
cd notefade
# Install dependencies
yarn install
# Start the dev server (frontend)
yarn dev
# Start the worker (backend, separate terminal)
yarn worker:devThe dev server proxies /shard requests to the local worker on port 8787.
# Type-check and build
yarn build
# Run tests
yarn test
# Run tests in watch mode
yarn test:watch468 unit tests across 26 test suites (Vitest) covering cryptography, steganography, key splitting, receipt verification, URL encoding, decoy generation, ZIP building, time formatting, and random utilities. 9 end-to-end tests (Playwright, Chromium) covering page routing, the create-note flow, full create-to-read roundtrip decryption, note-gone states, and password gate rendering.
# Run unit tests
yarn test
# Run E2E tests (auto-starts Vite dev server)
yarn test:e2eyarn build:prodRuns four steps: type-check → Vite build → SRI injection → build manifest generation. The output dist/build-manifest.json contains SHA-256 hashes of every file.
You can verify that the code running on notefade.com matches this repository.
With Docker (most reliable — pins exact Node version and lockfile):
git checkout v0.1.0
yarn build:docker
# Compare dist-verify/build-manifest.json against the GitHub release manifestWith the CLI script (requires Node 22.14.0):
git checkout v0.1.0
yarn install --frozen-lockfile
yarn build:prod
node scripts/verify-build.cjsThe verify script fetches the build manifest from notefade.com, downloads every listed file, and compares SHA-256 hashes for self-consistency. It also verifies SRI integrity attributes on script and stylesheet tags. If a local build exists, it warns when Node versions or commits differ between local and remote. Tagged releases on GitHub include build-manifest.json as an artifact.
# Deploy frontend to Cloudflare Pages
yarn deploy
# Deploy worker
yarn worker:deployIf using Cloudflare Pages automatic builds (connected to GitHub), set NODE_VERSION to 22.14.0 in your Pages project settings (Settings → Environment variables). This ensures Cloudflare builds with the same Node version pinned in .nvmrc, which is required for reproducible builds and matching SRI hashes.
| Layer | Technology |
|---|---|
| Frontend | React 19, TypeScript (strict), CSS Modules |
| Build | Vite 6 |
| Encryption | Web Crypto API (AES-256-GCM, PBKDF2, XOR) |
| Steganography | LSB image encoding, zero-width Unicode text encoding |
| Backend | Cloudflare Workers + KV |
| Validation | Zod |
| Testing | Vitest, Playwright |
| QR Codes | qrcode-generator |
src/
├── api/ # Shard API client & 7 backend adapters
│ └── adapters/ # cloudflare-kv, d1, upstash, supabase, dynamodb, self-hosted
├── components/ # React UI (CreateNote, ReadNote, NoteLink, QrCode, ...)
│ └── docs/ # Documentation pages
├── crypto/ # AES-256-GCM, XOR key splitting, PBKDF2, steganography (LSB + zero-width)
├── hooks/ # useCreateNote, useReadNote, useHashRoute, ...
└── styles/ # CSS variables & animations
worker/
└── index.ts # Cloudflare Worker (shard CRUD + rate limiting)
Six endpoints. That's the entire backend.
| Method | Endpoint | Description |
|---|---|---|
POST |
/shard |
Store a shard (returns ID) |
HEAD |
/shard/:id |
Check if a shard exists |
GET |
/shard/:id |
Fetch and delete a shard |
DELETE |
/shard/:id |
Destroy a shard without reading |
POST |
/shard/defer |
Create a defer token (dead drop) |
POST |
/shard/activate |
Activate a deferred note |
Rate limited per IP. Max request body: 1 KB. Full API docs at notefade.com/docs.
MIT — Sascha Majewsky