Upload an .html file to Drive, open it, and you get a wall of markup instead of the page. Nothing is broken — Drive is doing exactly what a filing cabinet does. Here's the mechanism, the workarounds people try, and what actually renders it.
You export a report, a dashboard, or a page an AI built for you. It's an .html file. You upload it to Google Drive, click it, and get this:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<style>body{font-family:system-ui;margin:0}...
A wall of markup where the page should be. The instinct is to assume the export went wrong and to generate it again. It didn't, and re-exporting produces the identical result — because nothing about your file is the problem.
A browser doesn't decide to render HTML by looking at the file extension. It renders when something hands the file over labelled as a web page. That label is a header called Content-Type, and a web host sets it to text/html. That single line is the whole difference between a page and a screenful of code.
Drive doesn't set it, and that isn't an oversight. Drive's job is to hold files safely, version them, and let people collaborate on them. Handing an arbitrary uploaded file to your browser as a live web page would mean anyone could host executable content on a google.com address — which is precisely why the old Drive web-hosting behaviour was retired. What you're seeing is a deliberate design decision working correctly, in a situation it was never meant for.
So the file is fine. It's in a place that stores files rather than serves pages. Everything after this follows from that one fact.
Download and open locally. Works on your machine. On the recipient's, it becomes their problem: find the download, know that .html belongs in a browser, get past a phone that has no app mapped to that extension. You've turned a delivery into a support call.
A third-party Drive viewer add-on. These read your file through someone else's service and render it there. Setting aside whether it works, it means routing a client deliverable through a third party you haven't vetted. For anything with real data in it, that's a bigger decision than the inconvenience it solves.
Rename it to .txt so at least it opens. People genuinely try this. It removes the confusion and delivers nothing — now it's text on purpose.
Put it somewhere that serves pages. This is the only one that ends the problem rather than moving it, and it's a smaller job than it sounds: any static host will set the header for you. If your page needs a real backend — saved form submissions, a login, a database — deploy it on something built for that, like Vercel or Netlify. If it's a self-contained page that just needs to render, a drop-and-get-a-link host does it in seconds.
If your export is a folder — index.html plus a stylesheet, some scripts, a few images — Drive breaks it a second way that's easy to misread as a different bug.
Those files refer to each other by position: index.html asks for ./style.css, meaning next to me. Inside Drive there is no next to me. Every file gets its own unrelated ID, so the references point at nothing. Upload all fifteen files and the page still arrives unstyled and inert, which looks like a broken export rather than a broken address scheme.
Two ways out: ask the tool that made it to produce a single self-contained file, or zip the folder and hand the bundle to a host that unpacks it and keeps the relative paths intact.
None of this makes Drive the wrong tool — it makes it the wrong tool for delivery. Storage, co-editing, an archive copy that outlives whatever host you picked: that's its home turf and it does it well. The mismatch only appears when the thing you're handing over is a finished page meant to be looked at, and we've written about where those two jobs diverge in more detail.
There's a related symptom worth telling apart, because the fix is different. If the file renders fine for you but your recipient reports a sign-in wall or a request-access screen, that isn't a rendering problem at all — it's permissions, and it usually means the link was copied before access was set. That one lives in why a share link won't open for them.
Drop the .html file — or a zipped folder — into miinideck and you get a private link in seconds. The header is set, so the page renders live in any browser: charts draw, toggles toggle, no download, no account on their end, no "which app should open this."
Every link is unguessable and no-indexed by default, so it doesn't turn up in search. Add a password if the contents warrant it, or an expiry so it doesn't sit around after the project ends — both are free on every plan. Replace the file later and the address stays the same, so the link you already sent shows the current version.
Free covers one always-on link and 10 MB per file, with other links defaulting to a 7-day expiry. Solo ($4.99/mo) makes links permanent and adds the detailed access log; Studio ($14.99/mo) adds a custom domain and white-labelling.
The short version: your file was never broken. It was in a cabinet, and you needed a room.
The attachment arrived, nothing was blocked, and your recipient sees markup instead of the page. That's three different email failures people keep merging into one. Here's which one you hit, and why the fix isn't a different attachment.
You send a delivery link, the reply is 'blocked by our security policy.' Nothing is wrong with your file. Here's what actually inspects a link between you and them, why unfamiliar domains lose that inspection, and what you can do from your side.
Website annotation tools start by asking where the page lives — a reasonable assumption that quietly excludes the most common case in 2026: an HTML file your AI just made, sitting in your downloads folder, due in front of a client this afternoon.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.