Lumi exports H5P content to a single standalone HTML file that runs in any browser. Two caveats decide whether that works for you — some content types won't export at all, and media gets inlined, which inflates the file fast.
H5P is one of the better things to happen to interactive learning content: genuinely good activity types, open, and not tied to one vendor. Its awkwardness has always been distribution. The natural habitat of H5P content is inside a platform — Moodle, Canvas, WordPress with the plugin — and if the person you want to reach isn't inside one of those, the usual answer has been some version of "well, you'd need to set one up."
There's a cleaner path, with two caveats worth knowing before you commit to it.
Lumi is a desktop application for Windows, macOS, and Linux that lets you author and view H5P content offline. Its useful trick is the export: it can produce a single standalone HTML file that opens in a browser without installing anything and without a connection.
That's the whole unlock. Once your activity is one HTML file, it stops being platform-bound content and starts being a web page — hostable anywhere, linkable, openable by anyone with a browser.
Which means the delivery question stops being "does the recipient have an H5P-capable platform" and becomes "can the recipient open a link." Everyone can open a link.
This is the one that will bite you if you don't hear it first.
Some H5P content types cannot be exported to standalone HTML — it's a property of how those content types are built, not a setting you missed. When it happens, the export doesn't fail loudly with a useful message. It produces a blank page, caused by CORS errors under the hood.
So the discipline is simple and non-negotiable: open every export yourself before you distribute it. A blank page you find takes a minute to work around. A blank page thirty students find takes a lesson.
If an activity has to travel outside a platform, that's a constraint worth knowing at authoring time, not export time — build it in a content type you've confirmed exports cleanly.
The thing that makes a single-file export genuinely self-contained is that the media goes inside it: images and audio are converted into text embedded in the document rather than sitting alongside it as separate files.
That's the right design — it's why the file works with no folder and no connection. But it has an obvious consequence: the file gets big. Encoding binary media as text costs roughly a third more than the original bytes, on top of bundling everything into one document. An activity with a handful of images and an audio clip can be substantially heavier than the sum of its parts suggested.
Where this shows up is upload limits. If you're hitting one, the fixes are ordinary: compress the images before exporting, drop the ones that were decorative, or accept that a genuinely media-heavy activity may not want to be a single file. (For reference, upload ceilings here are 10MB on the free tier, 25MB on Solo, 50MB on Studio — a text-and-interaction activity sits well under that; a photo-heavy one may not.)
An .h5p file is not a shareable document. It's a package designed to be uploaded into a platform that knows how to run H5P. Emailed to a student, it's an unopenable blob, and the student's reasonable conclusion is that you sent a broken file.
The HTML export is a finished web page. It opens.
When a colleague says "just send me the H5P," find out which one they mean before you send anything. One of those answers costs you an afternoon of confused replies.
This is the same trap as handing someone a SCORM package and expecting them to open it — a package for a machine, mistaken for a document for a person.
Once you have a working export, you can email the HTML file. It'll technically work.
But you'll spend the next day answering messages, because a downloaded HTML file is a genuinely bad user experience on the devices students actually have: managed Chromebooks, phones, locked-down school laptops. The file lands in Downloads, or doesn't; it opens in a text editor, or doesn't open; the browser warns about it.
Hosting it removes every one of those steps. Upload the exported HTML, share the URL, and the activity runs on click for anyone, on anything, with no download. The link is unguessable and off search, so a class resource doesn't become a public one — which matters more for educational material than people expect, given how much of it contains answers.
And when you revise the activity, re-export over the same link. Everyone who bookmarked it gets the current version. No "v2_final" in circulation.
Drop the exported HTML — or a zipped folder if your export produced one — and get a private link students open with one click. No platform, no plugin, no account.
Lumi's HTML export turns platform-bound H5P content into an ordinary web page. Test each export, because some content types quietly produce blank pages. Watch the file size, because media gets inlined. Then host it and share a link instead of a file — the same reason course content generally does better on a link than inside an LMS you have to enrol people into than as attachments trapped in whichever system the institution happened to buy.
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.
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.
Email providers cap attachments around 20-25MB. The fix when the file is bigger isn't to compress harder — it's to send the URL instead.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.