Password export converter

No. The converter is a WebAssembly module that runs inside this browser tab, and the conversion happens on the text in the box — there is no upload, no server round-trip, no analytics on what you paste. You can prove it to yourself by opening your browser's network panel before converting, or by loading the page, going offline, and converting anyway.

That said, a decrypted export is a plain-text copy of every password you own. Convert it, import it into the new manager, then delete both files and empty the trash.

Yes, as long as Carry two-factor (TOTP) secrets across is left on. This is the single most common thing lost in a migration: several popular converters drop the TOTP column outright, so the new manager imports the password but not the authenticator code.

Bitwarden, KeePass/KeePassXC, LastPass and the generic spreadsheet format all have a TOTP column, so the secret moves straight across. Chrome's CSV format has no such column — rather than throw the secret away, it is written into that entry's note, where you can copy it into an authenticator by hand. Turning the option off strips 2FA secrets from the output entirely, which is what you want if you are exporting a list to share.

Folders map to whatever the target calls them — a Bitwarden folder becomes a KeePass group and a LastPass grouping, and back the other way. Entries with no folder stay at the top level unless you name one in the folder box, which is handy when you want everything filed under Imported.

Custom fields, card details, identity details and secondary URIs have no column in most target formats, so with Keep custom fields, card and identity details in the notes on (the default) they are appended to the entry's note as labelled lines. Secure notes come across as entries with no password. If the manager you are importing into rejects rows with an empty password column, turn on Drop entries that have no password and those rows are left out.

No. Both the reading and the writing side go through a real RFC 4180 CSV parser, so a password containing a comma, a double quote or even an embedded newline is parsed as one value and re-quoted correctly on the way out. This is a genuine failure mode elsewhere: managers disagree about CSV escaping, and the usual symptom is a run of entries importing with empty or shifted fields.

The one thing that does break it is an export whose header row has been edited or removed by hand. If auto-detection then guesses wrong, pick the source format from the dropdown yourself.

Detection works off the shape of the file: a leading { or [ means Bitwarden JSON, and otherwise the header row decides — login_password means a Bitwarden CSV, grouping plus extra means LastPass, Title plus Group means KeePass, name/url/note means Chrome, and anything else carrying a password or username column is read as a generic spreadsheet.

If you renamed or reordered the header cells, two dialects can look alike, and the guess goes wrong. Set Format you are converting from explicitly and the guess is skipped. If the header is missing entirely, the conversion is refused rather than silently mangled — add the header row back and try again.

Not directly. A .1pux file is a zip archive rather than pasteable text, and a .kdbx file is an encrypted database that needs a master key to write — that is a different job from converting between text export formats.

The practical route for both is one hop through a format that is text: export 1Password to CSV and convert that, or convert to KeePass CSV and let KeePassXC import it into your .kdbx database. Firefox's CSV export works too — it is Chrome's layout plus some extra metadata columns, and the reader accepts it as-is.