Paste HTML or drop an .html file. It renders here, in your browser — nothing is uploaded.
Rendered in your browser. The file is not uploaded, stored, or logged.
Drop an .html file onto the panel, or paste the markup straight in. It renders immediately in an isolated frame, exactly the way a browser would draw it: stylesheets apply, JavaScript runs, and libraries loaded over HTTPS from a CDN still work. Nothing is stripped, so what you see is what the file actually does.
Switch between phone, tablet and desktop width to see how the same file reflows. This is usually the real question behind opening an HTML file at all — not "does it work" but "does it hold up on the screen the other person will use".
The rendering happens on your own machine. The file is read by your browser and drawn in a sandboxed frame; it is never sent to miinideck, never written to storage, and never logged. Close the tab and there is nothing left behind — which also means there is no link yet. When you do want to send it to someone, that's a separate, deliberate step.
A common arrival here is an export from an AI tool — a Claude artifact, a ChatGPT canvas, something a coding assistant produced — downloaded as one HTML file and now sitting in a downloads folder doing nothing. Dropping it in answers the question those files always raise: does this actually stand on its own, away from the environment that made it? What renders here is what a recipient would get, because there is nothing else on this page holding it up.
Paste the markup or drop the file into the panel above. Your browser reads the file locally and draws it in an isolated frame, so the contents never leave your machine — nothing is transmitted, stored, or logged. That matters when the file is a client report or an unreleased page: you can check it renders correctly before deciding whether anyone else should see it.
Because whatever opened it is treating it as text rather than as a document to draw. That's the normal behaviour for a code editor, and it's also what most email clients and file-preview panes do — they show the source, or offer a download, instead of rendering. A browser is the thing that renders HTML, which is why dropping the file here shows you the page rather than the markup.
Yes — download the file out of Drive, drop it here, and it draws as a page. What this can't do is render it in place, inside Drive itself. That needs something holding permission on your Drive account: add-ons and browser extensions exist for exactly that, and they're the only way to stay inside Drive, but they read your file through their own service — worth knowing before you install one for a client's document. This viewer never touches your account; your browser reads a file it already has. The trade is the plain one: one extra download step, and nothing gains access to your Drive.
Yes, as long as they're inside the file or loaded over HTTPS. Inline styles and scripts run, and external libraries from a CDN load normally, so charts draw, tabs switch, and animations play. The frame is sandboxed so the page can't reach the rest of this site, but that isolation doesn't change how the page itself behaves.
Yes — this page works on a phone, and the width switcher also lets you preview phone layout from a desktop. That second one is usually what people actually need, because the file is being checked before it goes to someone whose screen you don't have in front of you.
There's no upload, so there's no upload limit — the practical ceiling is whatever your own browser can hold in memory, which for a normal HTML page is far beyond anything you're likely to open. Very large files may take a moment to draw.
Viewing and sending are deliberately separate steps here. When you want a link, miinideck turns the same file into one — an unguessable URL that stays out of search by default, with an optional password or expiry. That step is a real upload, so it only happens when you ask for it.
Not in this viewer, which renders one self-contained file at a time. A site split across separate CSS, JS and image files needs those files to resolve relative to each other, which only happens once they're unpacked somewhere together — that's what the ZIP upload does.
Yes, and it's one of the most common reasons people end up here. An artifact exported as a single self-contained HTML file is exactly what this renders: drop the downloaded file in and it draws the same way it did in the chat, with its scripts running and its styles applied. That is also the fastest way to check whether an export is genuinely self-contained before you send it to anyone — if it looks right here, with nothing else on the page to prop it up, it will look right on their machine too.
Because the two environments load it differently, and this viewer is closer to how a recipient's browser behaves than the chat is. If it renders here and not where you published it, the difference is usually something the published version couldn't fetch — an external library, a font, an image referenced rather than embedded — or a policy on that host blocking scripts this frame allows. Either way the file itself is intact, which narrows the problem considerably.