ilolink for developers

Share docs without a repo or deploy

You have a doc, not a site. A README for a script, an API reference, a migration guide, release notes — the kind of thing that doesn't warrant a static-site generator, a PR, and a deploy just to hand someone a link. Paste the Markdown or HTML into the composer at ilolink.com, or drop a file, and you get ilolink.com/<slug> — a normal web page in a clean reading shell. Code blocks keep their formatting and tables render as tables. No generator, no build step, no branch.

• Markdown — headings, lists, fenced code blocks, and tables render in a readable layout.
• HTML — paste it directly; inline CSS, Google Fonts, and https/data images work.
• Files — drop one, up to 15 MB per doc.

One honest caveat: by default, if your HTML doc carries interactive JavaScript, it is frozen to static on the way in. Scripts are dropped and don't run — the layout and CSS render, so an interactive widget shows as a visual preview, not a working control. For docs that's rarely a problem; prose, code, and tables are all static anyway. If you do need the scripts to run, mark the doc trusted at publish time and it's served as-is inside a sandboxed frame on the isolated origin.

See if the team read it

Once the link is out, ilolink shows how the page was actually read — cookieless, from a rotating visitor hash, with no fingerprint and no personal profile:

• Scroll funnel bucketed at 0 / 25 / 50 / 75 / 100%, so you see how far people got — whether they stopped at the overview or read through to the breaking-changes section.
• Time on page — a skim reads differently from someone who actually worked through the setup steps.

These are aggregate and approximate by design — you learn how the doc was read, not which named teammate read it. There's more on the read side: total and approximate unique views, referrers, countries, device class, 30-day daily views, plus click and scroll heatmaps and reader reactions. See analytics, heatmaps, and feedback for the full picture, or open your documents after you publish one.

Get feedback in place

Reviewers can leave anchored comments pinned to the exact line or section — a threaded note on the specific code block or paragraph, not a separate thread where nobody can tell what "the third bullet" refers to. Reviewers don't need an account to comment, so feedback doesn't stall behind a sign-up.

Keep internal docs unlisted or password-protected

Not every doc is public. Pick the visibility that fits:

• Public or unlisted for docs you want to circulate freely.
• Password for an internal API doc or spec you don't want indexed or forwarded.
• Expiring if you want a link to lapse — expiry is opt-in, never forced on you.

The link redirects to an isolated render origin under a strict content security policy, and pasted HTML is sanitized on the way in, so a shared doc is safe to hand around. Docs are immutable — revise the README and you publish a new link; delete from the dashboard on any device you sign in on.