How bun.ink protects your texts – encryption explained simply

A text is a personal thing. A half-finished chapter, research with sources nobody should know about, a diary entry from a bad day – that isn't just arbitrary data. Which is why the question "who can actually read this?" isn't a technical footnote for a writing app, but a question of trust.

This article answers it as precisely as we can – without jargon, but also without promises we can't keep.

Two layers – one for everyone, one for your diary

bun.ink protects content on two levels, and it matters that you keep them apart:

• Layer 1 – server-side encryption. Applies to all documents, without you having to do or configure anything. Your texts are not stored in the database as readable plain text.
• Layer 2 – the high-privacy folder. A special folder type that you create yourself. Its contents are encrypted in your browser. Nobody but you can read them – not even us.

Layer 1 is convenience without compromise. Layer 2 is maximum protection at a price you should know about. We'll cover both in turn.

First, briefly – what encryption actually does

Picture a text running through a machine and coming out the other side as unreadable gibberish. To do that, the machine needs a key – a long, random number. With that same key, the gibberish runs back into the original text. Without the key it is effectively impossible to reconstruct; not a puzzle you can solve with patience, but a computation that wouldn't finish within human lifetimes even with enormous data centres.

For this, bun.ink uses AES-256-GCM, the standard method that banks, government agencies and HTTPS connections also rely on. Two of its properties are practically relevant for you:

• Every save uses a fresh random value. The same text saved twice produces two completely different pieces of gibberish. So the stored data reveals nothing about two documents having identical content.
• Every encrypted text carries a seal. If anyone alters the stored data by even a single character, the text can no longer be decrypted – the tampering is caught immediately, instead of quietly handing back a corrupted text.

There's another principle: a separate key for every kind of data. Document contents, GitHub access tokens and backups each have their own. Anyone holding one of them could do nothing with the other data. The keys never live in the program code and never in your repository – only in the server's configuration and in a password manager.

Layer 1 – your texts are not stored as plain text in the database

