How to Send an HTML File to a Client (and Get Feedback Back)

Sending an HTML file to a client has two failure points: the file not arriving in a usable state, and the feedback coming back unusable. Both are solvable, and neither is solved by trying harder at email. This guide covers the delivery mechanics and the review framing together, because in client work they are the same problem.

The Problem

Client review is where project timelines go to die, and the causes are mundane.

Delivery friction filters out reviewers. Ask a client to download a file, unzip it, find index.html, and open it in a browser and you will lose a meaningful share of them — permanently, not temporarily. They will get to it later. Later does not arrive. On a phone, the attachment route often does not work at all, and phones are where a lot of client review actually happens.

Ambiguous feedback costs rounds. When the client can only describe the page in prose, you get “the top section feels cluttered” and “can we try something different with the blue?” Every one of those requires a clarifying exchange before you can act, and each exchange is a day.

No shared reference produces scope arguments. Without a version record, “this is not what we approved” is unanswerable. You remember one thing, they remember another, and the discussion has no evidence in it.

The Solution

Three moves. None of them takes more than a minute.

1. Host it, send a link

Upload the file — or a zip of the folder, if there are separate assets — and send the URL.

The client clicks and sees the page. No download, no unzip, no security warning, works on their phone. This one change removes the entire class of “did you get it?” exchanges, and it removes the reason clients often do not review: the fifteen seconds of friction that makes them defer to tomorrow.

Keep unapproved work off the client’s production domain while you are at it. A review URL can be taken down without a deploy, and it will not compete with the real page in search results later. Undraft serves hosted projects with a noindex header specifically so review copies stay out of the index.

2. Frame the review in the message

The link needs one sentence of context. This is the highest-leverage sentence in the whole project:

Here’s the draft — it’s interactive, please click through and try it on your phone. Looking for feedback on layout and copy this round; images are placeholders and the form doesn’t submit yet.

Without it, half the comments are about the placeholder images. With it, none are.

3. Give the client somewhere to put the feedback

This is the step people skip, and it is the one that determines how many rounds the project takes.

If the feedback channel is email, the client has to convert what they see into a description of where it is. You then convert the description back into a location. Both conversions are lossy, which is why “the top section” turns into you changing the wrong thing.

On Undraft the client clicks the element and comments on it. “Cluttered” arrives attached to the section that is cluttered. Nothing to interpret, nothing to confirm, and the note is still on that version next week when you want to check whether you addressed it.

Handling Revisions Without Losing the Thread

Re-upload, do not re-link. New version, same URL. The link in Monday’s email is still correct on Friday. The alternative — a new link per revision — guarantees that at some point the client reviews version 2 while you are discussing version 4.

Let the version history do your record-keeping. When each upload is retained along with the comments left on it, “we asked for that in round one” is a question with an answer. This is worth more in a scope conversation than any amount of remembering.

Close every comment. Resolve it or decline it explicitly. An unresolved comment is an item that comes back in a meeting, usually at the worst possible moment.

Examples

Before

1. Email proposal.html as an attachment.
2. It arrives with a security warning; the client ignores it for two days.
3. They ask you to “just send a PDF.”
4. You send a PDF. They now cannot try the interactive part.
5. Feedback: “Looks good, but something about the header isn’t working.”
6. You ask what. They reply the next day.

A week, one vague note, and the interactive work never got reviewed.

After

1. Upload the file, send the link with the review frame.
2. Client opens it on their phone that afternoon.
3. Three comments pinned: header spacing, one headline, a mobile layout break on the third section.
4. You revise and re-upload to the same link.
5. Client reopens, resolves all three.

Two days, three actionable notes, and a record of both rounds.

Summary

• Send a link, not a file — every download step between the client and the work costs you reviewers.
• Frame the round in one sentence — say what is placeholder and what you want feedback on; this eliminates most off-target comments.
• Avoid collecting notes in email — prose descriptions of screen locations are the main reason client projects take four rounds instead of two.

Next: the step-by-step guide to share an HTML file, and how clients comment on a webpage directly.