Paste HTML code or drop an .html file — it renders live, here in your browser. Nothing is uploaded.
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.
The toolbar is small on purpose. Format opens up minified markup so you can actually read it. The width switcher shows the page at 390 px, 834 px or full desktop width — roughly a phone, a tablet and a laptop. Full screen hides everything but the page, which is the closest you'll get to what a recipient sees. And Export saves whatever is in the panel as an .html file, the quickest way to turn a snippet you pasted into a file you can keep or send.
Paste it into the panel. It renders straight away in an isolated frame: styles apply and scripts run, but the frame can't reach this site or anything else in your browser. That makes it a reasonable place to look at a snippet you didn't write yourself — you see what it draws without opening it as a page of its own.
Yes. Change the code in the panel and the rendered page redraws a moment after you stop typing, so you can nudge a style or a line of text and watch the result without pressing anything.
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, if it's one self-contained file. A browser game or animation exported as a single .html file is a page whose scripts draw on a canvas, and this frame runs those scripts the way a browser tab would, so the game starts and the animation plays. If it loads separate sprite, sound or level files from its own folder, it will start without them: zip the folder and open it in the ZIP viewer instead. Engines that need multithreading, such as some Unity and Godot web exports, may not start here at all. Sound can wait for your first click, because browsers hold audio back until you interact with the page.
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. Without an account the link lasts 7 days and can take a password; sign in (free) to change the password later or keep one link from expiring. 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.