Drop a single HTML file here and get one clean link that renders it live in the browser — no server, no DNS, no build step.
Drag & drop your photos or files
Multiple files become one album link automatically
or
PDF · Images · Video · ZIP · HTML
up to 100 MB on the free plan
Free: 20 links, up to 100 MB, never expire · Pro: unlimited, permanent links
Inline your CSS in a <style> tag and your JS in a <script> tag, and reference any images by full https:// URLs or as base64 data URIs. If your CSS/JS/images live in separate files right now, this is the only prep step that matters — everything the page needs has to be inside the one .html you upload.
Drag it onto the card. You can start with no account for one file up to 10 MB; a free signed-in account gives you 20 hosted pages, up to 100 MB each. The file is validated by its real bytes, not its name, so only genuine HTML is accepted.
Your page is served at a clean, shareable link and shown live in a sandboxed browser view. Open it yourself first — because scripts run isolated, a page that reaches for a parent window or a same-origin cookie will behave differently than it did on localhost. Fix and re-upload if needed.
Send the URL, or download the auto-generated QR code to drop into a slide, a printout, or a poster. Every open increments a view counter so you can see the page is actually getting looked at.
The classic case: you hand-coded an index.html — a coming-soon page, an event RSVP, a link-in-bio, a wedding details page — and every hosting guide wants you to buy a domain, point nameservers, and wait for propagation. Here the page is live the second the upload finishes, at a link you can share by text. Because it renders live rather than showing markup, visitors see the real page with its layout, fonts, and hover states intact. The honest limit: it's genuinely one file. If your site is index.html plus a /css folder and an /images folder, either inline everything into that one file or this isn't the right tool — a bucket of assets won't wire itself together.
Plenty of tools export a self-contained .html: a pytest or Jest coverage report, a Playwright run, an Allure or pandas-profiling summary, a Lighthouse audit, a Jupyter notebook saved as HTML. These are already built to be one file with everything inlined, which makes them a near-perfect fit. Instead of zipping the report and emailing it — where the recipient has to download, unzip, and find the entry file — you send one link that opens the interactive report in their browser. The view counter tells you the client or teammate actually opened it, and the link keeps working for the next person who needs it. Interactive charts and collapsible tables keep working as long as their JS was inlined into the export.
HTML email is its own painful format — nested tables, inline styles, no external stylesheets — and before you push a campaign you want a stakeholder to see the rendered result, not the source. Paste your Mailchimp, Klaviyo, or MJML-compiled output into a .html file, host it, and send the link for sign-off. Two honest caveats worth stating up front: a browser render is not a true inbox render (Gmail and Outlook strip and rewrite things their own way, so use this for layout/copy review, not final QA), and any tracking pixels or click-tracking links baked into the export will still point at your ESP. Strip those out of the review copy if you don't want your own test opens counted.
Yes. Everything the page needs must be inside the one file or loaded from an https:// URL — inline your CSS and JS, and reference images as full URLs or base64 data URIs. Separate .css/.js files or an images folder won't be linked up.
Yes, as long as those libraries load over https from a CDN like jsDelivr, unpkg, or cdnjs. Anything fetched from an https:// URL loads normally; only local sibling files won't resolve. Code that needs same-origin storage may not work in the sandbox.
Visually, almost always — layout, fonts, CSS animations, and CDN scripts render the same. Because the page runs in a sandbox, code that reaches for the parent window, first-party cookies, or a same-origin API may behave differently. Open the live link once to confirm before sharing.
Yes — coverage reports, Playwright results, Lighthouse audits, and Jupyter notebooks exported to HTML are usually already single self-contained files, which makes them an ideal fit. Interactive charts keep working as long as their JavaScript was inlined into the export.
For layout and copy review, yes: host the compiled email and send the link for sign-off. But a browser render isn't a true inbox render — Gmail and Outlook rewrite HTML their own way — so use it to approve design, not final deliverability QA.
Upload a file and share one clean, trackable link — free, no sign-up to start.