Your Whole Note in a URL: When the Address Bar Is the File

A note does not need an app to leave a trace. It can be the URL itself — every byte encoded into the address bar, pastable into a chat, an email, a bookmark. No install. No account. The artifact and the link are the same string. This post walks the three URL-as-file patterns and the honest failure modes.

The catalytic artifact this year was textarea.my, a 2,499-star repository whose README calls it "A minimalist text editor that lives entirely in your browser and stores everything in the URL hash."¹ Its creator, Anton Medvedev, posted it to Hacker News on 24 December 2025 under the headline "Show HN: Minimalist editor that lives in browser, stores everything in the URL" — story 46378554, with 468 points and 168 comments at access.²

The premise is straightforward — the editor is one HTML file; the document is the URL. There is no database underneath, no account, no round-trip to a server you do not control.

What "the URL is the file" actually means

The pattern names a discipline: instead of saving a note as a file or a database record, you encode it into a URL string and let the browser's address bar be the storage. The note travels wherever the link travels — clipboard, chat, email, a printed page. Three web-platform primitives make this work.

The first is the data: scheme. RFC 2397, written by Larry Masinter in August 1998, gives the grammar exactly:

dataurl := "data:" [ mediatype ] [ ";base64" ] "," data³

A note typed as data:text/plain,The%20whole%20note%20goes%20here. is a URL whose payload is the note. Paste it into a browser, and the address bar renders the text. There is no separate file.

The second is the URL fragment. RFC 3986, §3.5, by Tim Berners-Lee, Roy Fielding, and Larry Masinter, fixes the most useful property of the fragment for this purpose:

"the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme."⁴

The WHATWG URL Living Standard confirms the same definition in modern terms: "A URL's fragment is either null or an ASCII string that can be used for further processing on the resource the URL's other components identify."⁵ In plain language: what is after the # does not get sent to the origin server. The browser receives it; the server never sees it.

The third is the single self-contained HTML file — one document that bundles its editor and its text inside its own bytes. This is what textarea.my is: a 26-kilobyte HTML file with no external dependencies and no build step. Anton Medvedev's own one-line description of the project, in his Show HN post, was:

"Single HTML file, no deps, 111 loc"²

That "111 loc" line was true at submission time on 24 December 2025; the repository has since grown to a 937-line index.html as editor features and history-undo were added — a useful reminder that an artifact described in a Show HN post is a snapshot, not a final form.

Why the fragment is privacy-relevant, with limits

A URL's fragment is processed only by the user agent. RFC 3986 §3.5 is the canonical statement⁴; WHATWG's URL spec re-affirms it⁵. Practically, the contents of a note encoded after the # never reach the origin server. The host that ships the static editor page sees a request for that page; it does not see the document.

This is genuinely useful, and it is also frequently overstated. The fragment is private from the origin server. It is not private from anything else that touches the URL: the recipient has it, your clipboard has it, your browser history has it, a screenshare reveals it, and any extension reading window.location reads it.

A URL note is portable and host-independent — it is not a secret. Treat the fragment-hash pattern as "the server does not learn the document," not as "the document is encrypted."

There is also the implementation caveat that any specific page hosting the editor can still load third-party scripts that read the fragment client-side. The PATTERN is privacy-preserving in the protocol sense; a given page can still snoop on the string the browser hands it.

textarea.my itself uses the fragment-hash pattern correctly, and a viewer of the source can audit what scripts run alongside it. The lesson generalizes: the discipline is in the protocol, the trust is in the specific page.

How big can a URL actually be

The honest answer is two numbers from two layers, plus the standard that says "this only works for short values." The server-side floor is roughly 8,000 octets per RFC 7230 §3.1.1; the data: URL ceiling is per-browser and far higher (Chromium and Firefox at 512 MB, Safari at 2,048 MB, per MDN). Each pattern lives between those.

The server-side floor is IETF guidance. RFC 7230, §3.1.1, by Roy Fielding and Julian Reschke, recommends:

