Share an Encrypted Web Memo with a Code and Password — Full Guide
TL;DR: Kawa’s online notepad is an online notepad share code workflow — not a paste link. You get a 3-character code + password, browser AES-GCM encryption, up to 10 images, no account, no overwrite, and auto-delete after 7 days. Think delivery tray, not notebook app.
If you have ever searched for encrypted web memo, share without account, or a Privnote alternative that supports screenshots and multi-day re-reads, this is the operational guide — threat model first, then every click.
What problem does this solve?
People arrive with different keywords — “online notepad share code”, “browser AES-GCM memo”, “password memo sharing” — but the job is the same:
Move text or screenshots to another person or device right now, without making them sign up, without leaving plaintext in chat history forever.
Pasting into Slack, email, or Teams
Fastest option. Also the messiest:
- Plaintext persists in message logs, exports, and search indexes long after the incident is closed.
- Forwarding and screenshots spread content to people who were never in the thread.
- Chat image compression can blur error text you needed support to read.
- Attachment limits block large log excerpts or multiple screenshots.
An encrypted web memo encrypts before upload and requires two factors to read: a short share code (which memo on the server) and a password (how to decrypt). Send them on different channels so one leaked message does not expose both.
Google Keep, Notion, and “real” notes apps
Excellent for long-lived knowledge — sync, labels, collaboration, search. Poor fit when:
- The recipient has no Google account and you do not want to explain sharing settings on a call.
- You want throwaway content that should not live in a vendor’s infrastructure as readable notes indefinitely.
Kawa’s memo is account-free, 7-day TTL, append-only — a delivery tray, not a wiki.
URL-based paste services (aNotepad, paste bins, gist-style links)
One link is minimal friction. The URL is often the secret:
- Links sit in chat logs and ticket systems forever.
- Misconfigured visibility (public when you meant private) is a recurring incident class.
- Referer headers and access logs can leak tokens.
- Many hosts store plaintext or keys the operator can read.
Kawa does not mint a public memo URL. The server holds ciphertext indexed by a 3-character code; decryption requires the password. A guessed or leaked code alone is useless against a strong password.
| Pattern | You send | Best for |
|---|---|---|
| Chat/email paste | Plaintext or attachment | Non-sensitive, ultra-short, already inside a trusted boundary |
| Keep / Notion | Account + share settings | Long-term notes, co-editing, search |
| URL paste (aNotepad, etc.) | https://... per memo | One link, optional public/private toggle |
| Code + password (Kawa) | 3-char code + password | No signup, short TTL, encryption, multi-screenshot handoff |
| Privnote-style | One-time URL | Read-once secrets, no re-read needed |
Services like TheSecureNote and textdrop.sh sit in the same design space: browser crypto, minimal trust in the server, explicit threat modeling. textdrop.sh often puts the key in the URL fragment (#...) for zero-knowledge delivery; Kawa splits index (code) and key (password) so neither channel alone unlocks the memo — closer to how security teams already split “ticket ID” and “unlock phrase.”
End-to-end flow
Creator Recipient
─────── ─────────
1. Open online notepad 1. Open same page
2. Type text (+ optional images) 2. Find "Have a share code?" at top
3. Set password 3. Enter 3-char code + password
4. Turnstile → Encrypt & Save 4. Click Load → decrypt in browser
5. Copy 3-char code (e.g. K7M) 5. Copy text / save images locally
6. Send code + password separately (within 7 days)The copy button copies only the code. Password travels by voice, SMS, second chat, or another app — not bundled in the same message if you can avoid it.
Creator walkthrough (numbered)
Open the online notepad. Three banners at the top state the limits: 7-day auto-delete, 10 images, 100,000 characters. Internalize those before pasting production data.
Step 1 — Enter memo body
Type or paste into the text area. Maximum 100,000 characters — fine for code snippets, config lists, meeting drafts, log excerpts, curl one-liners. Rich text (bold, colors from Word) is not preserved; paste through a plain editor if formatting looks broken.
While you edit, a local draft may persist in localStorage on the same browser — that is pre-cloud only. The character counter (e.g. 0 / 100,000) shows headroom.
Step 2 — Attach images (optional)
Up to 10 files: JPEG, PNG, GIF, WebP.
- Drag and drop onto the drop zone
- File picker (multi-select)
- Paste from clipboard — screenshot then Ctrl+V (Cmd+V on Mac)
Thumbnails appear in a grid; remove extras with the delete control on each thumb.
Before encryption, the tool compresses:
- Long edge capped at 2560px
- JPEG / WebP re-encoded around 80% quality
- Then encrypted, then uploaded
For support handoffs, crop to the relevant UI chrome before paste — readable beats pretty.
Step 3 — Set protection password
1–20 characters, required. Recipient must type the exact same string.
Avoid 1234, password, or reusing the share code. Short but random alphanumeric + symbols beats a long dictionary phrase. Offline guessing against stolen ciphertext is still possible with weak passwords — encryption is not a shield you can lean on alone.
Empty password → “Please enter a password” and save blocked.
Step 4 — Turnstile and save
Complete Cloudflare Turnstile (bot friction), then Encrypt and Save to Cloud.
In the browser, in order:
- Bundle text + image blobs
- Derive key with PBKDF2 from password + random salt
- AES-GCM encrypt
- POST ciphertext only over HTTPS
Success → green completion screen with 3-character alphanumeric code (e.g. K7M). Case matters (the UI may uppercase input for readability).
Step 5 — Deliver code and password
| Share code via | Password via |
|---|---|
| Slack DM | Phone / voice |
| Email body | SMS |
| Chat A | Chat B (different service) |
Do not put both in one line if you can split them — one log row should not capture the full unlock set.
Creator constraints worth tattooing on your team wiki
- No overwrite — typo? New memo, new code, tell recipient “X9Z replaces A1B.”
- 7-day TTL — not archival storage.
- No share URL — there is no “open this memo link” concept.
Page layout (first visit)
One page hosts load and create:
| Area | Location | Role |
|---|---|---|
| Limit banners | Top | 7-day / 10 images / 100k chars |
| Load section | Upper | Code + password → Load |
| Compose | Middle | Text, images, password |
| Turnstile + save | Lower | Bot check, encrypt upload |
| Success screen | After save | Code display, copy, new memo |
After save, the compose form hides — normal. Create new memo returns to compose mode.
Versioning without overwrite
Treat each save as a version:
- v1 → code
A1B - Fix typo → v2 → code
X9Z, message “A1B is stale” - Thread codes in Slack so you know which version was read
No merge conflicts because there is no merge — only immutable drops.
Recipient walkthrough (numbered)
Same page as the creator. No separate “viewer URL.”
Step 1 — Find the load section
Top of page: “Have a share code?” above the compose form — visible immediately, no hunting.
Step 2 — Enter share code
Three characters, e.g. A7B. No extra spaces.
Step 3 — Enter password
The string the sender gave you separately.
Step 4 — Load
Browser fetches ciphertext, decrypts locally. Success shows full text and image thumbnails.
Failure messages you may see:
- “Memo data not found” — wrong code, typo, or expired (>7 days)
- “Decryption failed” — wrong password or corrupted payload
Step 5 — Persist locally (recommended)
Server copy vanishes at 7 days. If you need it longer:
- Text — select all, copy to Keep, Notion, or a file
- Images — right-click save (desktop) or long-press (mobile)
“Same code works again” is only true inside the window.
Recipient checklist
- Code is exactly 3 characters
- Password matches sender (case, full/half width, no trailing space)
- Within 7 days of save
- Corporate proxy / ad blocker not killing Turnstile or API
- After read, copied what you need locally
Browser AES-GCM — for readers who are not cryptographers
Marketing says “encrypted” for everything from TLS to base64 theater. Here is what Kawa actually does, in plain language.
Why not send plaintext over HTTPS?
HTTPS protects in transit. If the server stores plaintext, operators, cloud admins, and DB thieves read your memo. Kawa’s rule: server sees ciphertext only. The password participates in key derivation inside the browser and is not stored as plaintext on the server — which is why forgotten passwords are unrecoverable.
AES-GCM in one metaphor
- AES — strong symmetric lock (same key encrypts and decrypts)
- GCM mode — confidentiality plus integrity: flip one bit, decryption fails (tamper-evident)
- Password — combination dial
- Share code — warehouse shelf label (finds the box; does not open it)
PBKDF2 key derivation
Humans type short passwords; AES-256 needs a 256-bit key. PBKDF2 mixes password + random salt with 100,000 iterations to derive a key.
- Different salt per memo → same password → different keys
- Raises cost of offline guessing slightly (still: use strong passwords)
What gets stored (conceptually)
Payload shape is roughly salt : IV : ciphertext (Base64). IV is random per encryption — identical plaintext → different ciphertext each save.
The UI states that without the password, admins cannot decrypt. Support cannot “reset and peek.” That is intentional.
Three common misconceptions
1. “HTTPS means the server cannot read my memo.”
HTTPS protects the wire. Client-side encryption protects at rest on someone else’s disk.
2. “Encrypted means I can use a weak password.”
Attackers can download ciphertext and guess offline. Crypto helps; entropy helps more.
3. “Auto-delete proves nobody read it.”
Delete limits future reads and server-side exposure. Anyone who decrypted and copied within 7 days still has a copy — recipient hygiene matters.
One line for engineers
Web Crypto API: PBKDF2 (SHA-256, 100k iter) → AES-GCM 256-bit. Text and image blobs encrypt the same way. Fastest audit path: Network tab on save, not reading minified source.
URL share vs code + password vs Privnote
| Aspect | URL paste (aNotepad, etc.) | Kawa (code + password) | Privnote / burn-after-read |
|---|---|---|---|
| You send | One https:// link | 3-char code + password | One-time link |
| Link leak | Often enough to read | Password still required | Usually one read then gone |
| Operator decrypt | Often possible (plaintext DB) | Not with password alone | Varies by implementation |
| Re-read | Until deleted | Anytime within 7 days | Typically once |
| Images | Product-dependent | Up to 10, encrypted | Usually text-first |
| Overwrite | Many allow edit | No — new code | No — new note |
| Account | Usually none | None | None |
Pick Privnote (or OneTimeSecret) when the secret should die on first view and nobody needs to re-open it Tuesday.
Pick Kawa when the same person may re-read for several days, you want encrypted screenshots, and you prefer splitting code vs password over putting the key in the URL fragment (textdrop.sh style).
Broader product comparison: share a memo without accounts and /en/vs/memo/.
Image workflow (field scenarios)
Scenario A — Error screens to support
- Reproduce on PC; Win+Shift+S / Cmd+Shift+4 screenshot
- Paste repro steps + Ctrl+V images into memo
- Add Network tab / console shots (≤10 total)
- Random password; save
- Code in Slack ticket; password on phone
- Support reads on mobile, pinch-zoom
Scenario B — PC → your phone (no email self-forward)
Same tool, same code+password — see PC ↔ smartphone handoff (JA) for a Japanese walkthrough of the cross-device flow. Fewer plaintext copies in mail servers than emailing yourself; no Google account unlike Keep.
Scenario C — Using all 10 image slots
Trim whitespace before attach; smaller ciphertext → faster load. The notepad compresses automatically, but cropped signal beats full-screen noise.
Image failure modes
- >10 images — remove old thumbs or split into two memos
- HEIC from iPhone — convert to JPEG/PNG first
- Huge animated GIF — prefer static frames or shorter clip
Failure modes (10+) and fixes
1. Password never sent (most common)
Symptom: Recipient has code only → Decryption failed
Fix: Send password on second channel. Sender forgot password → unrecoverable; recreate memo.
2. Share code typo (O vs 0, I vs l)
Symptom: Memo data not found
Fix: Exactly three chars; use copy button; read aloud “K-as-in-kilo, 7, M-as-in-mike.”
3. Opened after 7 days
Symptom: Worked before, now not found
Fix: By design. Copy locally before expiry. See why memos delete after 7 days (JA).
4. Wanted to overwrite
Symptom: Same code cannot update
Fix: New memo, new code, notify recipient which code is current.
5. Turnstile will not complete
Symptom: Save disabled or Turnstile error
Fix: Disable ad/privacy blockers temporarily; try Chrome/Firefox/Safari; check corporate firewall on challenges.cloudflare.com.
6. Storage quota exhausted
Symptom: Temporary save failure message
Fix: Retry later; reduce images or text length. Platform-wide limit — not always user-fixable.
7. Password “looks right” but fails
Symptom: Decryption failed despite agreement
Fix: Trailing spaces; full-width vs half-width; IME full-width alphanumerics; use password manager generated strings.
8. Private browsing lost draft
Symptom: Closed tab before cloud save — content gone
Fix: Draft autosave targets normal mode; backup long text to a file before save.
9. Mobile paste image unsupported
Symptom: Cannot Ctrl+V screenshot on phone browser
Fix: Use file picker from camera roll; or create on PC, load-only on phone.
10. Fetch / network error
Symptom: Generic load failure
Fix: Reload; re-enter credentials; check VPN/firewall blocking API endpoints; retry later.
11. Word paste looks like garbage
Symptom: HTML tags or mojibake
Fix: Paste through plain Notepad/TextEdit first.
12. Sender and recipient different time zones around day 7
Symptom: Edge confusion on “last day”
Fix: Treat expiry as server-side 7×24h from save, not calendar sympathy — copy early.
Browser compatibility
Requires Web Crypto API (modern browsers).
| Environment | Notes |
|---|---|
| Chrome / Edge (current) | Recommended; DevTools steps below |
| Firefox (current) | Fully supported |
| Safari iOS / macOS (current) | Supported; private mode may not persist drafts |
| Internet Explorer | Unsupported |
| IE mode in Edge | Open in normal Edge |
JavaScript required. Strict Tor / blocking setups may fail Turnstile.
Security do / don’t
Do
- Use for short-lived, disposable secrets (staging API keys, temp tokens)
- Rotate anything shared once the recipient confirms
- Split code and password across channels
- Prefer 12+ random characters when possible (20 char max)
- Have recipients copy out within 7 days
- Verify ciphertext yourself in DevTools once (below) — r/webdev PSA: trust but verify
Don’t
- Store production DB master passwords here
- Paste PCI / government ID class data
- Put code and password in one chat line
- Screenshot the password itself into the memo
- Treat encryption as archival — TTL is 7 days
- Rely on
test/12345678because “it’s encrypted”
Password memo sharing complements human handoff; it does not replace 1Password, Bitwarden, Vault, or AWS Secrets Manager.
Seven-day auto-delete — what it means operationally
Success and load UIs remind you: this memo deletes in 7 days. Not a bug — product boundary.
For users:
- Explicit “do not use as permanent storage” signal
- Reduces forgotten server-side blobs becoming long-tail leak surface
- Caps ciphertext lifetime even if you lose track of what you shared
| Role | Action |
|---|---|
| Sender | Keep your own copy if you need audit trail — server copy expires |
| Recipient | Copy text / save images before day 8 |
| Both | No restore after deletion — design, not oversight |
Need permanence → migrate to Keep, Notion, or your wiki. Deeper rationale: 7-day auto-delete design (JA).
DevTools verification — prove plaintext never leaves
Chrome / Edge / Firefox: F12 → Network. This is the same class of check you’d run on textdrop.sh or any “client-side encrypted” claim.
Save side
- Open Network; enable Preserve log
- Compose test string e.g.
this is a encryption test memo - Set password; Encrypt and Save
- Select the POST to the save API
- Inspect Payload / Request body
Expect:
- Your test sentence not present as readable plaintext
- Long Base64 or
encryptedData-style fields memoId= your 3-char code (index only, not the decryption key)- No password field in JSON
Conceptual example (values change every save):
encryptedData: "AbCdEf...very long Base64...=="
memoId: "K7M"
(password field absent)Load side
Response body stays encrypted; plaintext appears in the DOM after JavaScript decrypts — order of observation: Network shows cipher → then UI shows plain.
Application tab — localStorage draft
Application → Local Storage may show plaintext draft before cloud save. That is local-only pre-upload state. After save, server holds ciphertext; compare before/after to understand the pipeline.
Use this once in onboarding — screenshot for security lunch-and-learn beats slides about “we use AES.”
Use-case quick hits
Developer — staging API key for contractor
Disposable key in memo; strong password; code in Slack, password in Signal; revoke key after QA; memo ages out in ≤7 days.
Support — customer log excerpt
Ask customer to send code and password in two emails; paste into internal wiki; do not re-share memo code externally.
Personal — long URL to phone
One line in memo beats mail-to-self clutter.
Infra — maintenance command cheat sheet for tonight only
Commands live in memo during window; canonical runbook lives in Notion without secrets after cutover.
Design — five wireframes + bullet feedback
Encrypted images + text; client needs no account.
Research — experiment params colleagues re-read for 3 days
Privnote wrong tool (single read). New parameter set → new code; track versions in email subject exp-20260717-v2.
Team playbooks (small groups)
- Two-channel rule — code in team channel, password in DM or voice. Never one message.
- Disposable secrets only — production creds in Vault; staging in memo.
- Version codes — v2 supersedes v1; announce stale codes.
- Seven-day hygiene — weekly “still need this?” or copy to Notion.
- Quarterly demo — new hires watch Network tab during a dummy save.
FAQ (prose)
Do I need an account?
No. Open browser → compose or load. That is the share without account pitch.
Can two people read the same memo?
Yes, anyone with code + password within 7 days, unlimited reads. No simultaneous editing — read-only handoff.
Can attackers brute-force the 3-character code?
Space is small; password is the real gate. Strong password + Turnstile on save reduces automated scraping. Do not use this for nation-state secrets — use proper secret stores.
Is HTTPS alone insufficient?
For server operator trust, yes. HTTPS does not stop the host from reading plaintext at rest. Browser AES-GCM addresses storage on someone else’s server.
How is this different from “we won’t read your data” in a privacy policy?
Policy is goodwill. Math + client-side crypto is enforceable ignorance — operators lack the key material.
Privnote or Kawa?
One view then burn → Privnote. Multi-day re-read + images + split code/password → Kawa.
aNotepad with password-protected URL?
URL is still the address; implementation may allow operator recovery. Kawa avoids public URLs and encrypts before upload by default.
Encoding issues?
UTF-8 plain text. Word soup → paste plain first.
Is this a Privnote alternative for everything?
No. It is a Privnote alternative when you need encrypted web memo behavior with multi-day TTL and screenshots, not burn-on-read semantics.
Checklists
Creator
- Content ≤100k chars, ≤10 images
- Strong password set
- Encrypted save → code copied
- Code and password on separate channels
- Updates = new memo, not overwrite
Recipient
- Load section at page top
- Code + password entered
- Saved locally before day 7
Security
- No immortal production secrets
- Rotate shared credentials after use
- Optional: DevTools ciphertext check done once
Related reading (JA cluster + comparisons)
| Topic | Article |
|---|---|
| Memo site comparison (11 services) | オンラインメモ帳の選び方 (JA) |
| PC → phone handoff | PCとスマホでメモを共有 (JA) |
| 7-day deletion design | 7日自動削除の理由 (JA) |
| English comparison / threat model | Share without accounts |
| Head-to-head vs aNotepad / NotePal | /en/vs/memo/ |
| This guide in Japanese | 共有コード・暗号化・使い方 (JA) |
Next step: Open the online notepad, save a dummy two-line memo, load it in a private window, and spend sixty seconds in the Network tab. You will feel how online notepad share code + browser AES-GCM differs from dropping a paste URL in #general — without risking real credentials on the first try.