PasswordMatic never asks you to create an account, which means it never stores your history on our servers either. Everything you generate lives in the browser you generated it in. That is great for privacy and terrible the day you buy a new laptop. This article covers the two ways to bring your history with you, and it explains — in more detail than the app itself has room for — the trade-offs behind the encrypted transfer option, so you can decide whether it is right for you.
The password and UUID history you see in PasswordMatic is stored in your browser's localStorage. It is not synced anywhere, not backed up anywhere, and not tied to any account, because there is no account to tie it to. That is the point: nobody but you, on that one device, can see it.
It is also the limitation. A new laptop, a new phone, a browser reinstall, or a cleared profile, and the history is simply gone. There is no password reset, no support ticket, no recovery email — the data was never anywhere else to recover it from. If you want it somewhere else, you have to put it there yourself, and PasswordMatic gives you two ways to do that.
Open the Export menu above your history and choose Download .csv or Download .txt. The file is built in your browser and handed straight to you; nothing is sent anywhere, and PasswordMatic's servers never see it.
The CSV has a header row and one entry per line, quoted so that a note containing a comma or a quote mark does not break the format. The TXT file is one entry per line, value and name separated by a tab. Both formats are scoped to whichever list you were viewing — passwords or UUIDs — never both.
Say this plainly, because the download button does not shout it at you: the file is not encrypted. Anyone who opens it can read every password inside. Treat it the way you would treat a printed list of your passwords — fine as a short-lived backup on your own encrypted drive, not something to leave in a Downloads folder or attach to an email.
If downloading a plain-text file feels like the wrong trade-off, the Export menu also has Online Export, which copies your history to another browser — your original stays exactly where it is — without ever writing an unencrypted file to disk.
Choosing it opens a QR code, a ten-character code in large type, a copy-link button, and an optional email field. From here there are two paths:
Either way, you land on the same import page. If the browser you are importing into has no history yet, the transferred entries are simply saved. If it already has entries, you are asked to choose: Merge, which adds the new entries and fills in any missing notes without disturbing what is already there, or Replace, which overwrites the list and tells you how many entries that will discard.
Password history and UUID history are transferred separately. Exporting from the password page can only be imported into a password history, and the same is true for UUIDs — there is no way for one to overwrite the other by accident.
A transfer sits on our server only long enough to cross from one browser to another, and we deliberately kept that window short. Four reasons:
It is tempting to think of the transfer code as a PIN, like the four digits that unlock a phone. It is not. The code is the encryption key.
Encryption happens entirely in your browser before anything is sent anywhere. The server only ever stores a blob of ciphertext it has no ability to read. That design only holds up if the code is hard to guess offline — because if someone obtained a copy of the encrypted database, a four-digit code would let them try all ten thousand combinations in well under a second. Ten characters, drawn from an alphabet with the confusing look-alikes removed, is long enough that guessing it offline is not a realistic attack. That length is also exactly why the QR code exists: nobody wants to type ten characters by hand if a camera can do it for them.
Email is not a secure channel. Messages sit in inboxes for years, get forwarded, get read over someone's shoulder, and occasionally get read by whoever broke into the account. Because of that, the emailed link and the code are never sent together.
The link by itself opens nothing more than a page asking for a code. The code by itself unlocks nothing without the link it belongs to. We will say this outright rather than bury it in a footnote: anyone who has both the link and the code can open the transfer and read your history. That is exactly why they are never sent through the same channel. The QR path keeps the code out of email entirely by putting it in the part of the link that a phone reads locally; the plain email path relies on you reading the code off your own screen rather than out of your inbox.
We never receive the code. In the QR link, the code sits after a # in the URL — the fragment — and every browser treats that part of a URL as purely local; it is never sent to any server, ours included. When you type the code by hand on the import page, it stays in your browser and is used only to decrypt the blob you already fetched.
What we do hold, for up to an hour, is an encrypted blob we cannot read without your code, a timestamp, a count of how many entries it contains, and the recipient's email address if you chose to send one. The blob itself is encrypted twice: once in your browser under your code, and again on our server under a key that lives only in our filesystem, never in the database. A leak of the database alone — through a bug, a backup, anything short of the server itself being compromised — would hand an attacker ciphertext they cannot open, because they would be missing both the filesystem key and your code.
Three messages cover everything that can happen on the import page:
In every case, the fix is the same: go back to the original browser and export again. Because nothing sensitive is retained on failure, there is no cleanup to do and nothing left over to worry about.
Open your history and try the Export menu on either device.
Generate Secure Password