"It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets."⁶

When a server is unwilling to accept a longer request line, RFC 7231 §6.5.12 defines the response:

"The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) is longer than the server is willing to interpret."⁷

So the IETF-blessed minimum that the transport layer must support is 8,000 octets, and a server that refuses a longer URL is supposed to return 414. For a data: URL the constraint is different and much more generous, because the browser is the one processing the bytes. MDN's "Data URLs" reference page records the actual ceilings:

"Browsers are not required to support any particular maximum length of data. Chromium and Firefox limit data URLs to 512MB, and Safari (WebKit) limits them to 2048MB. Note that Firefox 97 increased the limit from 256KB to 32MB, and Firefox 136 increased it to 512MB."⁸

These two figures cover two patterns. A data: URL pasted into the address bar lives within the browser's per-scheme cap (currently 512 MB in Chromium and Firefox, 2,048 MB in Safari). A regular https://your-site/#<text> link goes through HTTP, where the safe floor is around 8 KB before any given server is allowed to reject it⁶⁷ — and where intermediate proxies, log lines, and "share this URL" widgets all begin to fray well before that.

The spec itself is honest about the trade-off. RFC 2397's §2 introduction tells you in one sentence: "The 'data:' URL scheme is only useful for short values."⁹ Short values is the right mental model. A whole novel is the wrong test.

For text that wants to be near the upper end of "short," compress it. The lz-string library by Pierre Yves ("Pieroxy"), originally released in 2013 and still maintained, was designed exactly for this:

"lz-string was designed to fulfill the need of storing large amounts of data in localStorage, specifically on mobile devices."¹⁰

Its compressToEncodedURIComponent helper does the two steps you want in one:

"compressToEncodedURIComponent produces ASCII strings representing the original string encoded in Base64 with a few tweaks to make these URI safe. Hence, you can send them to the server without thinking about URL encoding them."¹⁰

Compression ratios depend on the text's entropy — Markdown notes with repeated headings compress well; dense prose less so — so do not promise a specific percentage. Describe lz-string by capability, not by a number you cannot defend on every input.

The three patterns, with code

A practical "URL is the file" workflow comes in three shapes: a data: URI when the note is short enough to be its own link, a fragment-hash on a static editor page when the note runs a few kilobytes, and a self-contained HTML file when the artifact has to survive offline. Pick the one whose trade-offs match the artifact.

Pattern A — the data: URI

The entire note is the URL. Type the text after a media-type prefix, percent-encode the few characters that need escaping, and paste the result.

data:text/plain;charset=utf-8,The%20note%20goes%20here.

What you get: a string that is the note. Paste it into a browser's address bar, and the document opens. Save it as a bookmark, and the bookmark holds the document. The URL travels exactly as far as any other URL — and no further.

What to watch: the server-side floor of ~8,000 octets⁶⁷ does not apply to data: URLs (no server is contacted), but every other place a URL lives — clipboard fields, log lines, link previews — has its own quietly enforced length budget. Stay short. RFC 2397 itself was explicit about this from 1998: "The 'data:' URL scheme is only useful for short values."⁹

Pattern B — the fragment-hash with optional compression

The host page is static. The note lives after the #. Because RFC 3986 §3.5⁴ separates the fragment from the rest of the URI before dereference, the origin server never sees the document.

// write: encode the note into the URL
import LZString from "lz-string";
const note = document.querySelector("textarea").value;
location.hash = LZString.compressToEncodedURIComponent(note);

// read: pull the note back out on load
const payload = location.hash.slice(1);
const text = payload ? LZString.decompressFromEncodedURIComponent(payload) : "";
document.querySelector("textarea").value = text ?? "";

What you get: a shareable URL where the entire note is the fragment. The static host serves the editor page; the editor reads the fragment into the textarea on load. textarea.my is the canonical example of this shape — Anton Medvedev's framing was deliberate: he set out, in his own words, "to see how far I could go building a notes app using only what modern browsers already provide — no frameworks, no storage APIs, no build step."²

