# Cryptee web client: reading the part of an encrypted app you can actually verify > Cryptee publishes the front end of its privacy platform while keeping the backend closed, and the README argues the choice in terms of verification rather than trust, since a client-side encryption design lets you read the code that handles your data. The client is built with Codekit and jQuery, a deliberate choice for a small team that ships quickly. **cryptee/web-client** — Cryptee's web client source code for all platforms. - Repository: https://github.com/cryptee/web-client - Website: https://crypt.ee - Stars: 533 · Forks: 27 - Language: JavaScript - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cryptee-web-client ## What is published and what is not This repository holds the source code for Cryptee's web client across all platforms, and the separation between the client and the server is the whole point of the design. The top level of the repository is small and reflects that: a .github/ directory, a license.md, a readme.md, a security.md and a source/ directory. The README opens by welcoming two kinds of visitor, one who is serious about security and privacy and one who just wants to copy and paste some code, and the closing line of that paragraph is the interesting one, since thanks for checking out Cryptee's source code tells you that the code is meant to be read. The homepage is crypt.ee, the repository is on the v3 default branch, the primary language is JavaScript, and the project is not archived with the last push on 2026-08-03. The repository listing records the licence as a custom one that GitHub cannot classify, so a reader who wants to reuse any of this code has to read license.md directly, and the presence of a separate security.md is the second hint that this is a project that expects careful reading rather than casual copying. ## The security contact is separated from the issue tracker The security and issues section is short and it draws a distinction that any project handling private files has to draw. If you find any critical security issues, you should reach out using an address given in the README in an obfuscated form, written as security at crypt dot ee. Otherwise you are invited to file bug reports and issues on GitHub, and the tone there is deliberately informal, with the README describing the issues section as meme and emoji friendly, asking people to use fun GIFs, and noting that issue and feature reports with relevant memes will win some free storage. There is a sentence defending that choice directly, saying that this does not mean Cryptee is not a serious product or company, and that it just means you can relax, and that everyone is human. Underneath the informality, the structure is the standard one for a security-conscious project, with a private channel for anything that could compromise users and a public tracker for everything else, and a written policy telling contributors what belongs where before they file it. ## Why jQuery and Codekit, argued from the size of the company The section on frameworks is the most direct writing in the README, and it starts by anticipating the reaction it expects, with the reader imagining phrases like why jQuery, why Codekit, why not Angular or React or Grunt, and the answer being to take a deep breath. The reasoning that follows is a statement about constraints rather than about technology. When you are a small company, living frugal to ship as quickly yet as reliably as possible, when your livelihood depends on how quickly you can ship new features, and you are building a product used by thousands of people every day to gain some level of security or privacy online, one thing becomes clear, and the thing is that you do not want to depend on ever-changing massive frameworks, backwards compatibility issues, or licences that a large company can change under you, with a link to the article about React's licence change included as the example. The chosen stack is Codekit with jQuery syntax, and the README notes in a struck-through aside that it once used zepto as well, tiny at around nine kilobytes, to make coding easier, and that it has since been given up. That is a small detail that tells you something about how the stack evolved, since replacing a library wholesale is exactly the kind of dependency churn the paragraph argues against, and here it happened anyway and was noted honestly. ## The argument for a closed backend is a verification argument The longest part of the README explains why the backend is not open source, and the reasoning has three numbered steps. The first is practical, that the main reason for the hesitation is that opening the backend risks exposing the tightly integrated abuse-prevention systems, and that sign-up abuse is not sustainable for a small company, financially or technically. The second is the interesting one, and it argues that there really is no trust benefit to opening the backend, for two reasons. The first is that it is not possible to verify the code that is actually running on the backend, so the code you publish is not the code that executes. The second is that this is exactly why all the encryption happens on the front end, so that you do not have to trust black-box servers running unverifiable code, and that once you read the front-end source code you can verify that your data never leaves your device unencrypted. That is a coherent position and it is one that privacy tooling projects arrive at often, since the client is where the data passes and the server is where the data arrives already encrypted. The third step handles the recurring request, which is to open the backend so that some users could run it on their own servers. The answer is that Cryptee is a project built for everyone to have a secure home for their files, that the largest majority of internet users are not tech-savvy and cannot and should not have to set up their own servers, and that spending the limited resources available on making the backend self-hostable on any given server is a massive undertaking that is unsustainable for a business at that size. ## Where this repository is the wrong starting point The first limit is the obvious one, and the README states it plainly, so it is worth repeating in a different form for anyone planning an evaluation. There is no backend here, so you cannot run this application yourself, and the only thing you can do with the code is read it, audit it, or copy pieces of it into something else. The second is the framework choice, and it is a deliberate one rather than a mistake, but it means the code is jQuery and Codekit, which is a stack a new team would not choose today and which a new team would have to learn before contributing. If you are evaluating this repository as a base for a project, that is a real cost. The third is the licence, which GitHub cannot classify and which therefore has to be read by hand, and the repository listing not resolving it is a genuine friction for anyone trying to automate a licence check. The fourth is the tone, and this is a lighter point but a real one, since the README asks for bug reports decorated with memes and GIFs, which is a pleasant culture but not a signal of the level of documentation a large engineering organisation would expect. The fifth is the verification claim itself, which is strong but narrower than it first appears. Reading the front-end source tells you what the client does with your data, and it tells you a great deal, since the encryption happens there. It does not tell you what the server does with the metadata it inevitably receives, such as the fact that an account exists and when it was used, and no client-side design removes that. The README's own argument about abuse prevention implies a server that must know about accounts, so the privacy claim covers the content of the files and not the fact of their existence. ## Conclusion Adopt the Cryptee web client as a reference if you are building an application where encryption happens in the browser and you want to show your users the code that protects their files. Skip it if you need the full server side, since the backend is deliberately not open source, and skip it if you want a modern component framework, since this codebase is jQuery and Codekit by choice. Verify first which branch you want, since the default branch is v3, and read the licence file yourself, since the project uses a custom licence that GitHub cannot classify. ## FAQ ### What is in the Cryptee web client repository and what is not? The repository holds the source code for Cryptee's web client across all platforms, with a .github/ directory, a license.md, a readme.md, a security.md and a source/ directory. The backend is deliberately not open source, and the README argues that opening it would expose abuse-prevention systems and would not add trust, since it is not possible to verify the code actually running on a server. ### Why does Cryptee use jQuery and Codekit instead of a modern framework? The README argues that a small company shipping quickly and reliably should not depend on ever-changing massive frameworks, backwards compatibility problems, or licences that can change under them. It uses Codekit with jQuery syntax, and previously used zepto, around nine kilobytes, which it has since given up. ### How do I report a security problem in Cryptee? Critical security issues should be reported privately using the address given in the README, written in an obfuscated form as security at crypt dot ee, and everything else goes in the GitHub issue tracker, where the project says bug reports with fun memes and GIFs can win some free storage. The project is on the v3 default branch and its site is crypt.ee. ## Sources - [cryptee/web-client on GitHub](https://github.com/cryptee/web-client) - [Issues](https://github.com/cryptee/web-client/issues) - [Project website](https://crypt.ee) - [README](https://github.com/cryptee/web-client/blob/v3/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cryptee-web-client