Encryptr

What Is Encryptr?

If you want cloud sync for passwords but don’t want the service provider to be able to read your vault, you’re looking for a “zero-knowledge” design: encryption happens on your device, and the server mostly just stores ciphertext. Encryptr’s whole pitch was exactly that—simple encrypted storage for a small set of secret types, synced through a cloud backend.

Encryptr keeps the scope narrow: it stores passwords, credit card numbers, and general key/value items (think secure notes in a structured form). It was built by SpiderOak (best known for encrypted backup tooling) and powered by SpiderOak’s Crypton framework, which was designed around end-to-end / zero-knowledge application patterns.

There’s an important reality check for anyone evaluating it in 2026: reputable third-party coverage and reference material report that Encryptr is discontinued (no longer active), and the last official release notes still visible are dated March 19, 2020. That makes Encryptr less of a “pick this today” product and more of a legacy app some people may still have data in (or may see mentioned in old privacy threads).

Encryptr Features and Performance

Encryptr was designed as a cloud-backed password manager / e-wallet with a zero-knowledge posture: you control your encryption keys, and the service is not supposed to have access to them. SpiderOak explicitly states in its privacy policy (covering Encryptr as one of its products) that users control encryption keys and SpiderOak does not have access to them.

What it stores (and what it doesn’t)

Functionally, Encryptr’s “vault” model is minimal by design. The project’s own README describes three data types: Passwords, Credit Card numbers, and general key/value pairs—and notes it can be extended to additional entry types.
What you should not expect from that description (and from the age of the product) is the modern “everything bundle” you get from actively maintained password managers: passkeys support, advanced sharing workflows, integrated 2FA token storage, admin policies for teams, and mature browser autofill. Those features are not part of what Encryptr publicly documented as its core.

Cross-platform apps (historically)

Encryptr was built as a cross-platform app: the README states it worked on Android, iOS, and Desktop, with the desktop app built using NW.js.

That said, platform availability is only half the story. With discontinuation reported and the last release notes dating back to 2020, “it runs” and “it’s safe to rely on in 2026” are different questions.

Security architecture basics (what’s actually documented)

Encryptr is explicitly described by SpiderOak as zero-knowledge and cloud-based.
Under the hood, Crypton (the framework Encryptr used) was built to push cryptographic operations to the client—encrypting/decrypting/signing/verifying on the user side. That design goal is described in independent Crypton audit material.

Crypton also used the Secure Remote Password (SRP) protocol for authentication flows, according to a developer write-up from the Encryptr author describing how Crypton avoids the need to store user passwords in the traditional way.

One more nuance: academic and technical discussions of Encryptr/Crypton describe AES-256 usage in the Crypton backend context, but these sources aren’t the same thing as a current vendor security whitepaper for Encryptr itself. Treat that as “this is what the Crypton design was described to use,” not as a current guarantee for a discontinued product.

Performance: what you can infer (and what you can’t)

Password managers usually feel “fast” because vaults are small and operations are local—until cloud sync, login, or key-derivation is slow. For Encryptr specifically, there’s no recent, credible benchmarking data in current sources. What can be said from the architecture is limited:

• It’s cloud-based, so initial login/sync depends on network and backend availability.
• Crypton’s model emphasizes client-side crypto work (encrypt/decrypt/sign/verify on the client), which is good for privacy but can be heavier on low-end devices compared with server-side processing.

Given the age/discontinued status, the bigger “performance” risk in 2026 isn’t speed—it’s reliability: whether servers still operate, whether apps still install/run on modern OS versions, and whether security assumptions still hold without updates.

Pricing and Plans

Your database lists Encryptr’s pricing model as free, and that lines up with how Encryptr was presented historically: a free, open-source password manager/e-wallet concept in public materials.

What we can’t responsibly claim in 2026 from the sources we reviewed:

• Any current paid tiers (monthly/annual) for Encryptr specifically.
• A current refund policy (refund windows only make sense for paid plans).

Some third-party reviews also describe Encryptr as free and note it is no longer active, which further supports treating it as a free legacy product rather than a commercial subscription offering.

Privacy and Security Assessment

