The short answer
SCORM vs HTML5 is not a real choice. HTML5 is the technology a course is built from: HTML, CSS, JavaScript and browser-native video and audio. SCORM is the packaging and tracking wrapper around that content, so an LMS can import it and record results. Every modern SCORM package is HTML5 content inside. You choose a destination, not a side.
The question exists because authoring tools list "HTML5" and "SCORM 1.2" side by side in the same publish menu, as if they were two rival formats. They are the same content at two levels of wrapping. The rest of this article takes the two layers apart, explains why the comparison once made sense, and gives the one question that decides which output you need.
What HTML5 is in this context
Strictly, HTML5 is a revision of the HTML standard, finalised by the W3C in 2014. In e-learning the word is used more loosely to mean "content a browser can run with no plugin": HTML markup for the pages, CSS for layout, JavaScript for the interactions, and the <video>, <audio>, <canvas> and SVG features that replaced the plugins older courses depended on. When a tool says "publish to HTML5", it means it will render your slides, quizzes and media as ordinary web pages.
An HTML5 export is therefore a folder, or a zip of a folder, that looks like a small website:
- a launch page, typically
index.htmlorstory.html; - the tool's player scripts and stylesheets;
- the slide or page data, usually as JavaScript or JSON files;
- images, audio, video and fonts.
You can put those files on any web server, an intranet, a static hosting bucket or a help-centre page, and anyone with the link can open them. Nothing in that folder knows who the learner is, what they scored, or whether they finished. It is a website, and a website reports nothing by itself.
What SCORM adds on top
SCORM does not replace any of the above. It adds two things around it. The first is a file, imsmanifest.xml, at the root of the zip, which tells the LMS what the course is called, which file to launch, how the content is organised and which version of the runtime it expects. The second is a conversation: when the LMS launches the content, the page's JavaScript looks for an object the LMS has placed in the window hierarchy (API for SCORM 1.2, API_1484_11 for SCORM 2004) and reports through it.
Initialize("") → "true"
SetValue("cmi.core.lesson_location", "slide-14") → "true"
SetValue("cmi.core.score.raw", "85") → "true"
SetValue("cmi.core.lesson_status", "passed") → "true"
Commit("") → "true"
Terminate("") → "true"
That is the whole addition: one descriptive file and a handful of calls. The content files themselves are often identical to the HTML5 export, with one extra script that finds the API and translates the player's internal events ("slide viewed", "quiz submitted") into those calls. What is SCORM? walks through the manifest and the runtime in detail; the point here is that neither of them is content. They are instructions about content.
Why did the SCORM vs HTML5 comparison exist?
The phrasing is a leftover from a real transition. Until roughly the mid-2010s, most authoring tools rendered their output as Flash: a .swf file inside a thin HTML page, which the browser ran through the Flash Player plugin. A "SCORM package" from that era was, in practice, a Flash SCO. When tools began offering browser-native output, they labelled it "HTML5" and put it beside the existing option, so the choice really was between two different renderings of the same course. HTML5 output was the newer, less tested one, and it was fair to ask which to ship.
| Era | What the content was built with | What the LMS wrapper was |
|---|---|---|
| Early 2000s to mid-2010s | Flash (.swf) in an HTML shell, sometimes with an HTML5 fallback | SCORM 1.2 or 2004 |
| Mid-2010s to 2020 | Flash or HTML5, selectable at publish time | SCORM 1.2 or 2004 |
| 2021 onwards | HTML5 only | SCORM 1.2 or 2004, cmi5, or none |
That transition is over. Adobe ended support for Flash Player in December 2020, browsers removed the plugin, and from January 2021 the player itself refuses to run Flash content. A Flash SCO therefore no longer runs in any current browser, LMS or not. The contrast that gave "SCORM vs HTML5" its meaning has disappeared: every SCORM package built today is HTML5 inside, and the only remaining difference between the two publish options is the wrapper.
The phrase lingers for one more reason. Some tools and platforms use "HTML5" as shorthand for "untracked web output" and "SCORM" as shorthand for "tracked LMS output". That is a label for the wrapper, not a statement about the technology, and reading it literally is what produces the category error.
HTML5 export vs SCORM export
Publish the same course both ways and compare the outputs:
| Concern | HTML5 export | SCORM export |
|---|---|---|
| Content files | HTML, CSS, JavaScript, media | The same files |
imsmanifest.xml | Absent | Present at the zip root |
| Runtime API calls | None | Initialize, SetValue, Commit, Terminate via a wrapper script |
| Where it runs | Any web server, or opened from a link | Launched by an LMS or a SCORM player |
| What it reports | Nothing | Status, score, location and suspend data to the LMS |
| Opened directly in a browser | Works | Usually runs, but finds no API and records nothing; some content shows an error |
The last row matters for testing. Double-clicking index.html inside a SCORM package is not a valid test of the package, because the API lookup fails and the wrapper either falls back to a no-LMS mode or stops. It tells you the content renders; it tells you nothing about what the LMS will receive. If you need SCORM content to run somewhere that is not an LMS, how to host SCORM without an LMS covers the options that keep the runtime conversation intact.
Moving between the two outputs is a matter of adding or removing the wrapper, not rebuilding the course. Going from HTML5 to SCORM means supplying a manifest and a script that makes the calls; converting HTML5 to SCORM shows what that involves and what the LMS will and will not be able to track afterwards. Going the other way means dropping the manifest and the wrapper, with one caveat: content that insists on finding an API before it will start needs that check disabled or stubbed, which is a setting in most tools rather than an edit to the content.
Which one do you need?
Decide by destination, not by which option sounds more modern.
- The course goes into an LMS and you need completion, a score or a pass/fail recorded. Publish SCORM. SCORM 1.2 is the safer import on older platforms; SCORM 2004 separates completion from success and allows far more suspend data. If the LMS supports it and you want richer data than SCORM carries, cmi5 or xAPI are the alternatives, but they are a different wrapper, not a different kind of content.
- The course goes on a website, an intranet, a help centre or a shared link, and nobody needs a record. Publish HTML5. A SCORM package here is dead weight: the manifest is ignored and the runtime calls go nowhere.
- Both. Build once and publish twice. The content is identical; only the wrapper differs, so there is no second course to maintain.
One edge case is worth naming. Some tools can publish an HTML5 export that sends xAPI statements directly to a learning record store, with no LMS and no package. That is tracking without SCORM, and it is the right answer when the content lives on the open web but the organisation still wants evidence of use. It does not make the output a SCORM package, and an LMS set to import SCORM will reject it.
When someone asks for "the HTML5 version" of a SCORM course, or "a SCORM version" of a web page, the useful reply is a question: where will it be opened from, and does anyone need to see a result afterwards? The answer to that settles the format. The content stays the same either way.
Where SCORM Central fits
SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.