Email designers live in a strange gap. The thing you are building is HTML, but you cannot exactly send the client a file, and forwarding a test send has its own failure modes: it lands in spam, the client's reply quotes a mangled copy, and their feedback arrives as "the button looks weird" with no way to tell which of your three buttons weirded them out.
Screenshots are worse. They flatten a scrollable, clickable thing into a picture, usually cropped, usually outdated by the next revision.
The preview link workflow
The approach that keeps rounds short: host the email HTML at a link and send that for review. The client opens it in a browser and reads the actual email, full width, their screen, their fonts. With commentable, they can also click any block and pin a comment to it, so "the button looks weird" becomes a note sitting on the button in question. Nobody installs anything, and reviewers do not need accounts.
Round to round it goes like this:
- Export or copy the HTML from your email builder. Paste it into a new link.
- Send the client one URL with focused questions. Subject line options go in the message, since the preview shows only the body.
- Comments come back pinned to blocks. Fix, update the same link, resolve the pins.
- When content and design are approved, do one real test send for final confirmation in actual clients.
What a browser preview does and does not prove
Be straight with clients about this: a browser renders your email better than most email clients will. Desktop Outlook uses Word's rendering engine and eats CSS for breakfast. Gmail clips messages over 102KB. Dark mode inverts colors unpredictably across clients.
So the browser preview is the right tool for content, copy, layout and design approval, which is most of the review conversation. It is not a rendering test. For that final stage, tools like Litmus and Email on Acid screenshot your email across dozens of real clients, and they are worth it if your list skews toward Outlook. The mistake is using those (paid, slower) tools for the content rounds, or using screenshots for anything.
Why not just use the builder's preview share?
If you build in Mailchimp or Stripo, they have preview links, and for teams fully inside one tool they can be enough. The cases where a separate preview link wins:
- Hand-coded emails, where there is no builder to share from.
- Agency work, where the review page should carry your logo, not your vendor's, and you would rather not walk a client through a marketing platform's interface to leave a note.
- Confidential campaigns. Product launches and announcement emails leak badly. An end-to-end encrypted link with a password and an expiry date is a different security posture than a platform preview URL that lives forever. The password guide has the details.
- Consolidated feedback. Builder previews are mostly read-only. A commentable link is the feedback channel, so approval and revision requests stop scattering across email replies.
One more habit worth stealing
Date your preview links to the campaign. An email review link has no business outliving the send date, so set it to expire a week after. Old campaign previews floating around are clutter at best and a leak at worst. Expiry is a default on commentable links, and honestly, for this use case it is the correct default everywhere.