Journlet

Privacy

Journlet is built so that the people running it cannot read your journal. This page explains what that means in practice, and is written to be checkable against how the app actually works rather than to sound reassuring.

The short version

What is stored, and where

On your device: the whole journal, held in the browser's own database for this site and readable only by the app. This is the primary copy. If you never sign in, it is the only copy, and none of your writing exists anywhere else.

Also on your device, in ordinary browser storage: your theme choice, which page you were last on, an unsent feedback draft if you have started one, and similar small preferences. If you link a device by scanning its QR code, your journal key is held there while you sign in. Thirty minutes after the scan it stops being accepted, and it is erased at that point if the app is still open or you come back to it. If you close the browser before then and never open the app again, it stays in that storage until you do, so finish the linking or open the app once more if you would rather it were gone.

On the server, only if you enable sync: your email address, and a sequence of encrypted updates representing your journal. Alongside those the server keeps the bookkeeping it needs to hand your own rows back to you — an account identifier, when the account first synced, the time each update arrived, a label saying which notebook it belongs to, and one encrypted copy of your journal's data key. Supabase separately records authentication activity, which can include the IP address and browser used to sign in.

Since 6 August 2026 it also keeps a running total of how much space your journal takes on the server, the limit that total counts against, and the time the total last changed. The first two are there so that one account cannot fill the database and stop everyone else writing; the app shows them to you on the Menu. The third is worth naming plainly rather than calling it bookkeeping: because the total changes whenever you write, its timestamp says roughly when you last wrote something. It says nothing about what.

The updates are encrypted with AES-GCM using a data key generated on your device. That data key is itself encrypted with a second key, shown to you as your journal key, and the encrypted result is what the server stores. To be precise about the distinction, because it is the one that matters: your journal key never leaves your devices, and without it the stored copy of the data key is unreadable. So the updates are unreadable to the operator, to the hosting provider, and to anyone who obtains a copy of the database — but the wrapped data key is on the server, and this page would be wrong to claim otherwise.

One more distinction in the same spirit, because it is the limit of what any web app can honestly promise. Journlet is delivered to you as a web page, so the encryption described here is performed by code the operator publishes. Nobody can decrypt your journal from the data the server holds. What you are also trusting, every time the app updates, is that the code served to you is the code described on this page. There is no app store review and no signed build standing between the two. That trust is unavoidable for software delivered this way, and it is better stated plainly than left for you to work out.

Sync is provided by Supabase, acting as authentication and encrypted storage only. No application code of Journlet's runs there, and nothing that runs there is capable of reading journal content. What does run is database rules that check each request is asking for its own rows, and nothing else. Where all of this physically sits is covered under Where your data goes.

What the operator can see

Being precise about the limits matters more than the reassurance. With sync enabled, the operator can see that an account exists, the email address attached to it, when it last synced, and roughly how much encrypted data it holds. That last point means the approximate size of your journal is visible, though not a word of its content.

The operator cannot see your entries, your collections, your reminder times, the pages you thread together or anything derived from them. Search and indexing happen on your device, which is a deliberate trade-off: server-side search would require the server to read your journal.

Accounts and email

Signing in uses a one-time code sent to your email address. There are no passwords. Your email address is used to authenticate you and to send those codes, and for nothing else. You will not receive marketing from Journlet.

Notifications

Reminders fire locally on your device. Reminder times are part of your encrypted journal and never reach the server in readable form. If server-sent notifications are ever added, this page will be updated before that happens, and the change will be described plainly.

This website

This page and the rest of journlet.com are static files. There is no JavaScript, there are no cookies, no analytics and no third-party requests of any kind. The fonts are served from this domain rather than from Google, so visiting this site does not disclose your visit to anyone else.

The site is hosted on GitHub Pages, which processes visitors' IP addresses in the course of serving requests, as any web server must. The operator does not receive, retain or analyse that data.

The app

The app carries no analytics and no tracking either, and its fonts are served from Journlet rather than from Google, so opening it discloses nothing to a third party.

The app talks to exactly one other place: the Supabase project that holds your ciphertext. Asking for a sign-in code sends your email address there before you have an account, which is unavoidable: it is how the code reaches you. Until you do that, nothing you write leaves the device.

Feedback and support

Writing to hello@journlet.com is ordinary email, not part of the app. The app never sends it for you: the Send feedback screen composes a message and hands it to Gmail's composer, to a mail app on the device, or to your clipboard, whichever you choose, and there you can read it, change it, or abandon it. Nothing reaches the operator until you send it yourself.

What arrives is what you wrote, your email address, because that is how email works, and the report block if you chose to leave it in. That block holds the build you are running, whether the app is installed or in a browser tab, how your browser describes itself, the size of the window, the sync state, the last error the server gave, and a count and a size for your journal. It holds no entries and no page names, and it is shown to you in full, editable, before it goes anywhere.

An unsent draft is kept in your browser's own storage on that device, so it survives being offline or closing the app. It is not added to your journal and never reaches the server.

