I Deleted My Entire Backend and Put the Database in the URL Bar Instead

What if I told you a web app could store its entire database in the address bar, no server, no sign-up, no login, and still keep your data private?

That sounds like a hack. It's actually the whole architecture. Let me show you how I built it, and then I want to hear whether you think this is genius or a terrible idea. (Honestly, I go back and forth myself.)

The problem: why does sharing a calendar require an account?

You've felt this pain. You want to share a quick schedule with a client or a friend, and your only real options are:

• Google Calendar or Outlook → account sign-ins, clunky permissions, and handing your data to a tech giant.
• Build a custom app → a Node.js backend, a PostgreSQL database, JWT auth, and a monthly AWS bill… just to share a few dates.

Both felt absurd for something so simple. I wanted something instant, private, and frictionless. No sign-ups. No backend. No access controls. Just a link.

The "aha" moment: the URL is the database

Here's the realization that started it all: for lightweight data, the URL itself can act as the database.

So I built Hash Calendar, a fully client-side app where your events, timezones, and settings live entirely in the URL hash (everything after the #). The server stores nothing. Sharing a calendar is just copying your URL and pasting it into Slack, WhatsApp, or email. Open the link, and the calendar rebuilds itself on your machine exactly as the sender left it.

"But if the data is in the link, doesn't anyone with the link have my data?"

Great question, and that's where it gets interesting.

Making it private: encryption that never touches a server

Before any data hits the URL, it can be encrypted locally with a password. Intercept the link all you want without the password; it's noise. No server ever sees your plain-text data or your password. Ever.

How it actually works (the 5-step engine)

1. State serialization → Every event, timezone, and setting is captured as a JSON object.
2. Aggressive compression → URLs cap out around ~2,000 characters, so the JSON gets compressed down to a fraction of its size.
3. AES-GCM encryption (Web Crypto API) → If you lock the calendar, the browser encrypts the payload with a key derived from your password. 100% local.
4. Base64 encoding → The (optionally encrypted) payload is made URL-safe and appended to the hash. The URL updates live as you type.
5. Client-side hydration → Open the link, and the process runs in reverse: decode → decrypt → decompress → parse → render. Full calendar restored in milliseconds.

The takeaway

The result is a lightning-fast, privacy-first tool that costs basically nothing to host. Not every web app needs a database sometimes; the address bar is enough.

You can try it free at hashcalendar.online, and the core engine is fully open-source if you want to see exactly how the encryption and state management work.

---

Now I want your take 👇

• Would you actually ship a "database-in-the-URL" app in production, or is this a fun toy?
• What's the most unconventional place you've ever stored application state?
• Where would this architecture break down first?

Drop a comment