htmlsharechecking
/ uses · personal · a page that keeps what you type, locally

somewhere plain to write it down.

journalling apps ask you to trust them with the most personal text you will ever type, in exchange for a sync feature and a subscription.

the alternative most people land on is a text file, which works, and a notes app, which syncs to a company either way.

a page whose storage is your own browser is a third option: nothing uploaded, nothing to sign into, a box to write in, and whatever daily prompt you find useful.

what you make
a journal that never uploads anything
where the data lives
this browser, this device, and nowhere else
the catch
clearing site data deletes it. export regularly

private because it never leaves.

01 / what it is

the privacy story here is unusually simple: the page is html we serve, and what you type into it is stored by your browser. it is never sent to us, we have no account attached to it, and there is nothing in our systems to hand over or lose. that is stronger than most journalling products can honestly claim.

the same sentence is also the risk. nothing is backed up. a cleared cache, a wiped phone or a browser reset takes it, and no support request will bring it back. that is why the export button gets a paragraph in the prompt rather than a mention, and why this page tells you to use it.

  • a writing box that saves as you type
  • the prompts you actually want, or none at all
  • yesterday and the last week, readable underneath
  • an index by month, once there is enough to index
  • a prominent export, because it is the only backup there is
  • import, so a new device can pick up where the old one left off
what it stores
your entries, in this browser’s local storage
who can read it
anyone with access to that browser profile. not us, and not anyone with the url
backups
the export file you make. there are no others
encryption
none. do not treat it as a secure store — treat it as a notebook on your desk

see one in action.

02 / example
htmlshare.net/p/…
screen capture · silent loop
video coming soon

a writing page with one prompt, yesterday collapsed underneath, and a month index

the live example is still being built — the prompt below is the one it was made with.

copy this, then make it yours.

03 / starting prompt

a starting point, not a template — the point of an agent is that the result is yours. change the sections to match what you want, and remove anything you don’t need.

starting prompt · paste into your ai
Build me a private journal as a single web page. Everything stays in my browser.

Ask me first:
- Whether I want a prompt to write against each day, and if so what kind — or nothing at all.
- Whether entries are one per day or as many as I like.
- Whether I want to tag entries or note a mood, or keep it to plain text.
- Roughly how long my entries tend to be, so the writing area is the right size.

Do not invent journalling prompts of the inspirational-quote kind unless I ask for them. Do not invent entries.

WHAT IT DOES

- Opens on today, with the cursor in the writing area. Writing should be the first thing possible, before any navigation.
- Saves as I type, continuously, without a save button. Losing a paragraph because the tab closed is the one unacceptable failure.
- Shows today's prompt if I asked for prompts, in a way I can ignore.
- Yesterday and the last several days readable below, collapsed, in date order.
- An index by month once there are enough entries, and a plain text search across everything.
- Editing a past entry is possible but should take a deliberate action, not a stray tap.

BACKUP — TREAT THIS AS A FEATURE, NOT A FOOTNOTE

- A prominent export that downloads or copies everything as JSON, and also offers plain text or markdown.
- An import that restores from that file.
- On the page, in normal-sized text: entries are stored in this browser only, there is no copy anywhere else, and clearing site data will delete them permanently. Suggest exporting periodically.

DESIGN

- Calm. Generous line height, comfortable measure, nothing flashing while I write.
- Works on a phone and on a laptop; most people write on one and read back on the other.
- Do not add word-count pressure, streaks, or "you have not written in 3 days" messages.

BE HONEST ON THE PAGE

- Say plainly: stored in this browser, not encrypted, not synced, not sent anywhere.
- Do not describe the journal as secure or private beyond what that sentence supports — anyone using this browser profile can read it.

STORING THE DATA

- Save everything to localStorage in the browser, automatically, as I go. No
  accounts, no login, no server call.
- On the page, say plainly that data lives in this browser only and does not
  sync to other devices. Do not bury it.
- Give me an "export" button that copies or downloads everything as JSON, and an
  "import" that reads the same JSON back. That is the only way my data can move
  between devices, so it is not optional.
- Never lose what I have already entered. If the stored data is from an older
  version of the page, read what you can rather than throwing it away.

DELIVERY

- Produce one self-contained HTML file. Inline the CSS and JavaScript.
- No build step, no server, no framework, no package install, no external
  requests at runtime.
