Local-first encrypted vault — embrangle.org
Embrangle is a single encrypted file — passwords, notes, cards, bookmarks, and contacts, sealed with AES-256-GCM before anything touches disk. There's no account, no server, and nothing syncs unless you move the file yourself.
.emb file you load and export yourself. No account, no server, no background sync.
Architecture
Most apps protect everything with a single password — break it, and the attacker has everything. Embrangle's master passphrase still protects the whole vault, but every item underneath it gets its own independently derived key, and any individual item can carry a second passphrase that survives a master-key compromise entirely.
For most people, the master passphrase is the foundation and the whole story — it's strong on its own. A 600,000-iteration PBKDF2 derivation makes offline brute-force attempts prohibitively slow.
Per-item passphrases are for the handful of things that genuinely warrant a second secret: a recovery seed phrase, backup codes, a single shared credential. Section passphrases are a lighter touch — useful if someone else might pick up your unlocked device.
If you forget a passphrase, whatever it protects is permanently inaccessible. That's deliberate: no one can be pressured or tricked into unlocking it on your behalf.
Format
Every item — a login, a card, a contact — is a title plus a list of fields. Each field is tagged with a single-character symbol that tells the app how to handle it: whether it's masked, copyable, a URL, or a TOTP secret. This field array is what gets sealed under the item's own key; the app rebuilds the UI from it after decryption.
An item's type and title are what populate the hub and item list once the vault is unlocked. The fields array is different — it stays sealed under the item's own key until you open that specific item, and is decrypted only into memory.
Two field-level markers add extra protection beyond encryption: ! (Permanent) warns before copying or revealing a value you likely can't rotate — recovery codes, seed phrases. ; (Re-auth) requires your passphrase again before that specific field can be revealed or copied, even within an already-unlocked vault.
Revealed fields re-mask themselves after 45 seconds, and anything copied to the clipboard is wiped after 30 — whether or not you come back for it.
Vault file
Your vault is a single .emb file containing two things: a salt, and an encrypted blob. Every item, folder, title, and section lock lives inside that one ciphertext. Anyone who got hold of the file — even with full knowledge of how Embrangle works — would find a salt and a string of bytes, and nothing else.
A plain JSON file — readable structure, unreadable contents.
Stack
Embrangle runs as a web app — which means the code running on your device is readable. Open your browser's developer tools and watch the network tab: nothing is sent anywhere, ever. You can see exactly what gets encrypted, when, and with what. That level of transparency is harder to offer in a native app, and it's a deliberate choice.
| Layer | Technology | Role |
|---|---|---|
| Frontend | HTML / CSS / JS | Single-page app. No build step, no framework, no dependencies. |
| Encryption | Web Crypto API | PBKDF2, HKDF, and AES-256-GCM. Entirely client-side, never leaves the device. |
| 2FA codes | Web Crypto (HMAC-SHA1) | Standard TOTP, generated locally from a stored secret — nothing phones home. |
| Storage | .emb file (JSON) | Loaded and exported manually. No database, no server, no background sync. |
Non-Goals
These aren't oversights — they're the tradeoff for not trusting anything beyond your own passphrase. Every item below would require an account, a server, a background connection, or some other party in the loop.
Backups, multi-device access, and recovery are all on you — by design.