Proposal: browser-side KeePass/KDBX export from the web vault

[eduard156d]

I would like to discuss a possible contribution adding KeePass/KDBX as an export
format in the web vault, building on the existing
KDBX feature request.
The goal is a portable, encrypted file usable directly in KeePassXC, without a
plaintext intermediate export or a separate conversion server.

Proposed user flow: select KeePass/KDBX in the existing export dialog, choose a
separate database password, complete the existing export verification, then
download the encrypted file. Conversion would run locally in the browser using
an established KDBX library. Vault plaintext and the database password must not
be sent to a server, telemetry, logs, or persistent browser storage. Existing
authentication, user verification, organization permissions and export policies
must remain effective.

The scope needs explicit agreement and compatibility tests:

• Personal vault items: define mappings for supported item types, fields,
  folders, notes and TOTP data; report unsupported data rather than silently
  discarding it.
• Organization items: preserve meaningful collection information and respect
  export authorization, including cases where reading an item does not permit
  exporting it.
• Attachments: embed permitted files and verify contents, sizes, duplicate
  names, download failures and browser memory limits.
• Stored passkeys: distinguish exporting credentials from passkey-based vault
  login. Require successful authentication with exported synthetic credentials
  in KeePassXC; copying fields alone is not a compatibility claim.

Tests would cover synthetic fixtures, wrong passwords, malformed inputs,
permission denials, cancellation, mobile resource limits and regressions in
existing exports. Any incomplete result should be clearly identified before
the user relies on it as a backup. This is not a proposal for synchronization
or a complete server backup.

In parallel, I am exploring a small independent export web app as an early
feasibility exercise. It is not an existing working product, and compatibility
and security remain to be demonstrated. Findings could inform an upstream
contribution without requiring changes to Vaultwarden.

Before starting an upstream implementation, would maintainers be interested in
this direction? What initial scope, library/security requirements and acceptance
tests would you recommend, and is bitwarden/clients the appropriate repository?
Community feedback on the workflow and required data types would also help.

[github-actions[bot]]

✨ Thank you for your code contribution proposal! While the Bitwarden team reviews your submission, we encourage you to check out our contribution guidelines.

Please ensure that your code contribution includes a detailed description of what you would like to contribute, along with any relevant screenshots and links to existing feature requests. This information helps us gather feedback from the community and Bitwarden team members before you start writing code.

To keep discussions focused, posts that do not include a proposal for a code contribution will be removed.

• 💡 For feature requests and general discussion, please visit the Bitwarden Community Forums.
• ℹ️ For questions and support, visit the Bitwarden Help Center.
• 🐛 To report a potential bug, please visit the corresponding repo. Server | Clients | iOS | Android

Thank you for contributing to Bitwarden!