Last updated August 31, 2026.
So you've made something you're pleased with. It could be a report, a dashboard, an interactive one-pager, or something Claude or ChatGPT generated for you in thirty seconds. Whatever it is, it lives in an .html file, and on your machine it looks exactly the way you intended.
Then you send it to your client, and a little while later the reply comes back: "I think you sent the wrong file? All I'm seeing is code."
The short answer
Put the file somewhere that serves it over the web, and send your client a link instead of the file itself.
I'd love to offer a cleverer trick, but every other route falls over somewhere. Email tends to show the source code, or a security policy swallows the attachment before anyone sees it. Cloud storage links display the markup instead of the page. Zipping the folder works nicely on a Mac, goes wrong on Windows more often than anyone expects, and stands no chance on a phone.
The rest of this article sorts out which of those failures you actually hit, so you can apply the matching fix rather than trying four things at random.
Why your file arrives as code
Three separate things can go wrong here, and they get mixed up all the time, which matters because each one needs a different fix.
Cloud storage treats your page as text
If your link came from Google Drive, OneDrive, Dropbox or Box, the wall of code your client saw is intended behaviour. None of the big storage platforms will render HTML from a shared link, and there's no hidden setting that switches it on.
Google Drive classifies .HTML as "Markup/Code," in the same bucket as .CSS, .PHP and .py, so as far as Drive is concerned your finished page belongs with the source files. Drive did host web pages once upon a time, but the feature was deprecated in August 2015 and stopped serving on 31 August 2016.
Dropbox comes right out and says it in their help centre: "Shared links don't render HTML content in a web browser." Rendering was switched off for Basic accounts in October 2016, and for Plus and team accounts on 1 September 2017.
OneDrive and SharePoint sit behind what Microsoft calls strict browser file handling, which admins can't change. In Microsoft's own words, .htm and .html files in document libraries "no longer open in the browser. Users are prompted to download the files."
Box does list HTML as previewable, though what you get is a text preview of the code. Box staff described HTML preview as "a current limitation" on their own community forum in 2023.
The one mainstream exception is pCloud, whose Public Folder will serve static HTML if you're on a paid plan.
The assets didn't travel with the file
Sometimes the page opens in a browser but looks badly wrong: no styling, missing images, default fonts. That usually means the stylesheet, images and fonts were sitting next to the .html file on your machine, and when you sent the file on its own, everything else stayed behind.
Nothing security-related is happening here. A relative link like ./style.css resolves fine from a folder on someone's desktop, provided the folder actually contains the stylesheet. The confusing part is that this bare, unstyled look also shows up in two other situations with completely different causes, one of which is coming up next.
The scripts are dead on arrival
Hardly anyone writes about this third failure, and it's the reason so many AI-generated files misbehave even when every asset arrives intact.
Browsers have tightened up how they treat local files. A page opened straight from disk over file:// runs as an opaque origin, which means it can't make CORS requests, and ES modules refuse to load at all. MDN spells it out: "if you try to load the HTML file locally, you'll run into CORS errors due to JavaScript module security requirements. You need to do your testing through a server."
Modern build tools output ES modules almost without exception. So when your file uses <script type="module">, or fetches its data from a JSON file sitting right beside it, double-clicking produces a page that renders its layout and then goes quiet: the charts never fill in and the tabs stop responding. All the while the images load normally, so the page looks half-broken rather than obviously broken. Sending the whole folder along fixes nothing either, because the restriction follows the page wherever it's opened from disk.
What happens if you just email it
Let's clear up the biggest misconception first: .html attachments are not blocked. Gmail delivers them, and both .html and .htm are absent from Google's blocked file types list. Outlook delivers them too, since Microsoft's blocked attachments list covers every Outlook version and platform, and neither extension appears on it.
The myth seems to come from lookalike extensions. .hta, .htc, .mht, .mhtml and .chm genuinely are blocked, and anyone who has watched one of those bounce can be forgiven for assuming the whole family is banned.
Outlook delivers the file but downgrades the experience. .htm and .html sit on the default ForceSaveFileTypes list in Exchange's mailbox policy, which Microsoft defines as file types "that can only be saved from Outlook on the web, not opened." In Outlook on the web and the new Outlook for Windows, that means your client gets no preview: they download the file, go find it in their Downloads folder, and open it from there.
Gmail has its own quirk. Since a change in mid-2024, the web preview shows the raw source, and the workaround is to download the attachment and open it in a browser, which works fine once you know, and is one more thing your client has to figure out on their own.
Then there's the corporate layer: any Microsoft 365 admin can block HTML attachments with a single checkbox. The common attachment types filter doesn't include html out of the box, but it sits right there in the selectable list, the default action bounces the message back to the sender, and the filter matches on true file type, so renaming the extension gets you nowhere.
Plenty of admins turn that checkbox on, and they have their reasons. Barracuda analysed roughly 670 million emails and found that 23% of HTML attachments were malicious, making HTML the most weaponised text file type in their analysis, and Microsoft's own threat data put HTML at 37% of malicious payloads in January 2026.
Add it all up and emailing the file is fine for a friend who'll cheerfully download whatever you send, and shaky for a client behind a corporate Microsoft 365 tenant, because you're betting on IT settings you can't see, and the way you find out you lost is that the reply never comes.
Slack, of all places, is a partial exception. Since mid-June 2026 it appears to render attached HTML files inline, a change first reported publicly on 16 June 2026. Slack hasn't documented it, there's no official word on which sharing contexts it covers, and the developer documentation still describes HTML as a syntax-highlighted code preview. Enjoy it while it works, but an undocumented behaviour makes a thin foundation for client delivery.
Why zipping it doesn't solve it
Zip the folder and send that: it's the top-voted answer on most forum threads about this problem, and the people asking are rarely happy with it. One commenter on a Stack Overflow thread about sharing HTML reports with non-technical colleagues put the objection well: "you would have to download every file locally and open in a browser. This is not an ideal solution."
Unideal is putting it kindly, because four different things go wrong with a zipped page.
The first is Gmail, which blocks .js and .mjs files "including their compressed form or when found within archives." Modern bundler output ships ES modules, so a zipped build folder bounces more often than not.
Password-protecting the archive, the classic forum advice, now backfires too: Gmail blocks password-protected archives outright. That tip still gets repeated in every thread on the subject, and following it today guarantees the exact bounce you were trying to dodge.
The sneaky part is that Microsoft's filter behaves differently. It checks the type of the attachment itself, sees a zip, and looks no deeper, so the same JavaScript-filled archive sails through Outlook without a murmur. So if you test your delivery in Outlook and conclude everything works, your Gmail recipients will bounce without you ever hearing about it.
Even when the zip does arrive, Windows lays a trap on the receiving end. Explorer lets people peek inside an archive without extracting it, and when your client double-clicks the .html they can see in there, Windows extracts that one file to a temporary folder and opens it alone, leaving the stylesheet and images behind in the zip. The page comes up unstyled, which to your client reads as "you sent me a broken file." The proper sequence, right-click and Extract All before opening anything, is documented by Microsoft, though expecting a client to know that sequence is optimistic. Count the real steps for a mailed bundle (save the attachment, find it in Downloads, right-click, choose Extract All, confirm the destination, open the extracted folder, double-click index.html) and you've handed a busy person seven chances to give up.
On a Mac, to be fair, the zip route works. Double-clicking an archive expands it into a real folder in place, so relative paths resolve, and Safari goes one further and decompresses downloads automatically, something Chrome, Edge and Firefox on macOS leave alone. You just rarely get to choose your client's operating system.
One suspect you can cross off the list is Mark of the Web, the marker Windows attaches to downloaded files. It survives Explorer's extraction, but it has no effect on HTML: Chrome classifies .html as a non-dangerous type, Chromium never reads the zone marker when loading a local page, and no warning bar or prompt ever appears. Whatever tripped your client up, that particular security layer wasn't it.
The phone problem
There's a good chance your client opens whatever you send on their phone first, and phones are where every multi-file attachment approach finally runs out of road.
An iPhone will unzip the archive happily, since Apple's Files app handles that part well. The wall comes straight after: tapping the extracted HTML opens a Quick Look preview rather than Safari, and Quick Look is sandboxed to the single file it's showing. It has no way of reaching the stylesheet in the folder it just created, so your client stares at an unstyled skeleton while the CSS sits uselessly beside it. The share sheet offers no "open in Safari" escape hatch either.
Android fails for a more structural reason. File managers there hand the browser a content:// URI, which is a database identifier rather than a path on disk. With no parent folder to resolve ./style.css against, relative links point at nothing and the browser reports the files missing. No update is coming to fix that; it's how the platform was designed.
This is also the real answer to the recurring "can I send HTML over WhatsApp" question. However WhatsApp treats the file in transit, your recipient ends up holding a local HTML file on a phone, and everything above applies.
The one attachment that does work
If you'd still rather send an attachment, one configuration survives everything above: a single self-contained .html file with the CSS, JavaScript, fonts and images all inlined, sent bare with no zip around it. A file like that clears both Gmail's and Outlook's blocked lists, needs no extraction on any operating system, contains no relative paths waiting to snap, and never hits the CORS wall because there are no separate module files to fetch.
Conveniently, that's also the shape of many AI-generated exports, which tend to arrive as one file with everything baked in. Open yours and check before assuming, though.
The trade-offs are real. Base64 encoding inflates every embedded asset by about a third, which you'll feel against the 25 MB ceiling on personal Gmail and the 35 MB one on Exchange Online. A large blob of encoded HTML still draws attention from phishing classifiers. And a client on Outlook web still gets no preview, so downloading first stays part of their experience.
That last stretch is really the whole argument for a link. Attachments can absolutely work, but every attachment path depends on your recipient's device, mail client, extraction habits and IT policy, and you control none of those. A link takes all four variables off the table at once.
Your options, honestly
Pick whichever row matches your situation. Full disclosure before you read the table: HummingDeck is our product, and it's the wrong answer for two of these rows.
| If you need | Use |
|---|---|
| A public page you'll maintain and update | GitHub Pages, Netlify, Cloudflare Pages or Vercel. Free, built for this, and you keep the URL. |
| A throwaway link for a day or two | A drag-and-drop host like tiiny.host or Netlify Drop. No account, live in under a minute. |
| A client to open it with no account, with a page marked not for search indexing | HummingDeck |
| Content limited to recipients who can verify an approved email address | HummingDeck restricted access |
| Your client to comment on the page itself | Nothing in this category does it well yet. Send a link and collect feedback in email or a call. |
| It to look like your own domain | A static host with a custom domain, or HummingDeck on Business. |
If what you're really running is a website, use a proper static host. GitHub Pages and Netlify are free, this is the job they were built for, and nothing in this article should talk you out of them.
The reason to reach for something else is control. A static host serves the same public page to everyone who holds the URL, which is precisely what it's designed to do, and also what makes it an awkward default for a client deliverable that was never meant to be public or that needs recipient-level access rules.
One pleasant side effect of switching to a link deserves a mention: you can see whether it was opened. Hardly anyone arrives at this problem looking for view tracking, but if you've ever sent a proposal into silence and spent the next three days wondering, you already know why it helps.
What native AI sharing does and doesn't do
If the file came out of an AI tool in the first place, it's worth checking whether the tool's own sharing feature already covers you. Sometimes it does, and where it falls short, the gaps are specific.
Claude. On Free, Pro and Max you can publish an artifact to a public link that anyone can view without signing up. On Team and Enterprise, public publishing isn't available and sharing stays inside your organisation, a detail that stings if you're a consultant or an agency, because it means someone on a Team plan can't send a client an artifact link at all. And where publishing is available, it comes in one flavour only: a public URL, with no way to name viewers, restrict access, or set a documented expiry.
Lovable. Shared preview links open without an account, which is handy, but on Free and Pro they expire after 7 days, and password protection belongs to Business and Enterprise. Their docs also state plainly that "Lovable does not identify who opened the link."
v0. Chats stay private by default, with four sharing modes. The public ones "may be indexed by search engines and appear in public galleries", which is harmless for a demo and rather less so when the page is a client deliverable.
Gamma. Gamma publishes a hosted site rather than handing you an HTML file, so it's solving a different job altogether.
We've gone deeper on two of these separately: sharing Claude Design files and ChatGPT-generated pages.
How to do it with HummingDeck
The flow is short: drag the .html file in, take the link it gives you, and send that to your client. A standalone HTML file works on the free plan, no card required.
For a multi-file project, zip the folder with an index.html at the root and upload the zip instead; we unpack it and serve the whole thing as one page, with the CSS, fonts, images and video intact. Zip bundles live on the Starter plan at $10 a month, and files cap out at 100 MB.
The free plan gives you the link itself, basic view tracking, an email alert when a qualifying view starts, and the option to revoke the link or swap in a newer version of the HTML without resending anything. Starter adds link expiry, the ZIP bundles, and per-page engagement. Pro adds restricting a link to approved email addresses, which is what you want when the honest requirement is "this can't sit on the public web." Business adds a custom domain and removes our footer from the viewer.
What these controls establish
- Revoking a link stops new access through it. It can't invalidate a file URL a browser already has, close a tab someone's got open, or recall a copy they saved.
- For supported non-HTML documents, removing the download action doesn't stop screenshots or copy-paste. HTML viewers don't expose a download button.
- An open link can record a qualifying view. It doesn't prove who opened it, and it can be forwarded.
Share an HTML file if you want to try it, or read our comparison of eight HTML hosts if you'd rather shop around first. Pricing is here.
FAQ
How do I share an HTML file with someone?
Upload it somewhere that serves it over the web, then send the link. Emailing the file usually shows your recipient the source code instead of the page, and cloud storage links from Google Drive or Dropbox display the markup rather than rendering it.
Can other people open HTML files?
Anyone with a browser can open an HTML file, and every phone and computer has one. The trick is getting the file to them in a form the browser will render: a link always works, while an attachment often opens as plain text, and on an iPhone a local HTML file won't open in Safari at all.
How do I create a link for my HTML file?
Upload the file to a service that gives you a URL. Free static hosts like Netlify Drop and GitHub Pages are fine for public pages, while a document-sharing tool makes more sense when you need a noindex directive or access limited to approved email addresses.
Can I upload HTML to Google Drive?
Google Drive stores HTML files without complaint, so uploading and downloading work normally. Displaying the page is the part Drive won't do: it classifies HTML as code rather than a document, and its web-hosting feature was retired in 2016. For a link that renders, you need a host that serves the file.
Why does my HTML file show up as code in email or Google Drive?
Those platforms treat HTML as source text rather than as something to render. Gmail's web preview began showing raw source in mid-2024, and Drive files HTML under Markup/Code. Serving the file from a web host is what turns it back into a page.
Can I send HTML in WhatsApp?
The reliable route is a web link. Sending the file itself breaks on the receiving end, where your recipient is opening local HTML on a phone: iOS previews the HTML without loading sibling stylesheets, and Android can't resolve relative links from the file URI.
How do I share an HTML file that has images?
Either inline the images into the file as base64 so it becomes fully self-contained, or upload the whole folder to a host that serves it. Sending the HTML file on its own leaves the images behind, because the file points at neighbouring files that didn't travel with it.
Does Outlook block HTML attachments?
Outlook delivers .htm and .html attachments, and neither type appears on Microsoft's blocked list. The real limitation is preview: both are set to save-only in Outlook on the web and the new Outlook, so your recipient has to download the file before opening it. An IT admin can still block HTML at the mail gateway, and many do.
Can I share an HTML file without making it public?
Use a tool with access controls rather than a public static host. Document-sharing tools can require verification through an approved email inbox, set an expiry date, or let you revoke the link later. A noindex directive can discourage search indexing, but it is not an access control.
How do I share a Claude or ChatGPT artifact?
Claude's own publish feature covers public sharing on Free, Pro and Max, while on Team and Enterprise sharing stays inside the organisation. If Claude, ChatGPT, or another tool hands you an HTML file, check whether it is self-contained, then upload the file or its complete bundle to a host.
Can I just turn it into a PDF instead?
A PDF is easier to send and every recipient can open it. The trade is that you give up whatever made it worth building as a web page: interactive charts, filters, tabs, hover states, anything that responds to a click. If the interactivity is the point, converting to PDF defeats it.
About the author
Ilya Spiridonov is the founder of HummingDeck, a document-sharing platform that serves standalone HTML files and multi-file HTML bundles to external recipients.
Sources
- Gmail blocked file types, Google Workspace Support
- Blocked attachments in Outlook, Microsoft Support
- Anti-malware protection and the common attachment types filter, Microsoft Learn, updated 9 June 2026
- Force-save attachment types in Outlook on the web, Microsoft Learn
- Gmail HTML attachment previews display raw code, University of Michigan ITS, 12 July 2024
- Force a file to download instead of open, Dropbox Help, updated 30 June 2025
- Browser file handling in SharePoint and OneDrive, Microsoft Learn
- Deprecating web hosting support in Google Drive, Google Workspace Updates, 31 August 2015
- Reasons for CORS errors: request not HTTP, MDN, updated 30 November 2025
- JavaScript modules, MDN, updated 21 August 2026
- Email threat landscape: Q1 2026 trends, Microsoft Security Blog, 30 April 2026
- Barracuda finds HTML email attachments malicious, Barracuda, 28 April 2025
- Publish and share artifacts, Anthropic, updated 22 July 2026
- Share your project, Lovable Docs
- Sharing, v0 Docs
- Zip and unzip files, Microsoft Support
- File object, Slack Developer Docs
Related:
- Host a single HTML file: eight tools compared: compare public hosts, developer platforms, and controlled sharing tools.
- Share a ChatGPT-generated HTML website: use the same workflow for a self-contained page created in ChatGPT.
- Share a Claude Design outside your organisation: follow the dedicated export and external-sharing workflow.
- Add analytics to an HTML page: compare analytics scripts with a tracked-sharing layer.
- Host an InDesign HTML export: handle a multi-file HTML bundle with fonts, images, scripts, and video.