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.
Drop a folder, get a live site in seconds, no account — and a preview that Cloudflare's changelog says stays live for one hour unless you claim it. That's an excellent preview. Here's the line where the thing you're sending stops being a preview.
They solve the same problem — getting someone from the physical world to a URL — in ways that fail differently. The deciding question isn't which is more modern; it's whether the person can point a camera at it.
A Drive link hands someone a file in a filing cabinet — download it, or preview a flattened copy. A private link hands them the finished thing, already open. Where the two diverge on rendering, control, and who the link assumes the reader is.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.