Why HTML collaboration is still unsolved
LLMs have made generating polished HTML documents trivial. A well-prompted Claude or ChatGPT session produces reports, dashboards, and presentations that would have taken a designer hours. The generation problem is solved. The collaboration problem is not.
The tools that handle collaboration well (Google Docs, Notion, Figma) work on their own formats. They do not render arbitrary HTML. The tools that render HTML (browsers, static hosts) have no concept of comments or review states. So teams building in HTML end up emailing screenshots, pasting feedback into Slack threads with no spatial context, or converting the HTML to a PDF that kills all the interactivity.
The specific problem with email feedback on HTML
Email feedback on a document has a structural flaw: it is disconnected from the document. A reviewer writes "the figure in the second section looks wrong" and two days later you are staring at the document trying to figure out which figure, which section, which version they were looking at.
This is not a people problem. It is a tooling problem. When feedback is anchored to a specific passage in the document, the context is preserved. The reviewer selects the text they mean, types their comment, and you see exactly what they are referring to. That is the difference between actionable feedback and feedback you have to spend time decoding.
How to set up HTML collaboration with LiveSend
- Upload the HTML document to LiveSend. Paste the code or drag the file. You get a permanent URL immediately.
- Open the document in your dashboard and go to the Comments tab.
- Add the email domain of your reviewers under Authorized domains. For example:
agency.comorclient.com. Anyone whose email matches that domain will get access to the comment interface when they open the link. - Send the URL to your reviewers. They open the link, enter their email, and see the document. A comment button appears in the bottom right corner.
- Reviewers select any text in the document and type a comment. They can add multiple comments before submitting. Each comment is anchored to the selected text so the context is always visible.
- You receive an email notification when comments are posted. Reply or resolve from the Comments tab in your dashboard. Reviewers are notified when their comments are resolved.
What reviewers see
The reviewer experience is intentionally minimal. They open a URL, enter their email, and see the document exactly as you built it. No account creation, no browser extension, no PDF viewer. A small comment button appears in the corner. When they click it, they enter comment mode: selecting any text triggers a form where they can type their comment. They can batch multiple comments before submitting so they can annotate the whole document in one pass and send everything at once.
Reviewers can also see comments left by other authorized reviewers and reply to threads. This is useful when you have two or three stakeholders reviewing the same document: they can see each other's concerns without separate email threads.
Comparing your options for HTML review
Several approaches exist, each with real trade-offs:
- Email feedback. Zero setup, universal. No context preserved. Works when the document is simple and the reviewer is precise.
- Convert to PDF and use PDF annotations. Familiar to most clients. Loses all interactivity. Annotations end up as flat notes with no threading or resolution state.
- Google Docs / Notion export. Works well if the document is mostly text and tables. Completely breaks for anything with custom layout, charts, or interactive elements.
- Figma for design review. The gold standard for visual feedback. Requires importing screenshots, not the live HTML. Comments do not map to the actual document.
- LiveSend collaborative comments. Works on the live HTML. No reviewer account. Comments anchored to text. Threading and resolution state. Right choice when the document is an interactive HTML deliverable going to an external reviewer.
When to use a different approach
LiveSend comments are the right tool when you have a finished or near-finished HTML document going to an external reviewer who should not touch the code. They are not the right tool for real-time co-editing (use a shared development environment for that), for large teams with complex approval workflows (use a purpose-built review tool like Reviewpad or a DAM), or for documents where the reviewer needs to make edits themselves rather than leave feedback for you to implement.