A SCORM package isn't a course you can open — it's a course wrapped for a machine. Here's what that wrapper buys you, what it costs, and when a plain web link is the honest artefact to hand someone.
Someone asks you to "just send the SCORM file." You send it. They reply that it doesn't work.
They're right, and so were you. The file is fine. It was just never meant to be opened by a person.
Strip the acronym and a SCORM package is a ZIP file containing three things: your course, a manifest describing its structure, and runtime code whose job is to talk to a learning platform.
That last part is the whole point, and it's the part that makes the package useless on its own. When a SCORM course launches inside an LMS, it opens a conversation: I've started. They're 40% through. They scored 82. They've completed it. The LMS records each of those against a named learner, and that record is what the entire compliance-training industry runs on.
Now take away the LMS. The course launches and starts talking — to nothing. Depending on how the course was built, you get something that half-loads, sits waiting, or throws errors into a console the reviewer will never open. From their side, "it doesn't work." From yours, "it works fine in the LMS." Both true, neither useful.
There are third-party SCORM players that simulate enough of an LMS to preview a package, and they're genuinely handy when you need to check a build. But a workaround you have to explain is not a delivery method. If your reviewer needs a tutorial to open your deliverable, you sent the wrong artefact.
The other output your authoring tool offers — publish for Web — is a folder of ordinary static files. An entry page, some scripts, the media. Served over the web, it's just a website that happens to be a course. Interactions, branching, audio, quiz logic all run client-side, in the browser, with no platform underneath.
Hand someone a URL and they get a running course. That's it. No import, no seat, no login, no admin to ask, no software.
And it records nothing. Not because a feature is missing, but because there is nobody on the other end of the line to record to. This is the honest trade, and it's worth stating plainly rather than discovering it later.
Not "which is better." They're different artefacts for different jobs. The question is:
Is anyone being graded?
If the answer is yes — compliance training you have to prove happened, certification with an audit trail, anything where "who completed this and when" is a question someone will actually ask — then you need SCORM (or xAPI) and a platform recording it. That's not overhead. That's the requirement, and no amount of link convenience substitutes for it.
If the answer is no, look at what the tracking layer is costing you. A client's marketing lead reviewing a module isn't being graded. An SME checking terminology isn't being graded. A prospect looking at a sample isn't being graded. In every one of those, the LMS requirement adds a seat, a login, an import step, and often a wait for someone's admin — in exchange for a completion record nobody will ever read.
That's a bad trade, and it's the one most review cycles are quietly paying.
xAPI (formerly Tin Can) comes up here as the modern answer, and it does loosen things: instead of reporting only to the LMS that launched it, a course sends statements to a Learning Record Store, which can live elsewhere and can capture activity well beyond a single course.
But it doesn't change the split. You still need something listening. No LRS, no LMS, no receiver of any kind, and xAPI has nowhere to send statements either — you're back to a course that runs and records nothing, which is exactly where the web link already was, with more setup.
The question was never SCORM versus xAPI. It's whether anyone is listening.
The resolution most teams working with external clients land on isn't picking a side. It's publishing twice from one course:
Same course. Two outputs. Two jobs, each done by the artefact designed for it.
The failure mode is asking one to do both — emailing a SCORM package to a human, or promising a client completion tracking from a hosted link. Both promises break, and they break in front of someone whose trust you needed.
For the review half: zip the Publish-for-Web folder, drop it in, and send one private link. Password and expiry optional, LMS not required.
A SCORM package is a course wrapped for a machine. A web link is a course handed to a person.
If you're sending it to a person, send the one built for people — and keep the wrapper for the machine that's actually going to read it. The same instinct applies well outside e-learning: the reason a hosted link beats a zipped folder in almost every hand-off is that the recipient is a human with a browser, not a system with an importer.
You built a one-page site someone paid you for, and you are about to put it on a free plan. The question is not whether the free plan can handle it — it is whether the host's own terms permit it. Two different walls, and only one of them shows up as a bill.
Every list of free HTML hosts assumes you'll sign up. If you won't, the field narrows to a handful — and each one charges you for it in a different currency. Which hosts genuinely need no account, what you give up, and when signing up is the cheaper trade.
When the page is a folder rather than one file, the hosting question changes and so do the ways it breaks. Which free hosts take a ZIP, what happens to your folder structure once they unpack it, and the four failure modes that account for almost every broken zipped site.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.