What to watch: the origin server does not see the document; everything else that touches the URL still does (clipboard, history, screenshare, extensions). And a specific implementation can still load third-party scripts on its host page that read location.hash client-side — the protocol-level guarantee does not extend to "no JavaScript on the editor page reads the fragment."

Pattern C — the self-contained HTML file

One .html file, no external dependencies. The "URL" in this case is file:///path/to/note.html on a local disk, or https://your.host/note.html if you want to publish it. The note's content can sit inline in the HTML as text, or be encoded into the URL hash exactly as in Pattern B.

What you get: an artifact that survives without a network, opens in any browser written this decade, and is a single email attachment or USB-stick file. It is the lower-friction cousin of the file-as-UI idea, where the file itself is the interface — here the file is also the link.

What to watch: a single-file HTML editor is bound by the same browser caps as a data: URL when its contents come back into the URL bar (per MDN⁸) and by your operating system's file-size limits otherwise. It is the most generous pattern; it is also the one that no longer fits in a single tweet.

Common mistakes

A discipline that uses the address bar as storage breaks in three predictable places: confusing "the server does not see it" with "nobody sees it," assuming all URL caps are the same number, and treating the URL artifact as a substitute for a folder of plain files. Name them in advance, and the failure modes stop being surprises.

Treating "the server does not see it" as "nobody sees it." The fragment is private from the origin server, per RFC 3986 §3.5⁴. It is not private from the recipient, the clipboard, the browser history, a shoulder-surfer, a screenshare, or a browser extension. If the document is sensitive, encrypt it inside the fragment before encoding — and then be honest that the protection comes from the cryptography, not from the URL shape.

Assuming all URL caps are the same. The HTTP request-line floor is ~8,000 octets (RFC 7230 §3.1.1⁶); servers may legitimately return 414 above that (RFC 7231 §6.5.12⁷). The data: URL cap is per-browser and very high — Chromium and Firefox at 512 MB, Safari at 2,048 MB per MDN⁸. A link that opens in your browser may not survive a copy through a Slack DM, a Google Doc paste, or an intranet proxy — test the round-trip on the platforms you actually share through.

Treating the URL as a vault. A URL note is one note. It does not link to siblings, does not search across a collection, does not survive a 414 from a strict server, and does not replace the directory of plain text files that grows into a body of work. Use it as the bottom rung of the durability ladder — the artifact you can hand to someone with nothing installed — and keep the rest of the practice in actual files.

Where this fits in the broader "the file IS the artifact" discipline

The "URL is the file" pattern is one case of a broader file-over-app philosophy: artifacts that last are ones you can hand to someone in a format they can read without your tools. A URL is the smallest possible file in that sense — plain text in a container the whole web opens. Steph Ango put it in one sentence:

"Apps are ephemeral, but your files have a chance to last."¹¹

His longer formulation makes the trade explicit:

"File over app is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. Use tools that give you this freedom."¹¹

A URL is the smallest possible file. It is not a folder, not a vault, not a graph. It is the artifact in its most portable shape — the note you can hand to a stranger by reading it aloud. That is a useful slot in a writing practice, and it sits naturally next to the file-as-UI idea¹² and the "let your notes be the file you own" thesis that runs through the rest of this blog.

Adjacent demand for this shape keeps showing up. The single-file-tiny-page idea behind safe-now.live — a self-contained emergency information page measured at 9,886 bytes by direct fetch¹³ — is the same instinct: the artifact has to fit in a place the network cannot disappear.

The "I just wanted a plain text website" essay from the Helene aftermath made the same point in different words. The URL-is-the-file pattern is part of that family; the connecting tissue is portable enough to survive.

A note worth keeping for a year is a file. A note worth handing to one person, once, may be a URL. The web platform already has the primitives for both, written down by the people who built the protocols. The discipline is to use them where each fits.

Frequently asked questions

