How private share links work: your document is the link.
Share without an account, an upload, or a document database. Here is exactly what happens when you press Share — including the limits you should know about.
Most “share” buttons create a server-side record: your document is uploaded, assigned an ID, and retrieved later. Markdown Viewer takes a different route. It turns the document into part of the URL itself, so there is no document for our server to keep.
What happens when you press Share
The operation takes place inside your browser in four small, inspectable steps:
- Encode. The browser converts your Markdown text into UTF-8 bytes.
- Compress. The browser calls
pako.deflateto apply the lossless DEFLATE compression format, reducing the bytes so the link is shorter. Pako is a JavaScript compression library running on the page — it is not an external service and receives no document data. - Make it URL-safe. The compressed bytes become Base64URL text, replacing characters that have special meaning in URLs.
- Copy. The result is appended after
#share=and copied to your clipboard.
https://markdownviewer.org/#share=eJxLzs8rSc0r...Why the part after # matters
In a URL, everything after # is called the fragment. Browsers use fragments for in-page navigation and client-side state. Crucially, the fragment is not included in the HTTP request sent to the web server.
Our server receives a normal request for / and returns the editor. The editor then reads #share=… locally, reverses Base64URL, decompresses the DEFLATE data, and renders the recovered Markdown. There is no share ID to look up and no document row in a database.
Because we never receive or store the document, we cannot search for it, restore an expired copy, or read it from an admin dashboard.
What changes on shared pages
A fragment is invisible to the server, but it is still visible to the browser and to scripts running on that page. That is why Markdown Viewer therefore handles an incoming share link deliberately:
- analytics is disabled for that shared session;
- advertising may still load, but the document fragment is not included in HTTP requests;
- after decoding, the fragment is removed from the address bar and browser history entry;
- rendering remains local, and generated HTML is sanitized with DOMPurify.
The honest limit: a share link is not encryption
Compression and Base64URL make text compact and URL-safe; they do notmake it secret. Anyone who has the complete link can decode and read the document, just as anyone with a traditional cloud-document link may be able to open it.
Do not use share links for passwords, API keys, private health or financial data, or anything that requires access control. Use an encrypted channel or an access-controlled service for those cases.
The link may also remain in the sender’s clipboard, a messaging service, or the recipient’s local browser data. Browser extensions and device administrators operate outside the protection this website can provide.
Why we chose this design
URL sharing is intentionally modest. It works best for notes, examples, issue descriptions, and small technical documents. Links are capped at roughly 32,000 characters because browsers and messaging tools impose practical URL limits.
In exchange for that limit, you get a useful property: no account lifecycle, no cloud copy to forget, no public paste index, and no server-side document retention policy to trust. The architecture makes the privacy promise concrete.
The short version