Zero-knowledge posture (the core claim)

Encryptr’s strongest documented privacy claim is the “zero-knowledge” design goal. SpiderOak’s privacy policy states users control encryption keys and that SpiderOak doesn’t have access to them, and Encryptr is explicitly positioned as a cloud-based password manager under that policy.

That’s the good news. The “no BS” caveat: a zero-knowledge claim is only as strong as the implementation, update cadence, and auditability. With Encryptr reportedly discontinued, you’re not getting the ongoing patch pipeline you want for something that sits at the center of your digital life.

Open-source status (real, verifiable)

Encryptr’s source code is publicly available on GitHub under GPLv3, and SpiderOak’s repository describes it as a zero-knowledge, cloud-based password manager/e-wallet.

Open source is a plus for transparency, but it doesn’t automatically mean “audited” or “secure today.” It means outsiders can review it—if someone actually does.

Audits and external review (what’s documented)

We found published audit reports for SpiderOak Crypton (the underlying framework), including material describing SRP and the client doing the crypto heavy lifting. That’s relevant context because Encryptr is “powered by Crypton,” but it is not the same as “Encryptr received a recent, product-specific audit.”

So the accurate takeaway is:

• Crypton had third-party security audit work published.
• Encryptr depended on Crypton.
• There is no clear, current evidence in the sources we reviewed of an up-to-date, Encryptr-specific audit program.

Known criticisms and research flags

Encryptr is referenced in academic/security literature around password-manager weaknesses (for example, research discussing attacks like clipboard sniffing and keylogger exposure affecting password managers, with Encryptr mentioned among evaluated tools). The broad point is not “Encryptr is uniquely bad,” but that password managers as a category can leak secrets through OS-level features like clipboards and input capture—problems that are hard to solve purely inside one app.

Jurisdiction

SpiderOak is a U.S.-based company, and Encryptr was a SpiderOak product. Jurisdiction matters if you’re concerned about legal compulsion, gag orders, or metadata collection. A zero-knowledge design limits what a provider can hand over, but it doesn’t erase jurisdictional risk entirely (account metadata, timestamps, IP logs, etc., depending on what’s collected). The SpiderOak privacy policy explains what account information is collected and describes using SSL/TLS for transport; it also positions Encryptr under its products list.

Discontinuation risk (the big one)

Multiple sources indicate Encryptr is no longer active/discontinued, including an updated third-party review and reference material noting discontinuation in March 2021. The last Encryptr release notes page we found is dated March 19, 2020. For security software, that gap is a deal-breaker for most users.

Strengths and Limitations

Strengths

• Zero-knowledge design intent: documented positioning as zero-knowledge, with SpiderOak stating it can’t access user keys.
• Open-source code available under GPLv3, enabling independent inspection and forks.
• Cross-platform ambitions (Android, iOS, desktop) documented in the project materials.
• Simple data model (passwords, cards, key/value) that avoids feature bloat and reduces complexity in the UI layer.

Limitations

• Discontinued / no longer active: reported by reputable sources; last visible release notes are from 2020.
• Not a modern “full-stack” password manager: Encryptr’s documented feature set is minimal compared with current leaders (autofill ecosystems, passkeys, enterprise controls).
• Audit gap at the product level: Crypton has audit reports, but we didn’t find current evidence of ongoing Encryptr-specific audits.
• Usability trade-offs: even older coverage noted it could feel “ascetic” compared with other password managers—minimal UI and fewer convenience features.

Who Should Use Encryptr?

Good fit

1. You already have an Encryptr vault and need to access/export it (legacy use). In that case, your priority is safe migration to an actively maintained password manager.
2. Developers/security researchers who want to study a real-world zero-knowledge password manager implementation built on the Crypton framework (open source).
3. People evaluating historical SpiderOak/Crypton designs as part of a broader privacy engineering review (again: research use, not daily-driver).

Not a good fit

1. Anyone choosing a password manager for daily use in 2026. A discontinued password manager is a risk multiplier.
2. Teams/businesses needing admin controls, audits, compliance features, and supported integrations.
3. Users who want modern browser autofill and passkeys with ongoing updates across OS/browser changes.