When you save, your text goes into the database encrypted. The server encrypts it immediately before writing and decrypts it again after reading – in between, it is nothing but gibberish in the database. The same goes for saved versions (the snapshots of your text's history) and for your text snippets.

You won't notice any of it. Full-text search, version comparisons, conflict handling, GitHub sync: everything works exactly as before, with no perceptible delay – encryption of this kind operates in the range of milliseconds, not seconds.

What this protects you from:

• A database leak. Anyone who gains access to the database gets gibberish, not texts.
• A stolen or lost backup. Backups contain the same encrypted data – and are additionally encrypted themselves.
• Access via the database console. Even someone looking around in there – today, or as a future team member – does not see your content.

And now the honest part, because this point determines whether you need layer 2:

• Layer 1 is not "nobody can read it". The server needs the key in order to show you your text in the editor. Anyone with access to the server configuration – that is, us as the operator – therefore technically has access to the key as well. We don't do that, but encryption alone doesn't prevent it. That gap is exactly what layer 2 closes.
• GitHub deliberately stays readable. "Git for writers" depends on real, readable Markdown files living in your repository – there you can open them on any device, and there AI agents can work with them. Encrypted gibberish in the repo would be useless. So the encryption protects our database, not your GitHub account; for your repository, the access rights you set on GitHub yourself apply (a private repository stays private).
• Names and numbers remain visible. Document, project and folder names, timestamps, version counts and approximate text length are not encrypted – they're needed to make lists, sorting and the tree view work. So don't name a folder after the secret it contains.

Layer 2 – the high-privacy folder for everything that's genuinely private

For a diary, for confidential sources, for texts nobody should see, there is the high-privacy folder. The difference sounds small but is fundamental: here the encryption doesn't happen on the server but in your browser – before anything reaches our data centre. All that arrives at the server and in the database is gibberish for which no key exists there.

This is true end-to-end encryption. We cannot read this content, cannot search it, cannot restore it and cannot hand it over to anyone – not even from backups, because they contain the same unreadable data.

Here's how it works, in plain terms:

1. When you create the folder, your browser generates a random folder key. Every document in that folder is encrypted and decrypted with it.
2. You choose a passphrase. From it, the browser computes a second key that locks the folder key away as if in a safe. Only this locked safe is stored – the passphrase itself never leaves your browser and is never stored anywhere.
3. That computation is deliberately expensive (Argon2id, a method built specifically against password-guessing attacks). An attacker wanting to try millions of passphrases has to spend noticeable computing time and memory on every single attempt. For you, unlocking takes less than a second.
4. After creating the folder, bun.ink shows you a recovery key, exactly once. It is the folder key itself, in text form. It opens the folder even if you've forgotten the passphrase.
5. When you open a document, bun.ink asks for the passphrase (or the recovery key). After that you carry on as normal: editor, local search, word count. When you save, your browser encrypts again.
6. The unlocked key lives only in the working memory of that browser session – never in a cookie, never in local storage. Reloading or logging out locks the folder again automatically.

Incidentally, a wrong passphrase is reliably detected without any password having to be stored anywhere: the safe simply won't open with it, and the seal on the encrypted data raises the alarm.

Your responsibility – and it's a real one

End-to-end encryption means the protection rests with you, because the key rests with you. From which follows the most important sentence in this article:

If you lose both the passphrase and the recovery key, the contents of that folder are gone for good.

For good really does mean for good. There is no "reset password", no support route, no master key and no restoring from backup. We hold nothing that could help – and that, of course, is the whole point. A back door for us would be a back door for everyone else too.

So, before you write the first sentence into a folder like that:

• Passphrase into the password manager, right away and not "later". It isn't your bun.ink password, but an additional, separate passphrase.
• Save the recovery key while it's on screen – password manager, encrypted note, or printed out and kept somewhere you'd keep identity documents. It is shown only once.
• Two places, not one. Passphrase and recovery key are each other's backup. Store them so that a single lost device doesn't take both with it.
• Practise once. Reload the page and unlock the folder again – ideally once with the passphrase and once with the recovery key. That way you know both really work, while the folder is still empty.

You can change the passphrase later at any time (via the folder's context menu). The folder key stays the same, nothing needs re-encrypting – and your recovery key remains valid, because it belongs to the folder key, not to the passphrase.

What the high-privacy folder costs

Because the server cannot read this content, it also cannot do anything with it. That's not a missing feature but the logical consequence – still, you should know about it before creating one:

• No GitHub. Documents in high-privacy folders are never synced to GitHub. They appear in no push, no pull and no commit. Versioning through Git, branches and working with AI agents are therefore not available for these texts.
• Search only locally and only when unlocked. Project-wide search cannot search encrypted documents. If the folder is unlocked, bun.ink searches locally in your browser as well; if it's locked, those documents are skipped.
• No version preview and no comparison. Versions are saved – encrypted and safe – but preview and line-by-line comparison are currently disabled for these documents.
• Locked again after every reload. For these documents there is deliberately no local cache and no restoring of open tabs, so that no plain text is left behind on the device. So you enter the passphrase once per session.
• On a save conflict, reloading wins. If you've changed the same text in two windows in parallel, the server cannot compare the versions. Instead of a merge, the answer is: reload, unlock, carry on.
• The decision is final. A folder is either high-privacy or normal from the outset. Encryption cannot be switched on or off afterwards, and documents cannot be moved between the encrypted and the normal area – the key would no longer fit at the destination. If you want to switch, you copy the text by hand into a newly created folder. Subfolders are allowed and inherit the protection; a high-privacy folder inside a high-privacy folder is not.
• Names and sizes stay visible. As in layer 1, folder and document names, timestamps, version counts and word counts are not encrypted. Only the content is.
• Your device stays your job. Encryption in the browser doesn't help against a computer with malware or an unattended, unlocked laptop. While you're writing, the text is inevitably readable – on your screen.

What we recommend

For most projects – a book manuscript, articles, documentation – the normal folder is the right place. Your content is stored encrypted there, and you keep everything that makes bun.ink strong: versioning through GitHub, comparisons, branches, AI support.

Use the high-privacy folder deliberately and selectively, for what genuinely concerns nobody else: a diary, therapy notes, protected sources, deeply personal drafts. A single "Diary" folder alongside your normal projects is the healthy split – don't encrypt everything, encrypt the right thing.

And regardless of which folder you write in: your texts are stored in Europe, they're stored encrypted, they're backed up daily – and they remain yours. As Markdown, in an open format, exportable at any time. That's exactly why we built bun.ink.