These are the questions a thoughtful reader asks first about URL-as-file notes — how the patterns compare, where the byte caps actually bind, what kind of privacy the URL fragment really gives you, and which workflows the discipline does and does not replace. Each answer is grounded in the IETF, WHATWG, or vendor primary cited above.

How do I share a note without an app? Encode the text into a URL and share the URL. Three patterns exist: data:text/plain;charset=utf-8,<your text> for the smallest case, a fragment-hash on a static editor page (https://your-site/#<compressed>) for a few kilobytes, and a self-contained HTML file you email or attach for anything larger. The IETF floor for the HTTP variants is ~8,000 octets per RFC 7230 §3.1.1⁶; the data: ceilings are far higher per MDN — 512 MB in Chromium and Firefox, 2,048 MB in Safari⁸.

What is a data: URL? A URL that carries its own payload, defined by RFC 2397 in 1998 with the grammar dataurl := "data:" [ mediatype ] [ ";base64" ] "," data³. The payload is the document — no server, no file, no install. The spec is honest about scope on the same page: "The 'data:' URL scheme is only useful for short values."⁹

Can a URL be private if it never goes to the server? The origin server never sees the URL fragment, because RFC 3986 §3.5 separates the fragment before dereference and processes it solely in the user agent⁴. WHATWG's URL Living Standard repeats the same definition⁵. This is a real property, and it is not the same as private. The recipient, the clipboard, the browser history, a screenshare, and any script on the host page can still read the URL. A URL note is portable and host-independent — it is not a secret.

How big can a URL be? For HTTP URLs, RFC 7230 §3.1.1 recommends senders and recipients support "at a minimum, request-line lengths of 8000 octets,"⁶ and RFC 7231 §6.5.12 defines the 414 URI Too Long response when a server refuses a longer request⁷. For data: URLs the limit is per-browser and far higher — Chromium and Firefox at 512 MB, Safari at 2,048 MB, per MDN's reference page⁸. Test the round-trip on the channels you actually share through; clipboards, link previews, and intranet proxies impose their own informal caps long before either limit.

How do I put a whole markdown note in a link? Compress and URI-encode the text in one step using a library designed for it. lz-string's compressToEncodedURIComponent "produces ASCII strings representing the original string encoded in Base64 with a few tweaks to make these URI safe"¹⁰ — so the output is safe to drop into location.hash. Then on load, read location.hash.slice(1) and pass it through decompressFromEncodedURIComponent. The compression ratio depends on the text; do not promise a percentage you cannot defend on every input.

Is textarea.my the standard? No. It is the catalytic example — Anton Medvedev's Show HN of 24 December 2025 (468 points, 168 comments)² and the 2,499-star repository whose README says it "lives entirely in your browser and stores everything in the URL hash."¹ The standards are the IETF and WHATWG documents above. textarea.my is the artifact that made many people see the pattern; the pattern itself is older than the artifact, and any specific page hosting it can still load third-party JavaScript that touches the fragment alongside the editor. The protocol property is in the spec; the trust is in the specific page.

What is the most portable way to send a note? Decide which property matters more: ultra-short and link-shaped, or arbitrary-length and file-shaped. For one paragraph that has to fit in a chat message, use the data: URI³ or a fragment-hash on a known editor page. For anything larger, attach a self-contained HTML or plain-text file. The URL pattern is the smallest possible artifact in the file-over-app sense¹¹; a real file is the next rung up, and a folder of files is the rung after that.

Does the URL pattern replace my note app? No, and it should not. A URL note is one note. It does not link to other notes, does not search across a collection, may exceed a strict server's request-line tolerance and return 414⁷, and exceeds a data: URL browser cap above the per-vendor ceilings⁸. Use it for the artifact you can hand to a stranger with nothing installed. Keep your daily writing in plain files on your own device, where searching, linking, and growing a body of work all stay possible.

A URL is the smallest portable artifact the web platform gives you, written down by the people who wrote the web. Notes worth keeping live in plain files you own on your own device — mnmnote.com is where that practice runs, with the file as the artifact and the address bar as one of the places it can travel.