Import / Export Across Password Managers: Format Reality Check (1Password, Bitwarden, KeePass)
A field guide to .1pif, .json, .csv, .kdbx — what each format actually contains, what gets lost in translation, and how to migrate your vault without losing TOTP secrets, custom fields, or attachments.
Published: 2026-05-05 · 10 min read
Why You Should Care About Export Formats Before You Pick a Password Manager
You're going to switch password managers eventually. Companies get acquired, prices change, you change devices, the app you love gets deprecated. The single most important question to ask before picking one is: "How do I get my data out, and how complete is the export?"
This is the part nobody talks about in the marketing pages. The export format determines whether you can leave with your data intact — or whether you'll lose your TOTP secrets, your password history, your custom fields, your tags, and have to rebuild from memory.
Here's a practical comparison of how the major password managers actually export, what survives the round trip, and what ByteGuard does differently.
The Format Landscape
| Product | Export Formats | Encrypted | Lossy? |
|---|---|---|---|
| 1Password | .1pif (legacy), .1pux (zip + JSON), .csv | No (plaintext export) | 1pux is rich; .csv loses most fields |
| Bitwarden | .json (encrypted or plain), .csv | Optional (PBKDF2 + AES) | JSON is full; CSV loses TOTP, custom fields |
| KeePass | .kdbx (native), .xml, .csv | .kdbx is encrypted; .xml/.csv are plaintext | .kdbx round-trips perfectly |
| LastPass | .csv | No | Heavy losses: TOTP, attachments, secure notes formatting |
| Apple Keychain | .csv (Safari Passwords) | No | Logins only; no TOTP, no notes, no cards |
| Dashlane | .csv, .json | No | JSON has notes / IDs; CSV is logins-only |
| ByteGuard | .json (encrypted), .csv | JSON: AES-256-GCM with user-set passphrase; CSV: plaintext | JSON: 0 loss; CSV: lossy by design (warned) |
"Plaintext export" doesn't mean unencrypted in transit. It means once you have the file on disk, anyone with read access to that file has all your passwords in clear text. Treat plaintext exports as nuclear waste — generate, use within the hour, delete from disk + Trash + cloud sync.
What Actually Survives Export
The dirty secret of password manager exports is that format ≠ content. A .csv file from 1Password and a .csv from Bitwarden look the same on the surface (header row + data rows) but:
- 1Password .csv has
title, website, username, password, notes— that's it. TOTP gone. Tags gone. Custom fields gone. - Bitwarden .csv adds
folder, type, login_uri, login_totp— so TOTP survives if both ends agree on the column name. - Apple Keychain .csv from Safari only exports website logins — no notes, no cards, no IDs.
The same content gap exists in JSON exports, just less obvious. Bitwarden's JSON has a rich schema (folders, custom fields, attachments by URL); 1Password's .1pux is a zip with embedded files for attachments and a strict per-record schema. They don't translate to each other 1:1 — every importer has to map fields and decide what to drop.
The Lossy Fields (Ranked by Impact)
- TOTP secrets — Catastrophic. Lose these and you're locked out of every 2FA-enabled service until you re-enroll. Most CSV exports don't include them.
- Password history — Useful if a recent change broke a service or if you need to verify an old account. Almost never preserved across exports.
- Custom fields — Essential for storing recovery codes, security questions, license keys. CSV almost always loses them; JSON usually keeps them but with non-standard naming.
- Attachments — PDFs, scanned IDs, screenshots. CSV cannot represent. JSON sometimes references but doesn't bundle (you have to download separately).
- Tags / folders / favorites — Organization metadata. Survives JSON usually; CSV maps folder to a flat string column at best.
- Notes formatting — Markdown, line breaks, links. CSV preserves text but breaks formatting. JSON keeps as raw string.
How ByteGuard Handles Import / Export
ByteGuard supports importing from 6 sources:
- 1Password (.1pux, .1pif, .csv)
- Bitwarden (.json encrypted/plain, .csv)
- LastPass (.csv)
- KeePass (.kdbx, .xml)
- Dashlane (.csv, .json)
- Apple Keychain (.csv from Safari)
For each source, the import pipeline is:
Two design choices worth calling out:
- Detection over user input. We sniff the file format from headers / structure rather than asking "what app did this come from?". Less friction, fewer mistakes. (You can override if detection guesses wrong.)
- Dry-run preview. Before any record hits your vault, we show a preview: how many items, how many duplicates with existing entries, what fields will be lost (with explicit warning if TOTP isn't in the source). You confirm, then we commit.
The Export Side: Encrypted JSON as the Default
For export, ByteGuard offers two formats:
| Format | Use when | Encryption | Field coverage |
|---|---|---|---|
| Encrypted backup (.bytegx) | Backup, device migration, archival | AES-256-GCM with user-set passphrase + Argon2id derivation | 100% (every field, history, tag, custom fields) |
| Plaintext CSV | Migration to another password manager that only reads CSV | None (warned + recommended deletion timeline) | Logins only (TOTP, custom fields, attachments dropped — explicit warning shown) |
The encrypted JSON format is the same one we use internally for iCloud sync (just with a different key derivation source — passphrase instead of Master Password + Secret Key). That means a backup file is bit-identical in structure to what's already on disk, no special export pipeline that could miss fields.
A Quiet Win: KeePass .kdbx Round-Trips
Among all formats, KeePass .kdbx is the closest thing to a universal "long-term storage" format:
- Open spec (KeePass 2 file format is documented)
- AES-256 / ChaCha20 encryption with Argon2 KDF
- Rich field schema: title, username, password, URL, notes, custom fields, tags, color labels, expiration
- 20+ year format stability — files from KeePass 2.0 (2007) still open in current versions
If you ever need to put your password vault somewhere "safe for 10 years that nobody can take away from you", export to .kdbx. Encrypt, burn to optical media, store in a safe deposit box. That file will outlive whatever password manager startup you're using today.
ByteGuard exports to .bytegx (richer for our internal model) and .csv (for migrating out). We don't currently export to .kdbx — but it's on the roadmap, exactly because of the long-term archival use case.
Practical Migration Checklist
If you're moving into ByteGuard from another manager:
- Export from the source — prefer the richest format available (JSON > CSV)
- Verify TOTP secrets are in the export. Open the file, search for
totporotpauth://. If absent, you'll need to re-enroll 2FA after migration. - Run ByteGuard's import preview — review the count + drop list
- Confirm import. Spot-check 5 random entries (especially TOTP — verify the 6-digit code matches what your old manager shows for the same account)
- Only then delete the export file (Trash + cloud sync + optional secure-delete)
- Wait 24 hours, use ByteGuard daily, ensure nothing important is missing
- Then revoke / cancel old manager subscription
If you're moving out of ByteGuard:
- Export to .bytegx (encrypted) for long-term archival
- Also export to .csv if migrating to a manager that requires CSV
- Note the lossy fields. Re-enroll TOTP at the new manager.
- Delete .csv after import succeeds
Key Takeaways
- Export format > everything else for long-term password manager choice. Pick a manager that exports rich.
- CSV is the lowest common denominator. Use it only for transit; never as a backup.
- TOTP is the most catastrophic loss. Always verify TOTP survives any export before trusting it.
- Encrypted JSON (with strong KDF and AEAD) is the right default for backup.
- KeePass .kdbx is the closest thing to a universal long-term archival format.
- Always run an import preview, spot-check, and keep the source file around for 24 hours before you delete.
Full crypto details for ByteGuard's encrypted JSON export are in the Security Whitepaper.