Marked Share: Rendered Markdown You Can Hand Off in 30 Seconds
Reviewed by the FreeOnline.fyi team · Updated 2026-09-14
What Marked Share actually does
We built Marked Share for one narrow, recurring annoyance: you've drafted something in Markdown — a spec, a release note, meeting notes, a README — and the person who needs it reads email, not a code host. The workflow is a split pane. Markdown goes in on the left, a sanitized rendered preview appears on the right, and a sticky export bar stays within reach across the bottom so the copy button never scrolls away from what you're editing.
The preview isn't re-rendered on every keystroke; it settles roughly 150ms after you stop typing, which is long enough to keep the pane calm while you're mid-sentence. Nothing is uploaded — the conversion happens in the page, so pasting an internal spec doesn't deposit it on someone else's server before you've decided to share it.
The output side is deliberately small: a share link, rich text on the clipboard, an HTML snippet, or a downloadable .html file. No accounts, no document library, no version history. We treat it as a hand-off utility, not a publishing platform, and that constraint is what makes it fast.
Where the share link actually lives
The link option is the one people ask about first, because it looks like magic: a URL that renders your document for someone with no account and no install. The content is encoded into the URL fragment — the part after the #. Browsers don't send fragments in the HTTP request, so the document text never travels to a server on the way to your recipient; it's decoded locally when their browser opens the link.
That design has an honest cost: the URL grows with the document. We cap the Markdown source at 20,000 characters overall, and past roughly 8,000 characters we disable link export while leaving the .html download available. Long links get wrapped, truncated, or auto-linkified badly by chat clients and email editors — we'd rather hand you a file than a link that breaks at character 6,000.
If you're sharing something long, download the .html and attach it, or switch to the HTML snippet. And as with any URL you paste into a third-party chat app, treat the link as public once it's sent — the fragment is right there in the message.
Choosing between link, rich text, HTML snippet and plain text
Each export exists for a different destination, and picking wrong is the most common way to lose formatting. **Share link** is for a non-technical recipient who just needs to read it — it opens rendered in any browser with no account. **Rich text** puts HTML-flavored content on the clipboard so headings, bold, lists and tables survive a paste into Gmail, Google Docs, Word, Notion or Slack. Paste normally; if an editor offers a "paste as plain text" variant, don't pick it.
**HTML snippet** is for when the Markdown is heading into a CMS, a static site, or a help-center article. The styling toggle applies here and to the share view only: leave it on for a self-contained block you can drop anywhere, or turn it off to inherit the host page's own stylesheet. **Plain text** strips the markup down to readable characters — the right choice for a terminal, a ticket comment, or a plain-text email digest where asterisks and pipes are just noise.
The generated link's character count is shown next to the primary button, and the raw output is available in a collapsible code block. Worth a glance before you commit: it's the exact string being copied, so you can spot a stray unclosed fence or a heading level you didn't intend. If you're producing a formatted document for a specific audience rather than a raw file, a purpose-built résumé builder handles pagination and typography in ways a Markdown-to-HTML hop won't.
Titles, tables of contents, and the edge cases
The document title field is trimmed and capped at 120 characters, and it feeds both the page title and the header in the shared view — so "Q3 migration notes" beats "untitled-final-v2". The table of contents toggle is off by default. When you switch it on, it auto-numbers h2 and h3 headings, and it stays hidden if the document has fewer than two headings, because a one-item contents list is just clutter.
Two edge cases catch people. If your document uses only h1 headings, there's nothing for the contents list to number. If your headings are all h3 with no h2 above them, the numbering will look inconsistent against the visual hierarchy — nudge the top level to h2 and let the deeper levels nest.
Everything rendered is sanitized. That means inline HTML you might lean on in a docs platform — a script tag, an onclick attribute, an embedded iframe — gets stripped rather than executed. It's the reason we can render someone else's link safely in your browser. The CommonMark specification is the reference we check against when a construct behaves unexpectedly, and it's worth a look if you write Markdown often enough to care about the difference between a hard break and a paragraph break.
The Markdown mistakes we see most in real pastes
Tables need the separator row under the header. Two pipes are not a table; `| a | b |` followed by `| --- | --- |` is. Skip the dashes and the whole block renders as a paragraph of pipe characters, which is exactly the failure mode people are trying to avoid by using a renderer in the first place.
Fenced code blocks need a blank line before the opening fence. Paste a fence directly after a paragraph and some parsers fold it into the paragraph text. Nested lists are the other repeat offender — pick two or four spaces for indentation and use it consistently, because mixing the two produces sublists that jump levels unpredictably.
Images are worth calling out honestly. Nothing is uploaded, so a local path like `./diagram.png` will not resolve for your recipient. Only images already reachable at a public URL have any chance of rendering, and even then the host may block hotlinking. If the picture matters, attach it separately or host it somewhere you control. For anything security-sensitive in how HTML is escaped, the OWASP XSS prevention guidance explains the sanitizing rules that tools like this apply.
How it compares, and when to use something else
The obvious alternatives each cost you something. Pasting raw Markdown into chat or email shows the asterisks, which is fine for engineers and confusing for everyone else. A code host or gist renders beautifully but usually wants an account from the reader, and it's public more often than people expect. A local editor preview never leaves your machine — great for reading, useless for handing off. A full docs platform is the right answer when the document has a life: multiple authors, reviews, a URL you'll maintain.
Marked Share sits in the gap between those: one document, one recipient, thirty seconds. Its limits follow from that. There's no persistence beyond the link itself, no collaboration, no history, and an over-long document has to travel as a downloaded file rather than a URL. Sanitizing also means you can't embed arbitrary interactive HTML.
If you want the full set — converters, generators, formatters — the rest of FreeOnline.fyi runs on the same no-account, nothing-uploaded model. As with any tool that touches text you care about, spot-check the preview and, for anything that matters, keep the original Markdown as your source of truth.