Correspondence is kept in the mailbox for as long as it takes to deal with what you raised, and where it records a fault still outstanding, until that is fixed. Anything older than twelve months is deleted. Ask and yours goes sooner. It is never used for marketing, and there is none to use it for.

Your data, and getting rid of it

Export: the app exports your entire journal as Markdown, generated on your device. There is no lock-in and no need to ask anyone for a copy.

Deletion, on your device: choosing to sign out wipes the local journal and the keys from that device immediately. A session simply expiring does not — the journal stays on the device and the app tells you it has stopped syncing, because losing your writing to a timeout would be indefensible.

Deletion, on the server: by asking, and not from a button in the app. Email privacy@journlet.com from the address the account is registered to. We reply within three working days, write to that same address to say deletion has been requested and how to stop it, and wait seven days before removing anything. Then your account goes, along with every encrypted update stored against it, the stored copy of your data key and your email address. It cannot be undone: there is no backup from which any of it could be restored for you. Supabase's own authentication logs are the one thing not removed by that; ask and they will be cleared too.

It works by asking rather than by a button because a button could not tell you apart from somebody who had reached your email. Signing in needs only your email address, so for a while the app could destroy the server copy on that alone, and there is nothing behind it to restore from. A check was tried and it did not hold, so the action was removed instead: there is now no way for anyone, including us on your behalf, to delete an account without that notice and that wait. The delay is the part that protects you, because it gives a request you did not make somewhere to be stopped.

Two things you can still do yourself, immediately, without asking anyone. Signing out removes the journal and its keys from that device straight away. And Export, from the menu, gives you a readable copy to keep first. If what you want is this off my phone now, those are the two, and neither needs us.

Deleting the account does not reach devices that are still signed in elsewhere: each holds its own copy of the journal until you sign out or remove the app there. Nothing can erase a device remotely, and no honest design could claim otherwise.

Retention: nothing is deleted automatically. If you stop using Journlet, your encrypted updates and your email address stay on the server until you delete the account. This is a deliberate choice — a journal is the sort of thing people return to after long gaps, and silently destroying it after a period of inactivity would be worse than keeping ciphertext nobody can read. Supabase pauses unused free projects after a period of inactivity, which suspends access but is not deletion and should not be mistaken for it.

Recovery: your journal key is the only way back into an encrypted journal. If you lose every device and the key, the data cannot be recovered by anyone, including the operator. This is a consequence of the design rather than an oversight, and the app says so at the point where it matters.

Why this is lawful

Under UK GDPR, processing your email address and storing your encrypted journal is done to perform the service you asked for: the lawful basis is performance of a contract, Article 6(1)(b). No processing here relies on consent, and none of it involves analytics, marketing or profiling.

Correspondence is the one exception, and it is named here rather than folded into the line above. If you email feedback or a bug report, replying to you and acting on it rests on legitimate interests, Article 6(1)(f): running and repairing the app, which is in your interest as much as the operator's, and involves no more of your data than the message you chose to send. You are not obliged to send one, and nothing in the app asks unprompted.

If you never sign in, none of your writing is processed by anyone: it stays on your device. Serving you the site and the app still involves your IP address reaching GitHub Pages, as described above — that much is true of visiting any website and happens whether or not you have an account.

Where your data goes

Your ciphertext and email address are held in Supabase's London region, on servers in the United Kingdom. Supabase Inc is a United States company, so administrative access to the service it operates may involve transfers outside the UK; such transfers rely on the standard contractual clauses in Supabase's data processing agreement.

Two other processors are involved. GitHub Pages, operated by Microsoft, serves this website and the app, and processes visitors' IP addresses in the United States in the course of doing so. Sign-in emails are delivered through Supabase's email provider, which handles your email address and the code in order to deliver the message.

Email you send to a journlet.com address is held by the provider of that mailbox, in the same way any email you send is held by the recipient's mail provider. Feedback is voluntary and no account is needed to send it, so nothing about it is conditional on having one.

Your rights

Under UK data protection law you have the right to be informed, to access your personal data, to have it corrected, to have it erased, to receive a copy in a portable form, and to restrict or object to how it is processed. You also have the right to complain to the Information Commissioner's Office. The right to withdraw consent does not arise here, because none of this processing rests on consent in the first place.

In Journlet's case the personal data held is limited to your email address and the bookkeeping described above, since the journal content is not readable by the operator. Access and portability are available to you directly: export from the app's menu, any time, with nothing to ask for. Erasure of the copy on your own device is too, by signing out. Erasure of what the server holds is by request, for the reason given under Your data, and getting rid of it, and it goes to privacy@journlet.com along with anything else you would rather have done for you. Asking is not a lesser route: it is the one that comes with notice and a delay, so a request you did not make can be stopped.

Who is responsible

Journlet is an independent project rather than a company. The data controller is Gary Rutland, contactable at privacy@journlet.com, which is the right address for privacy enquiries, deletion requests and anything else covered by this page.

Gary Rutland
76 Titchener Way
Hook
Hampshire
RG27 9RT

Changes

Material changes to this page will be described rather than quietly applied. The page history is public in the site's source repository.

Last updated 26 August 2026.