Three checks you can repeat
MakePwd is a browser-first encryption and privacy tools site. The claims on this page match the current implementation. We do not claim GDPR or other certifications, and “local-first” is not absolute zero logs. Ordinary page requests may still leave technical records such as IP, path, and time.
Work stays in the tab
Password generation, strength checks, link cleaning, text redaction, and file encrypt or decrypt use Web Crypto or on-device scripts. Your plaintext is not uploaded by default.
No account to breach
There is no sign-up, sign-in, or password vault, so there is no stored collection of your saved secrets to steal. Every tool opens ready to use.
The front end is inspectable
Static scripts and tool pages live on this origin. DevTools Network can confirm that passwords under test, files, and Burn-Link plaintext should not leave the browser as business requests.
Algorithms and limits
These numbers match the live site.
| Item | Implementation | Where you can check |
|---|---|---|
| Symmetric cipher | AES-256-GCM (authenticated encryption) | Burn-Link and File Encryption Box copy and scripts |
| Crypto API | Browser Web Crypto API | DevTools Sources, or any current browser implementation |
| File key derivation | PBKDF2, 100,000 iterations | File Encryption Box scripts |
| Random password length | 6–128 characters, default 16; below 8, the UI warns that strength is low | Password Generator |
| File size | Up to 5 GB per file; output .lock / .enc |
File Encryption Box |
| Burn-Link text | 32 KB per item; default 24 hours and 1 read; expiry 0–168 hours; reads 1–10 | Burn-Link create page |
| Burn-Link key transport | 256-bit random key, Base64URL in the # fragment |
Full link shape s.html?id={id}#{key} |
Where each tool computes
“Not uploaded” means the content is not sent as a MakePwd business field and is not written into analytics events. Hosting still may see ordinary HTTPS technical metadata.
| Tool | Stays on this device | What leaves the browser |
|---|---|---|
| Password Generator | Random characters or a readable passphrase | No business upload; you keep whatever you copy |
| Password Audit | The password you type, the strength estimate, and the local list check | Nothing. No Have I Been Pwned call or other remote lookup |
| Privacy Cleaner | URL stripping, text masking, and before/after view | Nothing. Source text is not written to analytics |
| File Encryption Box | The file, passphrase, derived key, and encrypt/decrypt result | Nothing. You download the result locally |
| Burn-Link | Encrypting plaintext, generating the key, and decrypting on the recipient device | Ciphertext only, plus expiry and maximum reads |
Burn-Link threat model
On create, the browser encrypts first, then uploads. The server returns an unguessable id; the page builds s.html?id={id}#{key}. The query string holds only the id. The key lives after #.
What this is meant to stop
- The server holds ciphertext and metadata, not the
#key, so it usually cannot recover plaintext - After the read limit or expiry, the ciphertext is deleted; a later open reports burned or expired
- A lost link cannot be recovered from this site: there is no plaintext copy and no separately stored key
- Create is rate-limited by IP to slow abuse, not to identify you
What this cannot stop
- Anyone with the full link can decrypt on their device
- Screenshots, copy-paste, or someone retelling the secret
- Pasting the full link into tickets, monitors, or chat archives that log URLs
- A recipient device with a keylogger or a hostile extension
The reader page is marked noindex. Send the full link, including #, only to people you trust, and avoid systems that log the entire address bar.
What this design cannot stop
On-device crypto reduces the risk that a website quietly takes your plaintext. It is not a general security guarantee.
- A compromised browser or extension can read page input. Site script cannot police that.
- Look-alike phishing domains can send content elsewhere. Check that the address bar is makepwd.com.
- Short or guessable secrets: below 8 characters the generator warns that strength is low. File-box strength follows the passphrase you choose.
- What happens after you share: once a result sits in chat, mail, or a drive, those services and the recipient decide what happens next.
- Hosting and access logs: IP, path, and the reader
idmay still appear in transport records. By browser rules, the#fragment should not enter the HTTP request.
How to verify it yourself
You do not have to take the slogan on faith. The current browser is enough.
- Open DevTools Network, generate a password or audit one. The requests should not contain the plaintext you just typed.
- Create a Burn-Link and inspect the address: query has only
id, key after#. The create body should be ciphertext plus expiry and reads, not the original text. - Encrypt a small file and confirm you download
.lockor.enc, with no POST of the original file to a MakePwd API. - For a longer walkthrough, read How to verify browser-local encryption.
Related pages
This page is the threat model and the checks. Data handling lives on the legal pages; use rules live in the terms.
FAQ
Where does MakePwd encrypt data?
Randomness comes from the browser Web Crypto API, and the result stays in the current tab. MakePwd does not upload generated passwords and does not write them to analytics. After you copy a result into chat or cloud storage, you control how it is kept.
Why does Burn-Link put ciphertext on a server at all?
The recipient needs an address they can open. Text is encrypted on this device with AES-256-GCM first. The server only stores ciphertext, expiry, and read count. The decryption key sits in the # fragment and, by browser rules, is not sent with the HTTP request.
Does Password Audit send the password to Have I Been Pwned?
No. Strength estimates and the check against the built-in public weak-password list both run on this device. This is not a live internet breach lookup and does not call an external pwned-password API.
Can MakePwd stop the recipient from taking a screenshot or forwarding the secret?
No. Burn-Link deletes the ciphertext copy on the server. Once the recipient decrypts it locally, they can copy, screenshot, or retell it. Giving someone the full link including # hands them the decryption key.