KeePass Web isn't a service you sign into — it's a handful of HTML files you can open directly, with no backend behind them at all. Each page is a single, un-minified, self-contained HTML file: open it in a text editor and you're reading literally everything it does. There's no server processing your data, no account, no extension to install, and no build step to view the source — unlike password managers that also encrypt client-side but still run on infrastructure you have to trust. It reads and writes KDBX database files — the same format used by KeePass, KeePassXC, Strongbox, KeePassium, and others.
KeePass Web is in the final stages of reaching a stable, GA 1.0 release. The
infrastructure — the domain, GitHub Pages, sponsorship tiers, and organization
documentation — has been in place since June 2026, and pre-1.0 versions with
full KDBX read and write support and a Google Drive connector are already
published on the GitHub releases page and served identically at
keepass-web.app. Dropbox and OneDrive connectors, WebDAV support, and
older KeePass 1.x .kdb database support are not part of GA scope; each may
follow in later releases as demand warrants.
These are beta releases. We'd welcome beta testers willing to put a real (or throwaway test) database through its paces and report what breaks — open an issue with what you found, or follow and comment on our GA tracking issue to see what's left. Follow development at github.com/keepass-web.
KDBX is an open, well-documented file format for storing passwords and secrets. It uses strong encryption and tamper-evident protections. Because it is an open format, many independent applications can read and write it. Your passwords are not locked to any single vendor — including us.
Any modern desktop browser that supports WebCrypto: Chrome, Firefox, Safari, Edge, and terminal browsers such as Browsh and Carbonyl. WebCrypto is the only browser API KeePass Web requires.
You don't have to take our word for it. Each page of KeePass Web is a single,
un-minified HTML file. Open the one you are about to use in a text editor before
you open your database.
Watch the browser network tab while it runs — you will see no outbound network
requests. Check the Application (or Storage) tab too: no cookies are set, no
localStorage or sessionStorage keys are written, no IndexedDB database is
created. KeePass Web persists nothing about you or your vault in the browser,
session or otherwise — close the tab and there is no trace. The one exception
is a cloud connector's own sign-in provider: if you use Google Drive, Google's
own sign-in library may set cookies or storage entries under google.com to
manage its session — that's Google's mechanism, on Google's origin, not ours.
The source code is published on GitHub, open for anyone to read, review, and
report issues against.
None that can see your database or your master password — but a few sit upstream of how the software reaches you, and knowing them is part of verifying it yourself:
- GitHub hosts the source, runs CI, builds and signs each release, and serves keepass-web.app via GitHub Pages. It's a single point of centralization we've accepted; see the "What happens if keepass-web.app shuts down?" answer below for the mitigation.
- The npm registry, for build-time tooling only (TypeScript, Biome,
jsdom, and similar) — never anything that ships to your browser. Every
version is pinned exactly in
package-lock.json, every package's integrity hash is verified bynpm cibefore install, and none may run an install script — a CI check with no allow-list fails the build if one does. See Dependency policy. - A container base image (
node:22-slim), pinned by immutable digest rather than a mutable tag, used only to give anyone a reproducible environment to rebuild a release from source in. - GitHub Actions (checkout, setup-node, CodeQL, attestation) — every action is pinned to a full commit SHA rather than a tag, so a compromised or re-tagged action upstream can't silently change what CI runs.
- Sigstore, which signs and publicly timestamps a build-provenance record for every release, so anyone can confirm which commit produced which published bytes.
- Google, only if you open the Google Drive connector, and only after
you click sign in — it loads Google's own SDK, scoped to
drive.file(files you explicitly pick), never anything broader. Any cookies or browser storage that sign-in uses are Google's own, set under its domain — KeePass Web itself never writes a cookie or a storage entry anywhere.
Anyone can independently rebuild a release from source and compare its checksum against the published one; see Reproducing a build for the exact steps we use ourselves.
Security software that depends on third-party libraries inherits that library's security fix schedule. If a vulnerability is discovered in a dependency, we are blocked on someone else's availability and priorities to ship a fix. By owning the parser ourselves, we control when fixes ship.
Every dependency is an attack surface and code you cannot fully audit. We keep the codebase small enough that a technically literate user can read all of it. Frameworks make that impractical.
For questions and feedback, start a GitHub Discussion. For bugs, open an issue. For security vulnerabilities, email security@keepass-web.app — please do not open a public issue for security reports.
Visit github.com/sponsors/keepass-web and choose a tier. It doesn't unlock anything — nothing is gated, and it isn't earmarked for any specific cost. Sponsorship is a signal: it tells us the software is valuable enough to the people using it that they want to support the people building it. The whole application — cloud connectors included — is open to everyone, whether you download it or open keepass-web.app.
A cloud connector opens your KDBX database straight from your own cloud storage — Google Drive, with more providers over time — instead of from a file sitting on the machine in front of you. You sign in to your provider, choose your database, and it opens in the browser; your edits are written straight back to the provider. The database itself never lands on the local disk.
There are two reasons you might want that. On a machine you don't control — a library terminal, a kiosk, a borrowed laptop — nothing is left behind afterwards, because your vault was never on the disk to begin with. And even on a machine you trust, keeping the authoritative copy in your cloud storage means there is no second copy to manage: no download-edit-reupload cycle, no stale or forked local files, and no unsaved local edits to lose if the machine crashes. Your vault stays in one place, reachable from any browser.
Google Drive at the first release. Dropbox, OneDrive, and WebDAV (Nextcloud, ownCloud, and similar) are planned for later releases as demand warrants.
No. The connectors are open to everyone. The application is MIT-licensed and its source is public, and it connects to your own provider with your own sign-in — no sponsorship required, and no storage of ours involved. Sponsorship isn't a fee for access; it's how people who find the software valuable choose to say so.
Yes. Two things are independent: where the pages run, and where your database lives. You can run the pages from a download or from keepass-web.app, and with either you can open a database from a local file or from your cloud storage. Running the pages you fetched and audited yourself while keeping your vault in the cloud is a perfectly ordinary combination — and often the point, since it keeps the database off the machine entirely.
Download the release from our GitHub releases page and open
index.html in any supported browser; it links to the other pages. From there you
open a KDBX database — a local file, or one in your cloud storage — and navigate,
copy, edit, and save your secrets. A local database saves by downloading the
updated file back to your machine; a cloud database is written straight back to
your provider.
That depends on where your database is, not on where the pages came from. Open a local database file and nothing leaves your browser after the page has loaded — no network requests at all. Open one through a cloud connector and the only traffic is between your browser and your storage provider, to fetch and save the database; your master password and decrypted secrets still never leave the browser. Either way there are no KeePass Web servers in the path, which you can confirm in the browser network tab.
Two reasons. It fits: the whole project is a set of self-contained web pages
you open directly, no install and no account, so ".app" says exactly what it
is. More importantly, .app is on the HSTS preload list
built into Chrome, Firefox, Safari, and Edge — every domain under .app is
forced to HTTPS at the browser level, before a single request goes out, with
no reliance on our TLS configuration, a redirect, or a header we could get
wrong. For a project whose trust model rests on "watch the network tab and
verify it yourself," having HTTPS enforced structurally, not by our
diligence, removes one more thing you'd otherwise have to take our word for.
keepass-web.app is served by GitHub Pages — there are no KeePass Web servers. The domain resolves to GitHub's infrastructure and serves a static file from a public repository. You can verify this by checking the repository at github.com/keepass-web/keepass-web.app.
Yes. Each distributable served at keepass-web.app is byte-for-byte identical to the same file in our GitHub releases. You can verify this by comparing checksums. We assert this openly because your trust in the served copies should be grounded in your ability to read and verify the ones you download — not in our word alone.
No. There are no KeePass Web servers — keepass-web.app is a static file on GitHub Pages. Decryption happens entirely in your browser. Your master password is never transmitted. If you open a database from cloud storage, your browser fetches it directly from your provider. You can verify this in the network tab: after the initial page load, any requests go to your storage provider, never to keepass-web.app.
Everything the project relies on — the app at keepass-web.app, source code, releases, and sponsorships — runs on GitHub. If we lose access to GitHub, or GitHub itself disappears, keepass-web.app goes with it. We think that is an acceptable risk: GitHub is well-established, the software is MIT-licensed so anyone can fork and host it, and most importantly, your passwords stay wherever you chose to keep them — a USB stick, a local drive, your own cloud storage, wherever. They were never ours, and where they live was never tied to whether keepass-web.app is up.
Download the pages from any surviving fork, from a copy the Internet Archive's Wayback Machine has captured, or open your database directly in KeePassXC, Strongbox, KeePassium, or any other KDBX-compatible client. You are never locked in.
Better than relying on any fallback: download and keep your own local copy of the current release now, from the releases page, rather than waiting for a shutdown to force the issue. It costs nothing, it's the exact file keepass-web.app serves, and you can verify that for yourself against the published checksum.