- Mobile-first and responsive; it has to be usable one-handed on a phone and
  still look right on a laptop.
- Accessible: semantic HTML, real contrast, visible keyboard focus, labelled
  controls, touch targets big enough to hit, and respect reduced-motion.
- Use placeholders where information is missing. Do not invent facts, numbers,
  names, dates, prices, or results I have not given you.
- Before you call it finished, use it yourself: enter real-looking data, reload
  the page, and confirm nothing is lost or mangled.

PUBLISHING

Publish the finished page to HTMLShare and give me the link.

Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.

1. An HTMLShare integration or connector, if you have one configured.
   The page is permanent and owned by my account. Report the url and the
   siteId. There is no claimUrl or manageToken on this path — do not go
   looking for one, and do not switch paths in order to produce one.

2. Otherwise, publish anonymously over REST. No account, key, or signup is
   needed:

    POST https://api.htmlshare.net/v1/publish
    content-type: application/json

    {"html": "<!doctype html> ... "}

   The reference is https://htmlshare.net/docs and, for the full schema,
   https://api.htmlshare.net/openapi.json

   Report these from the response, in your reply and never inside the page:
     url          the public page
     claimUrl     a private link that is mine alone. opening it is how I keep
                  the page past its 24-hour expiry, or set an email reminder
                  before it goes. it carries the manage token, so it must
                  never appear in the published HTML or anywhere a visitor
                  could see it.
     manageToken  the only thing that can edit or delete this page later. it is
                  returned once and never again, so tell me what it is.

Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.

If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.

RECIPE MARKER

Include this tag in the <head>, exactly as written:

    <meta name="htmlshare-recipe" content="personal-journal">

It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.
works as-is inclaudechatgptcodexcursorgrok
adapting it
export on a schedule you will keep.once a month, into a folder you back up. local-only storage is a genuine privacy win and a genuine single point of failure, and the second half is the one people find out about the hard way.
ask for saving-as-you-type explicitly.a save button is the default an agent will reach for and the wrong answer for writing. it is worth being blunt about in the first message.
do not put anything in the html itself.your entries are local, but the page is public to anyone with the url. no name in the title, no "journal of", nothing identifying baked into the file.

give it a url.

04 / publishing it

how you publish depends on how you’re working.

with an integration
if your assistant already has htmlshare connected — mcp or another supported integration — just ask it to publish the finished page and hand back the url. the page belongs to your account and is permanent. when you want a change, ask for an update to that same page rather than a new one.
with no integration
the prompt tells the assistant to post the html to the rest api instead, which needs no account and no key. it comes back with a live url you can open immediately, a private claim link, and a manage token. the claim link is how the page stops being temporary — keep it.
by hand
nothing stops you doing it yourself: have the assistant give you the html file and drop it on the htmlshare home page. same url, same page, one more step.
what matters here
be careful with the claim link here for the ordinary reason — it is the credential for the page — but note the entries are not on the page at all. what an account buys you is that the journal still opens next year.

the page can expire; your writing is in the browser either way.

05 / keeping it around
anonymous
24h

the page stops serving after 24 hours, with a 7-day recovery window. your entries are not deleted with it — they are in your browser — but you would have no page to read them in, which amounts to the same thing.

keep it around
your entries live in the browser, but the page is the only thing that can read them. lose the page and you have json you cannot open.
custom url
an address you can type without searching your history for it, which matters for a page you would rather not have in a shared autocomplete.
stable updates
change the prompts or the layout without moving the page your entries are keyed to.

questions.

06 / questions
can you read my journal?

no. we store the html file you published; your entries are written into your own browser’s storage and never sent to us. there is no account holding them and nothing in our database to disclose.

what if someone opens the url?

they get an empty journal. the entries are not in the page — they are in your browser — so a visitor sees the writing interface with nothing in it. anyone using your device and browser profile, though, can read everything.

is it encrypted?

no, and the page says so. it is a notebook on your desk, not a safe. if you need encryption at rest, this is the wrong tool and pretending otherwise would be worse than saying it plainly.

how do i not lose years of writing?

export, regularly, and keep the file somewhere you actually back up. there is no other copy — no server-side backup, no recovery, no support request that can help. that is the price of nothing ever being uploaded.