Support / Blog

Encryption mechanics you can verify yourself

These articles explain how local encryption works — they are not a substitute for the tools. Current pieces cover why an LLM relay can still sell Agent call logs as-is after SSH private keys and cloud tokens go into a prompt, why, after you close a burn-after-reading tab, the key after # can still come back from Recently closed tabs, why pasting that link into a chat that generates a preview does not always use up the read, why clipboard history still keeps plaintext after you copy a generated password, why format redaction can still point to the same customer before you paste a ticket into a chat AI, what UTM and click IDs carry when a campaign link is forwarded, why a rotated API key should not go back into chat after an env leak, and why a URL hash fragment never shows up in server logs. The facts match the tools: no accounts, and plaintext stays off the server by default.

Local encryption Hash fragments Verify in DevTools
01 / Articles

What you can read now

Newest first. Titles and summaries match the article topic—not the product definition on the home page, and not the how-to on each tool page.

02 / How we write

Only what you can check

Articles cover concrete problems from engineering, support, and outbound backups. Algorithms, permissions, and what is uploaded match the live tools. We do not invent a second set of promises.

Articles cover
  • Where computation runs Symmetric encryption uses AES-256-GCM via the browser Web Crypto API. Passwords are 6–128 characters; a single file is at most 5 GB, written as .lock / .enc.
  • What stays out of the request body Test passwords, cleanup source text, and files are not uploaded by default. Burn-Link only stores ciphertext; the key stays in the address-bar # fragment.
  • Open and read The blog, like the Password Generator, Password Audit, Privacy Cleanup, Burn-Link, and File Encryption Box, does not require sign-up.
Articles do not
  • Stand in for a tool homepage For a form, open the matching page. This page does not repeat a step list for generating a password or creating a Burn-Link.
  • Read as a password-manager guide UsePwd has no accounts and no vault, and cannot recover a secret by user. Identity is explained on About.
  • Invent service promises No support email, and no uptime percentage or response time. What the server actually receives is in the Privacy Policy.
03 / FAQ

Separate articles from tools

Articles answer “why” and “how to check”: for example, why encryption stays in the current tab, and why a # fragment never enters an HTTP request. To generate a password, clean a link, or create a Burn-Link, open the matching tool page—you do not need to finish the article first.

How this differs from tool pages 01 Articles explain mechanics and how to check them. To generate, clean, or encrypt, open the matching tool page.
Do I need an account to read? 02 No. Open and read. The top bar only has a language switch—no sign-in.
Are examples uploaded 03 No. Examples only explain local computation. Plaintext stays out of the request body by default; Burn-Link only submits ciphertext.
Can the server see the # key 04 HTTP requests do not carry the # fragment. The key stays in the address bar and is not sent with the request.
Will this become a web-wide lookup 05 No. The audit is local strength plus a public weak-password list, not Have I Been Pwned.
04 / Next

When you finish, go check

Articles are not a substitute for the tools. To send ciphertext once, encrypt a file up to 5 GB locally, or confirm we are not a password manager, open the matching page.